4 ms·

Pragmatic programmer does a decent job of it. Not perfect, but decent enough. I'm of the school that thinks it's something you need to practice. Many software

by waheoo 6y ago

Pragmatic programmer does a decent job of it. Not perfect, but decent enough. I'm of the school that thinks it's something you need to practice. Many software positions especially in large companies are very limited in scope, you basically just maintain and patch existing systems, rarely having to build systems from scratch. Building these systems from the ground up is what is hard but you learn what works and what doesn't the more you do it. If you want to learn how to build software, join a start up or small company that has a healthy appreciation for what software rewrites can provide. Run away from companies that follow the never rewrite mantra. Usually saying something like you'll just repeat mistakes, its like well no shit this thing was built before I was born, if you rebuilt it with me here I could avoid those mistakes. I'm not saying you should always rewrite, its usually better to refactor, but some design failures are hard to refactor out, have double binds or are too critical for stability woes. But systems that live forever should have unlimited quality assurance budgets for refactor and repair, very few do in this industry. Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane. Like running a machine in a factory 24/7 and never doing maintenance but expecting it to work perfectly like new forever with no future cost incurred as eventual debt.

Twisol 6y ago
> Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane. Preach it! I don't know where this mentality comes from, but it seems to treat software as something that just magically solves problems and only needs a little upkeep to chug along. The problem is that problems change, and a different problem is no longer necessarily a solved problem. It takes a lot of design effort to make something that can easily be adapted to changes in the problem space, and it still requires effort to make sure the software doesn't specialize itself over time into a corner.
- waheoo 6y ago
  Yup! And then sometimes it's actually advantageous to specialise systems into a corner, it has benefits, but these decisions need to be considered and made with care, and then it needs to be an understood limitation going forward that it can't be rolled back at a later time without a high cost. Thinking about the above further I notice the things I've learned over the years also require the ability to link problem to cause, or in my case it came in reverse, cause linked to problem. I ran into problems for years, learned how to fix them, and then during code reviews (even in self review), discovered the cause behind these problems. Sometimes these were causes that would only become problems at a later date because of knock on effects. I don't know how you teach that. Possibly antipatterns / code smells which usually hint at underlying problems that may be elsewhere / at a different level. Refactoring by Fowler and TDD by Beck cover a lot of these in good detail.
  - disgruntledphd2 6y ago
    Refactoring is an amazing book, but I think most people would be better served by starting with working effectively with legacy code, as it shows you how to get to a place where you can refactor confidently. The examples are kinda dated but the approach is pretty timeless.
    - chrisweekly 6y ago
      That'd be "Working Effectively with Legacy Code" by Feathers -- which I now look fwd to reading; thanks for the rec!
    - waheoo 6y ago
      I tend to disagree but this might be my biases at play. Refactoring starts from first principles, almost all examples include the reverse refactoring as often you need to undo optimisations a few steps before you can move forward in a different direction. I was recommended working effectively with legacy code by the same types of managers that expect forever returns off the same code. They like to point out how that book encourages small patching without refactoring as refactoring is often fruitless in short term money terms, whereas Fowler tends to advocate refactoring as a healthy and necessery part of software development. I can't say I hated working effectively. I found TDD by Beck more useful, and working effectively with unit tests to also be worthwhile. All of these books cover a lot of similar ground. If you're going to read only one or two I suggest TDD > refactoring and avoiding the others. (Just my opinion based on what I got out of them reading after 10 years on the job, I suspect juniors might have a different take)
      - disgruntledphd2 6y ago
        So, I love all of the books you've mentioned. However, I have ended up inheriting a pile of crappy code driving business value a bunch of times in my career (data science is much worse for this), so for me, Working Effectively was really really useful as it provided ways to deal with the craziness. As soon as I finished WELC, I ordered refactoring, and devoured it - but it is less practical for my situations, where there are no tests and nobody sees why they would even be useful. In terms of good and impactful reads, TDD is probably the most bang for my buck I've ever gotten, in that it's super short and very very good. Kent Beck is hilarious also, which definitely helps.

by waheoo 6y ago

Twisol 6y ago

> Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane. Preach it! I don't know where this mentality comes from, but it seems to treat software as something that just magically solves problems and only needs a little upkeep to chug along. The problem is that problems change, and a different problem is no longer necessarily a solved problem. It takes a lot of design effort to make something that can easily be adapted to changes in the problem space, and it still requires effort to make sure the software doesn't specialize itself over time into a corner.

waheoo 6y ago
Yup! And then sometimes it's actually advantageous to specialise systems into a corner, it has benefits, but these decisions need to be considered and made with care, and then it needs to be an understood limitation going forward that it can't be rolled back at a later time without a high cost. Thinking about the above further I notice the things I've learned over the years also require the ability to link problem to cause, or in my case it came in reverse, cause linked to problem. I ran into problems for years, learned how to fix them, and then during code reviews (even in self review), discovered the cause behind these problems. Sometimes these were causes that would only become problems at a later date because of knock on effects. I don't know how you teach that. Possibly antipatterns / code smells which usually hint at underlying problems that may be elsewhere / at a different level. Refactoring by Fowler and TDD by Beck cover a lot of these in good detail.
- disgruntledphd2 6y ago
  Refactoring is an amazing book, but I think most people would be better served by starting with working effectively with legacy code, as it shows you how to get to a place where you can refactor confidently. The examples are kinda dated but the approach is pretty timeless.
  - chrisweekly 6y ago
    That'd be "Working Effectively with Legacy Code" by Feathers -- which I now look fwd to reading; thanks for the rec!
  - waheoo 6y ago
    I tend to disagree but this might be my biases at play. Refactoring starts from first principles, almost all examples include the reverse refactoring as often you need to undo optimisations a few steps before you can move forward in a different direction. I was recommended working effectively with legacy code by the same types of managers that expect forever returns off the same code. They like to point out how that book encourages small patching without refactoring as refactoring is often fruitless in short term money terms, whereas Fowler tends to advocate refactoring as a healthy and necessery part of software development. I can't say I hated working effectively. I found TDD by Beck more useful, and working effectively with unit tests to also be worthwhile. All of these books cover a lot of similar ground. If you're going to read only one or two I suggest TDD > refactoring and avoiding the others. (Just my opinion based on what I got out of them reading after 10 years on the job, I suspect juniors might have a different take)
    - disgruntledphd2 6y ago
      So, I love all of the books you've mentioned. However, I have ended up inheriting a pile of crappy code driving business value a bunch of times in my career (data science is much worse for this), so for me, Working Effectively was really really useful as it provided ways to deal with the craziness. As soon as I finished WELC, I ordered refactoring, and devoured it - but it is less practical for my situations, where there are no tests and nobody sees why they would even be useful. In terms of good and impactful reads, TDD is probably the most bang for my buck I've ever gotten, in that it's super short and very very good. Kent Beck is hilarious also, which definitely helps.