IMO, all three phases have value. That first stage might feel like "what a fool I was", but in a lot of ways, that shit is enlightened! I think the problem comes when one of these approaches is applied, without context, to all problems.
I think it's a mistake to start a project in over-engineered phase, better to try 10 versions of rapid prototyping, and then as you start to get a sense of the problems, potential solutions, and where the risk is and what's worth investing in, bring in that pragmatism to tame the beast before it grows horns. And over time, as the requirements call for it, and only ever after it's needed, bring in that over-engineering (I guess at that point, it'd be just engineering?) And it's also super valuable to be able to scope which approach you take to which feature you're working on, all within the same code base. Risk, volatility, and uncertainty can vary from feature to feature and method to method.
They're all good, the flaw comes when you don't scope them and they get applied to problems they're a poor fit for. It's a gradient, don't invest in volatile code you might want to throw away tomorrow, and don't make a mess in code that's proven it's worth.
Make sure there is always someone smarter than you.
Not a prescription here, because I'm confident this suggestion is effective for many. For me, though, it was a bit paralyzing (I wasn't free to experiment or explore ideas if I wasn't incredibly confident in them, because I was too worried I'd look like a fool). What usually works for me is to always make sure I'm better than I was yesterday. It is valuable to check in and see where everyone else is from time to time, but it's better to rank myself against where I was than against where someone else appears to be. Also, pushing myself into my zone of discomfort. Basically, whatever it takes to stave off complacence and stagnancy.
You made some very good points here that first underline that people are different. That why I didn’t put “every developer” in the headline.
Regarding the phases: I still value them as experience but since I work in a large enterprise, 95% of my work needs to be high-quality maintainable code. So there is less room for experiments. However, we still do it from time to time intentionally and time-boxed. And what you describe is actually agile development. You start a small feature, put it out in the field quickly to get feedback and then change and add stuff iteratively.
Regarding the “find someone smarter”: that’s an exceptionally good thing if you are able to compare yourself objectively to older versions of you. But most of the time, I think the “frog slow cooked in a pot” metaphor applies where you are simply not aware of how it if you change and what might be an achievable goal.
I not sure if the bad experience you describe might be the result of a hazardous working environment fueled by seniors and managers that do not understand the value of making
mistakes?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
IMO, all three phases have value. That first stage might feel like "what a fool I was", but in a lot of ways, that shit is enlightened! I think the problem comes when one of these approaches is applied, without context, to all problems.
I think it's a mistake to start a project in over-engineered phase, better to try 10 versions of rapid prototyping, and then as you start to get a sense of the problems, potential solutions, and where the risk is and what's worth investing in, bring in that pragmatism to tame the beast before it grows horns. And over time, as the requirements call for it, and only ever after it's needed, bring in that over-engineering (I guess at that point, it'd be just engineering?) And it's also super valuable to be able to scope which approach you take to which feature you're working on, all within the same code base. Risk, volatility, and uncertainty can vary from feature to feature and method to method.
They're all good, the flaw comes when you don't scope them and they get applied to problems they're a poor fit for. It's a gradient, don't invest in volatile code you might want to throw away tomorrow, and don't make a mess in code that's proven it's worth.
Not a prescription here, because I'm confident this suggestion is effective for many. For me, though, it was a bit paralyzing (I wasn't free to experiment or explore ideas if I wasn't incredibly confident in them, because I was too worried I'd look like a fool). What usually works for me is to always make sure I'm better than I was yesterday. It is valuable to check in and see where everyone else is from time to time, but it's better to rank myself against where I was than against where someone else appears to be. Also, pushing myself into my zone of discomfort. Basically, whatever it takes to stave off complacence and stagnancy.
You made some very good points here that first underline that people are different. That why I didn’t put “every developer” in the headline.
Regarding the phases: I still value them as experience but since I work in a large enterprise, 95% of my work needs to be high-quality maintainable code. So there is less room for experiments. However, we still do it from time to time intentionally and time-boxed. And what you describe is actually agile development. You start a small feature, put it out in the field quickly to get feedback and then change and add stuff iteratively.
Regarding the “find someone smarter”: that’s an exceptionally good thing if you are able to compare yourself objectively to older versions of you. But most of the time, I think the “frog slow cooked in a pot” metaphor applies where you are simply not aware of how it if you change and what might be an achievable goal.
I not sure if the bad experience you describe might be the result of a hazardous working environment fueled by seniors and managers that do not understand the value of making
mistakes?