Published 2025-11-21
tag(s): #link-post #random-thoughts #programming
There are two interesting side effects of using an RSS aggregator.
One of these additions to my feed is Rach Smith.
A few of her posts resonated with me. The one I am linking today, is a post that hits on one
of the topics in my "to blog" list, so here we are :)[1]
A highly edited quote:
Sometimes I get asked by newcomers how one can become a developer like me [...]
If I had to pick one trait, it would be the ability to be comfortable with "the struggle". That part of the day/hour/minute where the code isn’t doing what you expected, things aren’t looking like they should, or where things are going wrong and you don’t know why. [...]
The full post is here. I recommend giving it a full read. It is short, insightful, and goes down a different road than this one.
Despite being stereotyped as the grumpiest group of people in any
organizations[2], I have the theory that the only way you can make your
career as a developer is if you are full of a very naive optimism.
And maybe lots (most? many?) developers are grumpy because they spent all their jolliness in
the technical side of things.[3]
As I established
in my last
post, I think writing software is potentially a very creative act.
And it is closer to writing prose than erecting a building, or any other "engineering
ideal" that some people like to lean into.
Following from that, what happens when you are hired to work in say, a mid-sized project?
Well, after a bit of time, you are given access to the code, and some minor task to
accomplish.
Let use again the "writing a novel collaboratively" analogy I brought up before.
You join a group of 5 other authors. 3 of them weren't there when the 850 page novel was
started.
Also the ending for the novel was changed a few times. One of the main characters was
removed from the story. Another one was changed from minor character to protagonist, but her
personality is totally different now.
Shortly after you join the group, one of the other authors says: "I think you have a clue of
this goes by now. So in chapter 27, change a few paragraphs so the dialogue flows better".
With the expectation that whatever changes you make follow continuity, style, and story
details coming before and after that chapter.
Any sane person would site down, open the source code the novel's manuscript and break
down crying.
How can they expect you to make these changes, without altering the continuity, unless you
read the whole novel at least once? Not that it is a bullet proof plan, because by
the time you finish it, other people in the group will have made changes too.
At face value, it is an impossible task.
And here comes the connection with Rach's post. Developers struggle, a lot. Not only in the
cases she mentions (which by the way are very real).
We feel also feel overwhelmed. We make changes in the dark, a bit by instinct and a lot by
hoping this is the right thing.
There are mitigations. You consult with other authors. Take a look at other chapters where the
same characters interact.
But you have to, as Rach says, enjoy the struggle. Even revel in it, and she hints at the end
of her post. :)
Developers are, in general, notoriously bad a estimating.[4]
And I have the theory that the same traits that makes us functioning developers, make us bad
estimators.
And by the way, that's also why we aren't good at identifying potential blockers and bad
requirements.
You enjoy struggling. And you also think that even if there are a gazillion things you don't
know, with a little more time, and a little more trying, you will solve whatever it is that
you are being asked to do.
And when approach your work such naivety, such innocence...does anyone really expect you to
have an accurate idea of how long the task will take? That's why we end up with rule of thumb
that are more or less "multiply you initial estimate by 500".