| 80% of the programming I do is the style you suggest. But ... software development has bifurcated into two skills, and we don't yet have the words to differentiate them. - There's the technician skill, where you poke at your react elements and fiddle with CSS until it looks like the mockup the designers gave you. Every 20 minutes you need to trawl through stackoverflow to find the exact way to use flexbox to get the layout you want, or to work around a bug in safari. When you're done you do some refactoring and feel good about it and call it a day. - And there's the engineering skill, where you scratch your head and read wikipedia & some academic papers until you know what search terms to use. And then you realise that really you want something like an invertible bloom filter, except there's some small % chance it will fail each time you query it so you need a fallback mechanism. Except then you realise that fallback mechanism will have O(n^2) - but if you use a slightly different data structure then it'll become O(nlogn + klogk). But that requires modifications to the bloom filter itself and a funky network protocol, so you write that. If the only programming you do is the first type, thats fine. Thats where we all start. Thats the majority of work out there. 25 minute pomodoros are probably fine for that. I like pair programming, because I can stay focussed better with a friend. Sometimes I listen to excited music while I work. But all the work I'm most proud of is the second type. I wrote a streaming incremental compiler for a 2d air pressure based language. I got 90% of the way to making an OT algorithm work for arbitrary JSON structures (including object move), only to realise that it absolutely needs conflict markers so I put it down for awhile. I wrote a nodejs server from scratch thats compatible with google's browserchannel protocol - basically reimplementing TCP in the process. I implemented a PEG parser - and I'm going to need a session like this to add the ability to pass realtime streaming text updates through the parser. These sorts of things can't be reduced to 25 minute context increments. They just need too much mental state. Maybe once they're done they can be broken down into pieces that you could explain in 25 minute chunks. But figuring out that some particular abstraction is the right one requires fitting the entire system together in your head, so you can turn it around. And thats a spacing out in the shower followed by a day with a whiteboard kind of task. I guess the way I see it is that large amounts of uninterrupted time doesn't simply make it easier to do hard engineering. It makes it possible. Is that what the book refers to as deep work? If so then I think pomodoros are an anathema to that. |
I think if that's true, you should spend your time structuring a back-end such that other people in the organization can take the "technician" stuff off your hands. People who care most about those parts of the codebase. Potentially even non-engineer. Start them in a read-only front end app. It doesn't get you out of the woods, because you still have to support all of those people. But your real job is doing the hard engineering work to create a robust framework which is safe for people to build on top of.
In the long term, you'll spend part of your time basically teaching, and the other part of your time doing that gnarly researchy stuff you love.
And you could eventually opt out of teaching too, if you found someone on your team who likes that work. Then you're just the wizard deep inside the machine making magic happen. Your teammates would probably help. Good people will take as much of the responsibility as they can, since they don't want you as a bottleneck anyway.