3 ms·

> Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent. Don't over-generalize. There is a messy co

> Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent. Don't over-generalize. There is a messy code and there is a messy code. Changing shared data without synchronization is incompetence, but having a 3-page long for-loop is not. In reality though, once you've cleaned stables a dozen times spaghetti code is the red flag of incompetence and the correlation is there.

zzalpha 11y ago
> once you've cleaned stables a dozen times spaghetti code is the red flag of incompetence and the correlation is there. Question is, where's the incompetence? Yup, like any profession, there are developers out there who just suck. But the same is true of middle and senior company management. Can you honestly say you've never cut a corner because some incompetent manager mismanaged the schedule or customer expectations and then forced you to compromise quality in order to meet an absurd date? And in any organization with that type of management, those issues are rarely isolated. Any one manager can do a little damage, but when an organization is dysfunctional, well-meaning coders on the ground may be forced to compromise code quality time and time again in order to deal with unrealistic schedules. Think of it like a professional sports team. Sometimes, yeah, the players just suck. But a bad coach or general manager can have an outsized effect on an organization. Now, I would never claim that all bad code is a product of bad management. Again, some folks just suck at their job. But speaking as a guy in middle management, I'd be willing to believe at least half of the bad code lying around in the real world is a product of an incompetent management structure. Getting back to the article, that would represent the kind of hidden incentive that would cause an outsider to assume developer incompetence, even though the reality is very much different.
swanson 11y ago
I absolutely agree that there exists terrible code and that there are incompetent individuals or folks that simply don't care. But if one assumes that as the default response, I don't think that is very helpful. Even in your example of shared data/synchronization - what if the original developers were told that the code would never need to be thread-safe? Or what if there was a constraint that required this trade-off to be made? It's not so black and white.
- evilduck 11y ago
  Hell, even incompetent looking code (like managing shared resources poorly) can often be explained by a small script done by an amateur turning into a side business and then a full fledged company. Experience and knowledge of an industry beyond software is often many times more valuable than the knowledge of parallel programming. It doesn't mean the code wasn't valuable or good enough at the time, it just no longer meets the rigor and demands, that's why you're employed to work on it. To call everything shitty thats's below your own standards, level of education and experience is a naive view of how software actually exists in the world. Especially when the standard advice given to "idea people" is to learn to code their idea themselves.
- lmm 11y ago
  It is helpful. It gives you the confidence to change things. It allows you to feel productive. And it's true often enough that it's a reasonable default, IME.
  - Sone7 11y ago
    That seems like a dangerous way to feel confident in your own work and abilities to me. Pinning your self worth to comparisons with others is not so helpful, long term, as you might think.
zorpner 11y ago
Over-generalizer, know thyself.

zzalpha 11y ago

> once you've cleaned stables a dozen times spaghetti code is the red flag of incompetence and the correlation is there. Question is, where's the incompetence? Yup, like any profession, there are developers out there who just suck. But the same is true of middle and senior company management. Can you honestly say you've never cut a corner because some incompetent manager mismanaged the schedule or customer expectations and then forced you to compromise quality in order to meet an absurd date? And in any organization with that type of management, those issues are rarely isolated. Any one manager can do a little damage, but when an organization is dysfunctional, well-meaning coders on the ground may be forced to compromise code quality time and time again in order to deal with unrealistic schedules. Think of it like a professional sports team. Sometimes, yeah, the players just suck. But a bad coach or general manager can have an outsized effect on an organization. Now, I would never claim that all bad code is a product of bad management. Again, some folks just suck at their job. But speaking as a guy in middle management, I'd be willing to believe at least half of the bad code lying around in the real world is a product of an incompetent management structure. Getting back to the article, that would represent the kind of hidden incentive that would cause an outsider to assume developer incompetence, even though the reality is very much different.

swanson 11y ago

I absolutely agree that there exists terrible code and that there are incompetent individuals or folks that simply don't care. But if one assumes that as the default response, I don't think that is very helpful. Even in your example of shared data/synchronization - what if the original developers were told that the code would never need to be thread-safe? Or what if there was a constraint that required this trade-off to be made? It's not so black and white.

evilduck 11y ago
Hell, even incompetent looking code (like managing shared resources poorly) can often be explained by a small script done by an amateur turning into a side business and then a full fledged company. Experience and knowledge of an industry beyond software is often many times more valuable than the knowledge of parallel programming. It doesn't mean the code wasn't valuable or good enough at the time, it just no longer meets the rigor and demands, that's why you're employed to work on it. To call everything shitty thats's below your own standards, level of education and experience is a naive view of how software actually exists in the world. Especially when the standard advice given to "idea people" is to learn to code their idea themselves.
lmm 11y ago
It is helpful. It gives you the confidence to change things. It allows you to feel productive. And it's true often enough that it's a reasonable default, IME.
- Sone7 11y ago
  That seems like a dangerous way to feel confident in your own work and abilities to me. Pinning your self worth to comparisons with others is not so helpful, long term, as you might think.

zorpner 11y ago

Over-generalizer, know thyself.