[calebpeterson]

I once had a manager that was fond of saying:

> 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.

[namdnay]

And the only better experience than "working on a greenfield project long enough to watch it become legacy and see the good and bad consequences of past decisions" is working on a second greenfield project long enough to see that drastically overcompensating for all the bad things from the first one is not the right solution either :)

[pjmorris]

Fred Brooks has a whole chapter, 'The Second System Effect', on this in 'The Mythical Man Month.'

"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.

[fjjjrjj]

And the only better experience than that is killing a new greenfield project before it gets to production because the old software was good enough and the problems were organizational in how the software was being used.

[4ndrewl]

The best code is the code that doesn't exist.

[antisthenes]

Certainly the most secure code. Not sure about best.

[ticklemyelmo]

Better on every axis: security, performance, resource consumption, reliability, verification, documentation...

Code is a pure liability that you accept to get a useful service.

[greenchair]

exactly..which is also why lines of code written is one of if not the worst possible metric of productivity. easy to game too.

[bell-cot]

> Better on every axis...

How 'bout job security?

[lawn]

I thought it was pretty funny how we had this large project that was supposed to replace a legacy system (that was mostly a bad hack that got pushed to production).

But when it was finished it failed to meet the basic requirements for the only customer that used the system.

[lmm]

Once you're senior enough those cases won't be funny any more, just sad.

[lawn]

I have a very dark sense of humor sometimes.

But yes, it's sad.

[Cthulhu_]

I wish this happened tbh. I've seen one where the greenfield (Scala, AWS, etc) is still living alongside the old good enough software they went back to (C# / .NET) ten years on.

[gorbachev]

I keep telling people v1 of anything always sucks.

One of the tells of an inexperienced engineer I use is how much they disparage the previous team's work.

[maerF0x0]

> 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.

[indymike]

> And many fail to discern between "disparage" and "critique" or even "Question in order to learn"

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.

[philote]

I always pick apart previous teams' work.. it's how I learn. I question most every decision because I'm curious why they made those decisions. And it lets me think about how I'd do it better. And yes, I know that many poor decisions are not necessarily the developer's fault. It could be bad specs, lack of time, etc.

[bdcravens]

In most cases, "better" means different things in different contexts. (Customer-driven vs performance-driven, for example) Of course, this isn't news for most of us. Where I think a lot of us fall short is assuming that definition has changed since the code was written.

[belthesar]

This harkens back to Chesterton’s Fence. It’s always worthwhile to interrogate why things were done the way they were, especially when first coming onto a project. Knowing the why of a decision is essential to understanding if and how it should be changed. Especially if the reason is “this is what we had the time and knowledge to do at the time.”

[lmm]

> It’s always worthwhile to interrogate why things were done the way they were

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).

[darepublic]

The people who have those answers have long gone. The only person left is a project manager who tells you it's up to you to figure it out. After you make a change in production they will come to you with questions after a few months, just when you assumed things must have gone well

[throwaway422432]

They usually shut up when they realise the "previous team" was one of the founders who is paying their wage.

When your v1 code takes a company to profitability it was good enough.

[beoberha]

Oh man this one hits home. I don’t do much coding anymore but my general advice to folks I lead is you’re never going to be happy with how you did things and just make sure it scales and is well tested.

Edit: oh and how could I forget as simple and readable as possible

[kerkeslager]

At this point I just don't think total rewrites from scratch are a good idea, full stop. I've never seen a rewrite from scratch that didn't lose most of the learned solutions from the previous attempt, repeat most of the same mistakes and have to re-discover the solutions, and utterly fail to even attempt a passable improvement on a model of the core complexity of the problem being solved.

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.

[jcheng]

Second System Syndrome! :)

https://en.m.wikipedia.org/wiki/Second-system_effect

[rcxdude]

AKA fighting the last war. Can be difficult not to focus on trying to avoid painful things from past projects, though.

[purplethinking]

And the only better experience than that is that all software is pain

[calebpeterson]

So true!

[atoav]

I always tend to say: "Everybody learns better from their own mistakes, but if you are empathic you can also learn from other people's mistakes".

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.

[globnomulous]

> 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?

[quickslowdown]

cURL is my personal go-to when discussing things like this. The Unix implementation is old, stable, functional, and has changed elegantly with the times.

[pavel_lishin]

Especially when they're your decisions, decisions you pushed for and felt very good about at the time.

[calebpeterson]

Yep!

There is no teacher quite like cause and effect.

[TeMPOraL]

Reinforcement learning, as usual, for the win!

[regularfry]

This is literally the approach recommended in Team Topologies. The same team should own vN and vN+1, so that they both have to operate their own design and have the opportunity not to make the same mistakes again. It should be the default.

[rafaelmn]

That would require staying in one company for more than 2 years, which means you probably lost out on 20-30% of income over next 2 years.

[jorgesborges]

It’s okay to enjoy work and focus on your craft for two years rather than jump for more money. If you like your employer and colleagues and are growing as an engineer isn’t that better in the long term? I think jumping around can risk creating an engineer who leaves a place worse than when they started.

[lmm]

> If you like your employer and colleagues and are growing as an engineer isn’t that better in the long term?

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.

[kerkeslager]

> It’s okay to enjoy work and focus on your craft for two years rather than jump for more money.

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.

[regularfry]

It does not. It requires the team to be stable. It says nothing about the composition of that team.

[pz]

In particular, I appreciate that you assign value to the consequences and not the decision itself. Anytime junior engineers on my team would complain about "shitty code" I'd assure them that someone would be complaining about their code in a few years.

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.

[ixtli]

Came here to say this. Ive had to work on slop, and it never stops being slop unless the stars align and you can do a bunch of work which is short term unprofitable. What people really should do is work on the same project for five years. Watch the interest wax and wane and more importantly watch the requirements change. Then you'll stop looking at things in black and white like "good project bad project"

[softfalcon]

Too bad a lot of devs love to greenfield, slap it together, then bugger off to the next project pronto.

[lmm]

When that's both more pleasant and better paying, who can blame them?

[svachalek]

"You either die a hero or you live long enough to become the villain"

[calebpeterson]

Never thought of that in the context of software projects. It works really well!

[konfusinomicon]

oh the hills that were conquered and those to have died upon, captain hindsight strikes again!

[hinkley]

Come on to a brownfield project and ask a lot of pointed questions about how we got here.