3 ms·

> But sometimes you’re working in a codebase which will probably outlive you. This is so rare, it's not worth thinking about. Code lasts a decade or two before

> But sometimes you’re working in a codebase which will probably outlive you. This is so rare, it's not worth thinking about. Code lasts a decade or two before it's been completely rewritten or replaced. After 30 years, the oldest code that I ever touched exists in very few places (2 that I know of). > Spending effort making tending the garden delightful will almost always pay off given enough time. What constitutes "good practice" is ever-changing and it doesn't add business value. You work within the constraints of the time and move on. The people who do this find themselves in the best position, career-wise. Paying some small attention to maintenance helps you move up and on to bigger projects and responsibility. Like all things, pursue a middle ground of philosophy. ie You can fiddle with code forever trying to make it "better". More extensible, more maintainable, more clear, more more more. Arguing over future cases (premature planning) is the most common sin. Planning for everything to be reused is not being efficient. Regardless, you have biases that inform what you think is "better" and how software will be used, which future you (and other developers) will note share.

josephg 4y ago
> Arguing over future cases (premature planning) is the most common sin.. There's definitely a scale between "unmaintainable mess" and "architecture astronomy" where both extremes are pathological. I've seen plenty of unmaintainable messes in my time - particularly from average teams who are lacking in good technical leadership. You see this sort of thing all the time in consulting, and in software teams at non-software companies. (Eg, in the airline industry). There's a reason why Martin Fowler talks a lot about software craftsmanship - because at places like Thoughtworks they could often use more of that sort of thinking. I've also seen plenty of overengineered messes too. Most smart college students (myself included) seem to need to go through this at some early point in our careers, where we really spread our wings and discover first hand why writing thousands of java classes is a terrible idea. (Or whatever the poison of the day is). If all your abstraction does is move your food (business logic / algorithms) around the plate, or -worse- hide it, then your abstraction is making the code worse. I have no idea which sin is more common. I think it really depends on what sort of engineers you spend time with. Google definitely suffers from the second kind of problem much more than the first - to the point where google (hilariously) often outsources making actual websites to external consulting companies, because their own software practices are too expensive to implement. Does your team need more long term thinking or more short term thinking? Its impossible to answer without reference to your actual team, your existing practices, and what you're trying to deliver. A weekend game jam should be scrappy, and the code for the space shuttle should be written carefully. Neither approach is objectively good or bad; there's just different tradeoffs appropriate for different kinds of project. The best senior programmers can switch style & philosophy based on whats needed for the task sitting right in front of them.
- resonious 4y ago
  > the code for the space shuttle should be written carefully Couldn't help but remember the comments in the Apollo-11 source code saying "TEMPORARY, I HOPE HOPE HOPE". https://github.com/chrislgarry/Apollo-11/blob/a13539c7c5c482ffbbebf099ad3aada7d0f54fdf/Luminary099/LUNAR_LANDING_GUIDANCE_EQUATIONS.agc#L179-L180 https://github.com/chrislgarry/Apollo-11/blob/a13539c7c5c482...
quanticle 4y ago
This is so rare, it's not worth thinking about. It might be rare in the sense of code that will be around after you're dead. But it's probably not rare in the sense of code that will be around after you've left the company.

josephg 4y ago

> Arguing over future cases (premature planning) is the most common sin.. There's definitely a scale between "unmaintainable mess" and "architecture astronomy" where both extremes are pathological. I've seen plenty of unmaintainable messes in my time - particularly from average teams who are lacking in good technical leadership. You see this sort of thing all the time in consulting, and in software teams at non-software companies. (Eg, in the airline industry). There's a reason why Martin Fowler talks a lot about software craftsmanship - because at places like Thoughtworks they could often use more of that sort of thinking. I've also seen plenty of overengineered messes too. Most smart college students (myself included) seem to need to go through this at some early point in our careers, where we really spread our wings and discover first hand why writing thousands of java classes is a terrible idea. (Or whatever the poison of the day is). If all your abstraction does is move your food (business logic / algorithms) around the plate, or -worse- hide it, then your abstraction is making the code worse. I have no idea which sin is more common. I think it really depends on what sort of engineers you spend time with. Google definitely suffers from the second kind of problem much more than the first - to the point where google (hilariously) often outsources making actual websites to external consulting companies, because their own software practices are too expensive to implement. Does your team need more long term thinking or more short term thinking? Its impossible to answer without reference to your actual team, your existing practices, and what you're trying to deliver. A weekend game jam should be scrappy, and the code for the space shuttle should be written carefully. Neither approach is objectively good or bad; there's just different tradeoffs appropriate for different kinds of project. The best senior programmers can switch style & philosophy based on whats needed for the task sitting right in front of them.

resonious 4y ago
> the code for the space shuttle should be written carefully Couldn't help but remember the comments in the Apollo-11 source code saying "TEMPORARY, I HOPE HOPE HOPE". https://github.com/chrislgarry/Apollo-11/blob/a13539c7c5c482ffbbebf099ad3aada7d0f54fdf/Luminary099/LUNAR_LANDING_GUIDANCE_EQUATIONS.agc#L179-L180 https://github.com/chrislgarry/Apollo-11/blob/a13539c7c5c482...

quanticle 4y ago

This is so rare, it's not worth thinking about. It might be rare in the sense of code that will be around after you're dead. But it's probably not rare in the sense of code that will be around after you've left the company.