I would say that I do this too. There's a lot of stuff I can more or less do on autopilot and stuff that requires actual attention and finesse, for lack of a better word. I feel like management thinks that I'm good at my job for all of the autopilot stuff that I can crank out, and that makes up for the time I spend implementing one of the more interesting bits.
I think one of the ways that remote work changes this is that I can do other things while I think through a tricky problem; I can do dishes or walk my dog or something instead of trying to look busy in a room with 6-12 other people who are furiously typing because that's how the manager and project manager understand that work gets done.
I like to make parallels with sports: when I am on the court, I am so much dumber about what's going on. Suddenly, when I am on the sidelines, I can see patterns, strengths and weaknesses for each team and so forth. It's not that I was dumb while on the court, it's just that your brain is in a different mode of operation (focusing on your own performance in this particular case).
Doing the dishes is indeed a good one too.
I'd take a brisk walk around the spaceship and then hit a shower. It was a great way for me to avoid an afternoon slump and let me do a lot of background processing in relative peace.
(Amusing to see “root caused” == “diagnosed” and != “caused”.)
> He never spent a long time on a problem since he believed that the subconscious would continue working on the problem while he consciously worked on another problem.
This is definitely a thing. Intellectual labor just isn't physical labor.
Or just spending time reading about the topic
The problem is making that a regular occurrence.
Ideally you shower every two days or so.
> "I shower once a month, whether I even need it or not"
joke being that one clearly needs it after a month.
i told her that 1. i can only think in english when thinking about work and 2. saying stuff out loud helps me organize my thoughts and this is specially easy while showering because i don't really have to concentrate.
Seriously, modern work is all about knowing what to do and how to do it rather than putting in a large number of hours executing a straightforward task.
Developers are always about optimization and automation and tweaking and refinement, and their tools reflect this constant pursuit of efficiency that constantly transcends and questions how a job is expressed (UI, mental modeling) and completed.
No other industry - ironically including technical management roles (maybe even especially so?) - seems to have this sort of focus.
I even hesitantly wonder if the biggest similarity I've ever seen is with accessibility type setups with screen readers and whatnot. (Ha, that says a lot about the fundamental impedance mismatch of developer tooling!)
All the time tracking tools I've ever used (at software companies!) had a bad UI. Sometimes we even have to track the same hours into two different tools. Can't we automate time-tracking away? My explanation is that this is the result of cultural evolution. Companies that make people think twice about their time and spendings are more successful. People will copy whatever successful companies are doing.
This is so messed up - and yet so interesting as a direct result of that.
I've only ever considered the idea of "looking busy" in the sense of whether or not someone is trying to optimize for shirking actual mental engagement.
I never thought of how doing that can actually make room to think. But that's so logically obvious once you mush the two ideas together!
I say this is messed up because I can totally see this being both necessary and helpful in certain situations. Wow.
That's why I am a huge fan of free software (and I've spent years on it too).
This link shows a touchline between using api and not using api https://www.swyx.io/api-economy/
But how can we build some tool for telling product managers that they should fix there automating proces?
Starting out, if I spent a whole day thinking over a problem or writing code that I ultimately had to scrap, I would tell people I got nothing done that day and it was a waste.
Now if I do that, I see if as the necessary troubleshooting that all must go through to solve the problem.
Come on guys. Plenty of software devs are actually working during the day.
What are you guys doing if you're not working? Reading articles? Playing Halo?
When writing code you might have written 10 lines of code in the past week, but the next day you write 200 because you've been thinking about the structure of the solution. In this way you might be working even if you're going on a walk or doing the dishes.
This isn't unique to programming, of course.
You hit the nail right on the head.
This is the main thing that non-programmers (i.e. Management) need to understand about "Programmers" and the key to "Manage" them effectively.
> The greatest people are self-managing -- they don't need to be managed. Once they know what to do, they'll go figure out how to do it. What they need is a common vision. And that's what leadership is: having a vision; being able to articulate that so the people around you can understand it; and getting a consensus on a common vision.
Related quote from Scott McNealy : "Agree and commit, Disagree and commit, or get out of the way."
Too many times Management/Leadership devolves into giving orders without having a clue. It then becomes nothing more than a power trip to the detriment of everything and everybody.
All "Good" people just need Autonomy, Vision, Freedom and stellar Results will auto-magically follow.
We cannot. Some things require multiple hours of uninterrupted concentration and if my calendar looks like someone fired a shotgun filled with 30 minute meetings at it, I can't achieve that.
I mostly did small bug fixes or read articles because there was no way to do anything productive. I need the mental space to properly plan and execute.
I will backburner a ticket for days, then when what I need to do comes together I will sit down and bang it out in an hour.
It's to the point that I will deliberately review a ticket and code segment every day, even if I'm not actively working it, just to have the pieces come together in my mind and crank out the ticket.
This method is not very scrum friendly, because in truth I'm actually brain-working all of my tickets at the same time, but I haven't shifted any electrons, just neurons.
Sometimes, when I hit a sticking point, I go do something completely different - like read Hacker News - in order to push stuff into what I call "background processing" in my subconscious.
This really highlights why I hate agile so much. Intellectual work doesn't lead itself to reporting status on completed tickets every single day.
Status is WIP until completion. As for the intellectual work, that's just outright Analysis stage.
Most of dev's work is actually analysis. Sure, there's implementation, testing and such, but Analysis is almost non-stop.
Anonter way to put this is Evaluation of Alternatives, Optimization of Approaches.
If one was tasked to move a 10-ton block, 1000 yards in 10 days. You can use brute force move it 100 yards a day for 10 days or spend 5 days inventing a way to move it 1000 yards in day and get it done in 6 days.
One of the deepest thinkers ever about society and he is known for the most boring of his ideas.
Most things can be explained with this other idea of Pareto that humans are not rational but rationalizers.
Most human action/thought is kind of dumb and non-rational and then we invent rational explanations after the fact. Paint a varnish of rationality after the fact on non-rational behavior in Pareto's words.
I once collaborated with a colleague to design and implement a data sync framework. For six weeks we chatted about it during our lunch break, while walking from the office to a Japanese takeaway and back again. We'd propose ideas and find weaknesses and flaws in them, and would spend our evenings thinking hard to come up with solutions to get around these issues.
Our boss saw none of this, but it easily consumed about three weeks of person-hours (i.e. around 120 hours).
One day, walking back from lunch, neither of us could find any problems with our proposed solution. We walked into the office straight into a meeting room, spend 30 minutes drawing diagrams on a whiteboard, then returned to our desks and coded up a working proof-of-concept in a couple of hours.
From our boss's perspective, we had implemented a new technology in an afternoon. He's the kind of non-technical person who equates productivity with typing code into a computer. But I think more places need to equate productivity with sitting on a sofa staring into space, or going for long walks, or whatever it happens to be that works for the developer in question.
But then again, since thoughts are words, thinking can be translated into typing that is monitored: notes instead of code.
Those things are a form of procrastination. With your points you should be sceptical for those who just go for VS Code or whatever MS sets up for them nicely in 2 minutes, not those who configure Emacs or Vim.
This says two things about me: I usually underestimate the design details when estimating time, and the design takes me roughly the same time anyway.
This doesn’t have to be a programmer only thing IMHO. If you spend 5 hours chilling and 3 executing and everybody is happy with your performance, it may be just your way to do things. If someone next to you does the same by coding 8 hour straight - its their style, and neither is better.
Everyone else appears to be talking about time spent directly thinking about a problem - which absolutely can look exactly like you're staring into space and this magic "subconscious processing" everyone claims to do.
That is far too seductive and idea, and far too ego flattering for me to trust it. "I'm so smart I solve problems in my sleep!"
Oh really?
But the phenomenon of solving problems quickly after a break/sleep/shower/whatever is one I recognise too.
Something else I recognise is that I also jump to solutions too quickly, often wrong ones, or by something that feels quit similar, jump to the idea that I don't understand things or that I don't know how to solve a problem.
Either the "wrong idea(s)" or the "no idea" are patterns of thinking that make it that much harder to see the problem a different way, or to think up new approaches. You can absolutely overcome it, but it takes a deliberate effort of will, and possibly explicit step by step techniques to do.
Much easier to just put it down and have a nap or a walk or whatever.
But that time isn't "subconsciously working on the problem", it's time spent letting go of you original ideas, letting those neuron interconnections to loosen up ( or whatever, not a neurologist, can you tell? ) so you can generate new ideas, obviously you haven't forgotten them.. but they have that softening distance to them now, and the no longer carry as much weight.
To take in one more, completely unsubstantiated step further, maybe that what a 10x coder is: someone who can more freely move between their ideas ( naturally or via learned technique ) meaning the the need to sleep on it far less often. Or maybe they give themselves a chance to let go of there currently working on the next and the next ( which I'm sure we all do some of, or every software company would be surrounded by a cloud of Devs, walking or staring off into spec! ) But maybe to 10x engineer does that more readily? Without the the exhausting drain I know I feel jumping from deep thinking on one think to deep thinking on another?
We shouldn't discount how many of the "other things" people list are either directly rejuvenation ( sleep! ) Or at least refreshing via increased bloodflow from some level of physical movement, even if it is just getting up to do the dishes.
Personally I think "well rested me" is of about average intelligence, "well rested and in the zone me" is perhaps a little higher but "tired me"? Wow can that be a big drop!
So.. rest, rejuvenation, letting go of mental models by directing your attention else where all seem like more likely causes than "my brain solves problems without even trying"
( Sorry tsike, kinda went of on a tangent there.. ! )
Less hard problems need less-passive processing but are better solved on a bicycle or doing something completely unrelated.
And that doesn't mean you'll perform well in technical interviews. They're often about specific algorithms most people would never implement themselves. Few are about the problem solving part of programming.
There have been times I spent 20-30 minutes understanding a new problem at 5pm, which at the time seemed like it was going to take up a significant amount of my working hours the next day.
Then come back the next day and I'm able to finish the task before 10am. During the evening, the problem was solved both consciously (thinking about it on the train home) and subconsciously (whilst sleeping). I just had to produce the deliverable the next day.
Also sometimes your mind needs a break. I personally cannot produce quality thoughts continuously no matter how much you force me, or I want to. I can mindlessly do physical things, but cannot code or think. I find it hard to believe there are people who can do this, if there are, they must be rare I beieve.
It's a huge waste of human potential. Background processing is vital. Getting hit by the various silly hurdles in the path to shipping- having to go from the elation of getting something done to having to switch to an entirely different set of less fun tasks to get it shipping. Yet our processes, our industrial processes, are oriented towards assurity, towards treating us "human resources" like machines, to making us complete full units of work.
It's hard for me to tell exactly where this sprung up from, how it is so deeply deeply rooted. I tell my managers outright I think it's a wasteful & outright damaging practice, but that I understand that it's the expectation, that every other company acts like fools too, not just them. I don't argue, but I am quite clear that you will get much much much less out of me when I don't have some autonomy, when I have to drag, roll, push, row, swim each rock, one at a time, from end to end. Again, I'm not sure how such a demeaning & menial form of completing single-task-at-a-time happens, especially when no one in management or upper ranks is expected to live like this. My top theory is just that it's convenient for management purposes. That company's are bad at assessing progress, that we're afraid of situations that aren't ultra-well scheduled & predictable, and that we treat programmers like cogs in a machine because we're too afraid to try for better.
Creative procrastination is amazing. Not only are programmers out doing great things, but the task they're more obligated to do goes from irrelevant & stupid to something they just don't ever want to think of again. The internal pressures builds over time, even for the irrelevant everyday crap of development, until we're finally jazzed to just get it done. By procrastinating, we bank up some motivation. And we've gotten a lot of passive processing in. Productive procrastination is one well-known example, but I feel like it's just the tip of the iceberg. Having some different tasks to switch between, having a wheelhouse of obligations, allows enormous relief, allows a much higher average output to be maintained, in my view. I'm kind of in a lull of personal projects right now, because I completed some stuff, and don't have a lot of in-flight options to pick up & work between. Everything feels so slow & getting going again has been such a chore, I feel it so much. Being able to trade off, switch around, chase what feels good is a huge huge productivity increase.
More than anything what amazes me is how conventional & dogmatic companies are. They seemingly all chase the same malgining evil controlling exploitation of human-resources, and not a once has a company seemed to even understand that there are trade-offs. The whole industry is exactly the same; controlling & top-down, one-at-a-time. The people who invented Amdahl's law, surprisingly, seem utterly unable to grasp it's application to humans & our motivations. We all have diverse & wide execution units, but we are treated like in-order single-stage processors. If this were just the predominant way of treating engineers/human-resources, I'd find it unfortunate, but that it is almost entirely the rule, that it is universally expected, that there are so few systems or experiments for doing anything else: the status quo is pathetic & cruel, and lacks even the basic legitimacy to have explored other ideas.
This is because the classical consecrated need for project management. Back in the day, you would have factory workers overseen by managers to a) establish a process for the work to be done which is easy and precise - "plan the work" and b) oversee it - "work the plan". The process is, in their view, necessary so why question it?
SW development is a creative process which doesn't really lend itself to rigid guard railing of classical project management.
Some advocates outright speak against managers because of the penalty the rigid process has on creative throughput. Quote from https://www.simplethread.com/agile-at-20-the-failed-rebellio... :
> The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning. For example, Ken Schwaber was vocal and explicit about his goal to get rid of all project managers – not just get the people off his projects, eradicate the profession from our industry.
Industrial mass production makes physical objects with incredible efficiency, once things are up and running. Because it's so effective with atoms, people think it can be just as effective with bits, and they're wrong.
Software manufacturing is the bit after you compile the code.
Seems to invite a deep dive into the history of Gantt charts or their use.
The case in discussion is how we developers do just the bare minimum consciously (or unconsciously) and the fake away the rest. Even with this perspective I don't consider it wrong at all. Our developer brains can be in "the zone" for not more than 2-5 hours everyday. If we force ourselves to be in the zone more than that, we are just damaging our runway and heading towards a burnout.
That said, the only thing we could do is - learn how to increase our zone hours. John carmack went to the extent of measuring his bathroom breaks as a way to extend these focus zones. While that is a bit extreme. generally as developers our antidote should be to optimize our focus zones to what fits us.
This, however, should not be an excuse, but a cue to get better at that 'thinking stuff'. Improve it. Train it. Learn.
And with all that, strongly ask yourself if that 'backburner time' must be paid. A bricklayer needs 10+ hours off to rest his body, so he can lay bricks for another 8 hours tomorrow. Should we pay him 18 hours?
My answer to both is that when I efficiently ponder and backburn ideas, it is 'work'. But when I'm binging Silicon Valley Episode 5, it is not (unless I can prove that this helps me bring the problem closer).
I do think though that anyone that has written code should be able to understand that it's not as simple as sitting down and typing fast.
(Points were redeemable for schwag from the company shop. They were highly desirable and nearly cash equivalents).
Deleting code is arguably the most valuable work you could be doing.
Sometimes I'll know I need to write some code or some function and I'll just think about it in the back of my head while doing other things, sometimes for a whole day or two. Then I'll sit down and write it in like 20-30 minutes. Did I work 20-30 minutes, or have I been working for a day or two? I would say a day or two, and the 20-30 minutes was the time needed to produce the deliverable of that work.