4 ms·

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 decisio

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

calebpeterson 2y ago
So true!
fjjjrjj 2y ago
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 2y ago
  The best code is the code that doesn't exist.
  - antisthenes 2y ago
    Certainly the most secure code. Not sure about best.
    - ticklemyelmo 2y ago
      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 2y ago
        exactly..which is also why lines of code written is one of if not the worst possible metric of productivity. easy to game too.
        escapecharacter 2y ago
        I marked my transition to senior engineer when my net lines of code flipped to negative. Not that I game that obviously, it just occurred naturally for a ~4 month period
      - bell-cot 2y ago
        > Better on every axis... How 'bout job security?
        rzzzt 2y ago
        Anyone can write no code.
        MonkeyClub 2y ago
        But it takes a master to not write the write piece.
- lawn 2y ago
  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 2y ago
    Once you're senior enough those cases won't be funny any more, just sad.
    - lawn 2y ago
      I have a very dark sense of humor sometimes. But yes, it's sad.
- Cthulhu_ 2y ago
  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 2y ago
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.
- philote 2y ago
  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 2y ago
    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.
- maerF0x0 2y ago
  > 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 2y ago
    > 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.
beoberha 2y ago
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
jcheng 2y ago
Second System Syndrome! :) https://en.m.wikipedia.org/wiki/Second-system_effect https://en.m.wikipedia.org/wiki/Second-system_effect
pjmorris 2y ago
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.
purplethinking 2y ago
And the only better experience than that is that all software is pain
kerkeslager 2y ago
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.
rcxdude 2y ago
AKA fighting the last war. Can be difficult not to focus on trying to avoid painful things from past projects, though.

calebpeterson 2y ago

So true!

fjjjrjj 2y ago

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 2y ago
The best code is the code that doesn't exist.
- antisthenes 2y ago
  Certainly the most secure code. Not sure about best.
  - ticklemyelmo 2y ago
    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 2y ago
      exactly..which is also why lines of code written is one of if not the worst possible metric of productivity. easy to game too.
      - escapecharacter 2y ago
        I marked my transition to senior engineer when my net lines of code flipped to negative. Not that I game that obviously, it just occurred naturally for a ~4 month period
    - bell-cot 2y ago
      > Better on every axis... How 'bout job security?
      - rzzzt 2y ago
        Anyone can write no code.
        MonkeyClub 2y ago
        But it takes a master to not write the write piece.
lawn 2y ago
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 2y ago
  Once you're senior enough those cases won't be funny any more, just sad.
  - lawn 2y ago
    I have a very dark sense of humor sometimes. But yes, it's sad.
Cthulhu_ 2y ago
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 2y ago

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.

philote 2y ago
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 2y ago
  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.
maerF0x0 2y ago
> 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 2y ago
  > 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.

beoberha 2y ago

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

jcheng 2y ago

Second System Syndrome! :) https://en.m.wikipedia.org/wiki/Second-system_effect https://en.m.wikipedia.org/wiki/Second-system_effect

pjmorris 2y ago

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.

purplethinking 2y ago

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

kerkeslager 2y ago

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.

rcxdude 2y ago

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