4 ms·

This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". You need to

This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.

tsimionescu 6y ago
I think it's important to note here that you need to start your thinking or design from the simplest possible solution, but that doesn't mean it always makes sense to actually implememt that solution.
- justin_oaks 6y ago
  Agreed. That's why I advise to start simple/stupid, not necessarily deploy the stupid solution. It's a direct response to those who start out with crazy-complicated schemes in mind.
ryandrake 6y ago
I wonder if there is something going wrong in the software engineering education pipeline that is encouraging developers to always keep reaching for the most complex tool in the toolbox rather than the simplest. We all see this all the time, so the problem is widespread. Maybe it’s not education but career growth: It sounds like “resume-driven development” where people are incentivized to add complex tools to their toolbox merely so they can get hired at places that select for complex tool use.
- anaerobicover 6y ago
  I think it's just inherent in the personality types that are successful at software. We are good at understandinging complex things, and we like it; it makes us feel good to master them, and creating one is a special variety of mastery, so we incline towards that. I think it also takes experience to see that simple solutions can be more robust; the more natural response to foreseeing future problems (another trait) is to have specific responses for all of them, which generates a complex result.
- BlargMcLarg 6y ago
  I hear this often, and I see many on HN be in favor of this narrative, but I have the opposite experience. Its often the cargo-culting companies pushing these soft requirements onto education, as students and companies will otherwise complain about not being employable / finding starters who reach their expectations respectively. Most of the time, I see seniors reach for overly complicated solutions, when much simpler solutions exist. Which later falls apart when errors happen silently and simple ideologies like "single truth" are ignored for no particularly good reason, leading to massive duplicate code and gotchas. At this point, I'm extremely unconvinced the problem is just education or juniority/seniority. The "paper factory" is just doing what companies are demanding. The real problem is a general lack of competence being used to market products, be they good when used properly (e.g. GoF, where many readers only look at design patterns and completely forget "composition over inheritance"), or snake oil.
- justin_oaks 6y ago
  Sometimes people haven't been exposed to different ways to solve problems, so they reach for the first thing that comes to mind. Sometimes the never learn to consider multiple solutions and weigh their costs and benefits. I once had a boss who still coded, even though all the developers begged him to stop. His code was spaghetti, but worse was his inability to come up with more than one solution to a problem. If the first solution he came up with was complicated and error-prone then that's the one he proceeded with.
- pdimitar 6y ago
  In my experience the most common cause for this phenomena is that the devs are afraid they won't be employable if they don't utilize those fads or, as you very correctly summarized it: resume-driven development.
BoiledCabbage 6y ago
> This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". > You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough. 100% true. People love to dig at Test Driven Development, but it solves a common problem and is great for junior developers because it has 3 important rules. 1. Understand your requirements. And not in a wishy-washy hand-wavey way. But in an explicit, expressed as a single test verifiable/falsifiable requirement. 2. Implement the simplest solution that meets your requirements. Don't over-engineer anything, don't chase the latest fad, don't sleeve solve a way more complicated generic problem that you think we'll hit later, because you don't have enough experience to know how likely we are to hit it and the costs to make that tradeoff. 3. Keep you codebase clean and well factored. Don't let cruft and hacks build up. Ignoring TDD, any junior engineer that can consistently exhibit those three behaviors is almost by no longer a junior engineer. Those are hard things to learn as an early coder. Yes as you become mid-level and senior you should be more independent and break the above often - but at that point you have good foundations and the experience to make the tradeoffs to know when to deviate and by how much. TDD is a very effective method for solving a problem that otherwise often takes a while to solve. Developing good fundamentals.
- pdimitar 6y ago
  > 3. Keep you codebase clean and well factored. Don't let cruft and hacks build up. I feel obliged to mention that this very often goes against "do the stupidest thing that will work". Most of the time in my career a clean codebase has naturally led to an intelligent solution which is definitely not the stupidest thing that will work. Finally, it's also often the case that stupid code requires exorbitant amounts of comments or documentation, undermining the notion of it being simple to extend (which many conflate with the original premise). A little bit more intelligent code is usually self-describing.

tsimionescu 6y ago

I think it's important to note here that you need to start your thinking or design from the simplest possible solution, but that doesn't mean it always makes sense to actually implememt that solution.

justin_oaks 6y ago
Agreed. That's why I advise to start simple/stupid, not necessarily deploy the stupid solution. It's a direct response to those who start out with crazy-complicated schemes in mind.

ryandrake 6y ago

I wonder if there is something going wrong in the software engineering education pipeline that is encouraging developers to always keep reaching for the most complex tool in the toolbox rather than the simplest. We all see this all the time, so the problem is widespread. Maybe it’s not education but career growth: It sounds like “resume-driven development” where people are incentivized to add complex tools to their toolbox merely so they can get hired at places that select for complex tool use.

anaerobicover 6y ago
I think it's just inherent in the personality types that are successful at software. We are good at understandinging complex things, and we like it; it makes us feel good to master them, and creating one is a special variety of mastery, so we incline towards that. I think it also takes experience to see that simple solutions can be more robust; the more natural response to foreseeing future problems (another trait) is to have specific responses for all of them, which generates a complex result.
BlargMcLarg 6y ago
I hear this often, and I see many on HN be in favor of this narrative, but I have the opposite experience. Its often the cargo-culting companies pushing these soft requirements onto education, as students and companies will otherwise complain about not being employable / finding starters who reach their expectations respectively. Most of the time, I see seniors reach for overly complicated solutions, when much simpler solutions exist. Which later falls apart when errors happen silently and simple ideologies like "single truth" are ignored for no particularly good reason, leading to massive duplicate code and gotchas. At this point, I'm extremely unconvinced the problem is just education or juniority/seniority. The "paper factory" is just doing what companies are demanding. The real problem is a general lack of competence being used to market products, be they good when used properly (e.g. GoF, where many readers only look at design patterns and completely forget "composition over inheritance"), or snake oil.
justin_oaks 6y ago
Sometimes people haven't been exposed to different ways to solve problems, so they reach for the first thing that comes to mind. Sometimes the never learn to consider multiple solutions and weigh their costs and benefits. I once had a boss who still coded, even though all the developers begged him to stop. His code was spaghetti, but worse was his inability to come up with more than one solution to a problem. If the first solution he came up with was complicated and error-prone then that's the one he proceeded with.
pdimitar 6y ago
In my experience the most common cause for this phenomena is that the devs are afraid they won't be employable if they don't utilize those fads or, as you very correctly summarized it: resume-driven development.

BoiledCabbage 6y ago

> This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". > You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough. 100% true. People love to dig at Test Driven Development, but it solves a common problem and is great for junior developers because it has 3 important rules. 1. Understand your requirements. And not in a wishy-washy hand-wavey way. But in an explicit, expressed as a single test verifiable/falsifiable requirement. 2. Implement the simplest solution that meets your requirements. Don't over-engineer anything, don't chase the latest fad, don't sleeve solve a way more complicated generic problem that you think we'll hit later, because you don't have enough experience to know how likely we are to hit it and the costs to make that tradeoff. 3. Keep you codebase clean and well factored. Don't let cruft and hacks build up. Ignoring TDD, any junior engineer that can consistently exhibit those three behaviors is almost by no longer a junior engineer. Those are hard things to learn as an early coder. Yes as you become mid-level and senior you should be more independent and break the above often - but at that point you have good foundations and the experience to make the tradeoffs to know when to deviate and by how much. TDD is a very effective method for solving a problem that otherwise often takes a while to solve. Developing good fundamentals.

pdimitar 6y ago
> 3. Keep you codebase clean and well factored. Don't let cruft and hacks build up. I feel obliged to mention that this very often goes against "do the stupidest thing that will work". Most of the time in my career a clean codebase has naturally led to an intelligent solution which is definitely not the stupidest thing that will work. Finally, it's also often the case that stupid code requires exorbitant amounts of comments or documentation, undermining the notion of it being simple to extend (which many conflate with the original premise). A little bit more intelligent code is usually self-describing.