3 lines of code shouldn't take all day

In 1989, I was working at my first (very short lived) US job, for Bell Labs (not the Bell Labs, but related). I was working on their "office-scale" phone switches, the kind that allowed you to forward a call from one extension to another. There was a hard-coded limit of (I think) 16 forwards, and for some reason it was decided to increase this to (I think) 64. This involved changing a constant in a header file, a documentation string and one conditional in the code that for some reason didn't use the constant.

Expected time for this work was: 1 week.

Well, yesterday I made a rather significant change to the code. Essentially, a reimplementation of an existing function in a completely different way, to avoid a memory consumption issue that cannot be solved in the old approach. 68 insertions, 15 deletions. It, unexpectedly, worked correctly and passed all tests from the first attempt, even though there are threads involved, and they are my weak point. But I didn't have a "Huh... that's pretty cool" moment. I had an "I don't like this code, it's too complex, it must be wrong somehow" moment.

> working on other people's projects instead of starting my own feels like losing at this point - no READMEs, no automated CI, no Ansible, no Dockerfiles, no IDE run profiles, no common linting rules, no code static analysis, no local DBs with migrations, no local setup scripts etc.

You hit the nail on its head here, my friend.

When working with others' projects, I try to add tests where I've added/modified features, so that at least I can get a sense of it all and make sure I don't break anything. And for a completely untested codebase, it might make sense to add more integration-like tests (while still using mocks for external dependencies), such that simultaneously a bigger proportion of the codebase is covered, even if at slightly longer test times.

From a systems perspective, there is a balance to be achieved.

You want faster iteration times in order to provide feedback, but if they're too fast then you neglect other things or end up swinging wildly. Consider a thermostat that turned on the heat or cooling at just .1 degree below or above its target, or turned it off as soon as it hit the reverse. Or if because the feedback comes in as a torrent of data you attend to that feedback instead of other elements of the system or your capabilities.

As a system gets more complicated you have more factors to consider. In the case of programming, if you rely too much on that near-instant feedback, how much are you internalizing about your system, language, and environment? How often are you making the same errors but recovering quickly (so it's not slowing you down too much, or doesn't appear to be slowing you down too much) because of the feedback? How much faster could you ultimately be if your work were smoother and not so rough and jagged?

Introducing a delay, here, gives you time to contemplate. Even if it's just taking an hour or two a day to sit back from the keyboard and ponder what you've done that day and what you will do the next. Create a plan instead of jump into action, even if the plan doesn't get executed perfectly or ends up being the wrong plan that bit of contemplation is when you learn.

But too long a delay (especially a forced delay) causes other problems. The actually needed feedback (not just compiler errors and such, but your V&V issues discovered from testing and evaluation) getting delayed by a day or more can be too much (especially when working with a team, where other parts are potentially changing around your own changes). Too long a delay also promotes batching many unrelated changes together because you don't want to sit through the whole process again. Consider a system that takes a week or a month to get feedback from an external test team, you'd be tempted to throw many changes at them because of that week or month long delay (or more!) and not just one change.

So strike a balance, find a point where your iteration cycle permits you time to think and not just act so you can really learn (both programming and the particular system you're trying to develop). Smooth out your development so that you're slowed down not by having to take corrective steps but having to ponder logical steps. "Is this the right data structure? Well, if I isolate it in my domain model then I can swap it out later and no one will be impacted." or "I'll take a walk around the building and think about what I actually need here."

"No one has Borgmon readability."