> Experience is what you get when you don’t have any.
The only better experience than working on a legacy codebase is working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions.
Code is a pure liability that you accept to get a useful service.
Not that I game that obviously, it just occurred naturally for a ~4 month period
How 'bout job security?
But when it was finished it failed to meet the basic requirements for the only customer that used the system.
But yes, it's sad.
One of the tells of an inexperienced engineer I use is how much they disparage the previous team's work.
And many fail to discern between "disparage" and "critique" or even "Question in order to learn"
One of the greatest failings I've seen in leadership in our time is the idea that in order to make a critique one must come with a solution in hand. As a leader I want to know the things that are going wrong as soon as they're seen, not to require someone to go through the heavy lifting of a solution before they say a word. Now, of course, there's a difference between bitter unhelpful cynicism, and simply identifying a gap between the current state and optimality.
I think I’ve had the conversation with new to my organization devs a few hundred times: “Look... saying code is crap or stupid is telling others you’ve given up on learning. How about asking why it is the way it is?”
> greatest failings I've seen in leadership in our time is the idea that in order to make a critique one must come with a solution in hand.
The pattern works at very high levels in an org chart, but with developers and those that manage them it breaks the whole concept of problem solving. You have to be able to identify and understand problems before you can come up with a solution... and usually, with software, the solution is developer hours.
It really isn't. A lot of the time you end up spending a lot of effort to understand something that was dumb to start with and has been dumb ever since. Something like the bullshit asymmetry principle applies - any idiot can take 5 minutes to write a line of code that will baffle a team of experts for hours. (I've done so often enough myself).
When your v1 code takes a company to profitability it was good enough.
Edit: oh and how could I forget as simple and readable as possible
"The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one."
Brooks reasons that the combined experience of doing the first project well and the second project badly leads to better designs from then on.
I'm not granting a "rewrite from scratch in Rust" exception even though that's in vogue right now. I'm not saying don't rewrite it in Rust, I'm saying don't rewrite it from scratch. It's harder to write new features in Rust while maintaining the old C code, but it's the right way to do it.
The latter is less costly and only requires you "only" to open your eyes and look at projects that are in an ugly state the right way. Yet surprisingly few people are capable of looking at someone elses fucked up project and not going all like: "Hah! Idiots! I would never have made that decision".
Maybe however that crusty piece of code used a framework that — back in the day — was the hottest, trendiest piece of technology out there and you are currently in the process of committing similar sins, and you won't know it till it is too late.
For me adminstration of Linux servers has been an invaluable source of inspiration. You are directly and 100 percent exposed to the effects of software aging in a changing environment. And you directly wittness which software ages like fine wine and which ages more like milk.
Now I'm curious. What software has aged well? What software hasn't? Do certain types or categories of software tend to age better or worse?
There is no teacher quite like cause and effect.
No, growing as an engineer just means the reality of software development will make you more miserable.
> I think jumping around can risk creating an engineer who leaves a place worse than when they started.
Of course it does, but companies have made the choice to pay more for that than for someone who stays and makes the place better, we should give them what they want.
These aren't mutually exclusive.
> If you like your employer and colleagues and are growing as an engineer isn’t that better in the long term?
Better than liking your employer and colleagues and growing as an engineer and also having more money? No.
This isn't a field with low demand for talent. You can have all these things--don't settle for less.
> I think jumping around can risk creating an engineer who leaves a place worse than when they started.
That's a risk that companies should be willing to pay to avoid.
But a lot of companies aren't willing to given their engineers adequate pay increases each year, and it's not engineers' responsibility to accept less money than they are worth. If you want more experienced engineers, you have to pay for more experienced engineers. That's just basic free market economics: if you don't like that you don't like capitalism.
Some companies understand this and do better, but these are the exceptions not the rule. If you find such an exception, stick with them!
I fundamentally disagree with the narrative that engineers are supposed to be passionate about their craft and learning and interest and not care about the money. That's propaganda spread by corporations to get us to accept less pay, and if you believe it you'll be exploited. And as it turns out, the places that pay the best are also usually the best places to be passionate about your craft, so there's no real conflict. The places that pretend to pay you in learning and passion instead of money generally don't deliver on the learning and passion either.
Having the context or, better yet, responsibility for the past decisions is great for developing a pragmatic approach to software design AND empathy for other software engineers.