> You puke out a solution(minimum viable product), without thought about optimisation.
And that's where it ends, because unless your employer vastly overhired, there's already a dozen (or more...) of tasks in the backlog just waiting for you to vomit them out as well.
After a year or two of working like this, you have a mountain of technical debt and no time work on it all. The entire system slowly disintegrates under its own weight.
There needs to be a balance between fast and correct, and it is only up to the developer to resist the pressure from management to work fast (at the expense of correctness). I would go as far as to say that it is one of your main non-technical duties as a developer to resist and manage this pressure as best as you can.
Maybe you're a genius who can analyze problems and implement solutions both fast AND correctly, but that is very rare.
The truth is that complex problem solutions can have complex, messy implementations. They can also have simple, beautiful implementations. Or anything in between. But what they almost invariably require is complex investigations... which take time to conduct properly.
Most (not all!) "fast" programmers I've worked with over the last 15 years produced output of questionable quality, often stemming from the "what you don't know you don't know" part of the knowledge pie chart, instead of some deeply thought out cost/benefit calculation.
IMO if the code sticks around long enough to disintegrate under its own weight, than that code was a rousing success!
"Resisting management" is almost always a horrible idea. Code is only useful when it provides a solution at the right time for the right price. If not, it is no longer useful and the world moves on.
Overall quality is nothing more than a reflection of business maturity. Like a mighty old tree with a great big trunk. It has had time to grow strong and majestic.
Most businesses don't live longer than 5 years. Most products and solutions are temporary fixes or ideas that don't last longer than a few months. Investing huge amounts of time and resources into those things is a recipe for disaster.
I think this depends strongly on your companies bussines area. If you have BB with companies really relying on your product and long running contracts, the customer wants what he paid for. Including support for the heap of defects. Worse if you got a reputation to uphold and also want to keep your BB costumers. You can quickly become deadlocked in maintaining your old quick shots, unable to move anywhere.
I think it is hard to make general rules without specific market context.
Agreed. It's worth noting in the context you describe, you have valuable customers who have paid for long-running contracts. This warrants the ongoing time and investment in quality.
Most of the time, this is not the case.
My experience is of course mainly at startups, so I am most familiar with the shorter time-horizon, lower-cost initiatives.
> After a year or two of working like this, you have a mountain of technical debt
What's the reason to stay longer than 2 years? From what I see it's x10 times harder to get raise inside an organisation vs when changing it.
Probably, the reason is that companies adapted to employees getting rise and leaving soon. So a raise inside org is more a calibration for those highly underrated on entry ones than some real compensation for any experience.
As much as we want to pretend that slowness correlates with attention to detail and quality of code, this is often only rationalization. Some people are perfectionists (in a bad way) and overcomplicate things that don't really matter to the end result, others have analysis paralysis and take too long to make decisions, making the code suffer, and others are just not that great and generate the same result as a faster developer at best. There are surely good but slow developers, but it's not as common as "internet common sense" paints it.
And disavowing their role in cause and effect. They play chicken with other developers, who end I sacrificing their own productivity to fix the issues. Bad managers see this productivity gap and reward the hack instead of punishing him.
But not necessarily about the solution they envision. Case in point: I worked with one customer who wanted to add a search box at the top of a list to search through ~50 elements. I showed him the standard browser search with ^F and he was delighted. Saved us a day of work.
They know their problem, you should figure out a solution.
> You puke out a solution(minimum viable product), without thought about optimisation.
And that's where it ends, because unless your employer vastly overhired, there's already a dozen (or more...) of tasks in the backlog just waiting for you to vomit them out as well.
After a year or two of working like this, you have a mountain of technical debt and no time work on it all. The entire system slowly disintegrates under its own weight.
There needs to be a balance between fast and correct, and it is only up to the developer to resist the pressure from management to work fast (at the expense of correctness). I would go as far as to say that it is one of your main non-technical duties as a developer to resist and manage this pressure as best as you can.
Maybe you're a genius who can analyze problems and implement solutions both fast AND correctly, but that is very rare.
The truth is that complex problem solutions can have complex, messy implementations. They can also have simple, beautiful implementations. Or anything in between. But what they almost invariably require is complex investigations... which take time to conduct properly.
Most (not all!) "fast" programmers I've worked with over the last 15 years produced output of questionable quality, often stemming from the "what you don't know you don't know" part of the knowledge pie chart, instead of some deeply thought out cost/benefit calculation.