For me, there is a difference between working "hard" and working "deep". Working "hard" means being busy, typically more than 8 hours a day. Example: answering mails, writing some sort of report, dealing with customers, driving a truck, sitting at a cash register all day. Working "deep" means being extremely focused on a challenging thing until it is done. This can be writing code, but also theoretical writing or building something with your hands, even repairing something. After a "hard" day, I am completely exhausted and my mind is blank. After a "deep" day, I am satisfied and euphoric.
> After a "hard" day, I am completely exhausted and my mind is blank. After a "deep" day, I am satisfied and euphoric.
Maybe this is the reason for the ubiquity of over-engineering and other patterns of over-complication - quite a few people enjoy deep work, but the vast majority of jobs in software development, or writing, or even a fair few in science, turn out to be only hard work when done with optimal efficiency.
I think this is true, but only if you have sufficient control over the context. I've been very careful about how I choose my jobs. But a lot of developers end up in situations where the truly deep work can only be done in coordination with a bunch of others. Assuming typically bad management, this means that the only thing left is hard work.
The first time I saw this pattern was with a place that used their master database as the central integration point for a lot of different code bases. They could have simplified things greatly, but that would have required multiple teams to simultaneously change how they used particular tables in their code. The database was controlled by a central group of database administrators who were very busy and had different incentives than the teams they supported. Getting all these people on board for a change was possible only if it rose to an executive level. Which if it could be achieved at all, required lots of politicking.
So in practice, every team had to make up for the garbage architecture through hard work. Which however much they meant well, tended to reinforce the problems.
I wrote this because I'm in a place were we all do almost nothing but "hard work" - most this hard work is the result of bad decisions and every effort to improve has gone stale because everyone is so busy chasing bugs and stupid assumptions in the architecture but it's been the idea of management and while first not realizing what I'm up to I've quickly came to learn that trying to criticize the architecture is met with silence as it's the child of management and co-workers that are there much longer than me.
We use ant with a lib-folder - worked on maven in my spare time - nobody cares. Worked on automated tests - nobody is willing to discuss this or do the required changes like fixing Angular timeouts and assigning some unqiue-id's to elements that tests don't break. We misuse the API from the parent project we are building a plugin for - some calls take 3s or more instead of feasible 100ms if correctly implemented. We have a useless PHP addon that constantly breaks for "performance" but it's slower than doing it in Java correctly. Brought all of this up. It's not even a topic.
People who study the Challenger accident talk about "normalization of deviance". When things are bad once, people react. But if they're bad regularly, people just get used to it. Bad is the new normal. And that's very hard to change.
I think the only times I've seen significant progress had 2 common elements. One is a fucking disaster. Something has to blow up so badly that the grand poobahs feel the pain, and make sure everybody beneath them does too. The other is a bubble of sanity. Maybe it's one team that has a few people like you, enough to say, "Well in this team, for this product, we're going to do it fucking right." And then that team has to show that doing it right produces great results, results that prevent the fucking disaster from ever happening again.
So for your sake, I hope you either change your organization or change your organization. You deserve better.
Excellent! Even one other sane person is a huge help. If you can find an area to make even a small demonstrable improvement, hopefully you'll be given more room to try for bigger ones. It might be easier to endure if you think of it as preparing to swoop in with a solution at the next crisis.
Yes! But only if you think of deep work as holistic problem solving rather than fetishizing some technical aspect (which is hard to avoid for certain flavor of programmerly personality).
I disagree with this statement, and I'd argue that most people haven't actually experience "deep work" (which btw, the book with that title change the way I see and experience work deeply)
Deep work has nothing to do with over-engineering and everything to do with non-distracted focused time doing something that actually releases dopamine and feels good.
yep.. and we see posts of people moving monoliths to microservices and vice-versa as a result. You either find meaning in that or there a salary premium and lots of vacation time for the mindless work. Otherwise, you're probably working "hard"
When I think back to the times I was putting in a lot of extra hours, I wasn't getting results in proportion to the time spent. Partly because being tired your capacity declines. Partly because, in retrospect, we were all performing hard work as a way of impressing clients, bosses, and each other. And partly out of some phenomenon related to "revenge bedtime procrastination" [1] where I just ran out of self-discipline and would secretly take the breaks I should have been taking anyhow.
Some years back I hired movers. Previously my experience moving had been the casual thing with friends and family. We took our time, joked around, took breaks, kept entertained. But these movers were relentless. They never rushed and never seemed stressed, but if there was work to do they were on it until the work was 100% done. And when there wasn't work to do, they were perfectly chill.
I keep coming back to the memory as how I want to work. No bullshit, hard work when it's time to work, and really letting go of it at quitting time. It's harder to achieve for software, but I will keep iterating in that direction.
> They never rushed and never seemed stressed, but if there was work to do they were on it until the work was 100% done. And when there wasn't work to do, they were perfectly chill.
That only works because their job is perfectly defined. The scope is finite and always in sight. I'm not quite convinced this would work for creative work or a project that's somewhat open-ended in features and/or scope.
To give an example of this: I can do this type of no-bullshit relentless work when I exercise in a gym. 1.5hrs of a strict routine with a fixed number of reps. And a hard stop after that.
Never found the same type of ability for deep work.
For me, the right approach is what you'll see in Lean processes. You pick the next few clear steps and break them down into small units of work, each of which delivers value. Then you knock them off at a solid pace.
And that's despite the fact that it was a startup. It helped that my cofounder had 3 kids under the age of 5. He came in on time and he left on time. We all busted ass while we were there, but when we left, we mostly left. One real test for me was when I had to take weeks off to help a sick relative. Even though I was the technical cofounder and had been involved in every bit of the code, I got maybe two calls where they really needed me. It was a sign that we're built a real cross-functional team.
I'm 99% with this, except that when you work so hard on the challenging deep work and there's no energy left to be able enjoy the glory of the success.
