3 ms·

Work with bad companies, be surprised by poor managers? Who is the "we" in this context, I assume an agency? So that's not a problem with this process itself.

Work with bad companies, be surprised by poor managers? Who is the "we" in this context, I assume an agency? So that's not a problem with this process itself. You're describing problems with managers, and problems with developers being unable to handle bad managers. Even putting aside the manager's incompetence, as a developer you can mitigate this easily in many different ways, here's a few: - Just don't show it to management - Deliberately make it obviously broken at certain steps - Take screen shots of it working and tell people "this is a mockup, I still have to do the hard work of wiring it up" It's all a balancing act of needing to get feedback from shareholders and managing expectation. If your management is bad, you need to put extra work into managing expectations. It's like the famous duck story, from Jeff Atwood (see jargon number 4), sometimes you have to manage your managers: https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/

anonzzzies 1y ago
Sure, but we actually thrive here; my company gets called in when systems are not functioning, badly broken, etc and they cannot fix it themselves (usually because the people who built it are gone for decades and they just kept it running with ductape for this time). We never stay for long, we just patch the system and deliver a report. But for figuring out what went wrong and writing the report, we find out how it got to be that way and it's always the same; they suck. Talking banks, hospitals, factories, it really doesn't matter; it's all garbage what gets written and 'TODO: will refactor later' is all over the place. We see many companies from the inside and let me tell you; HN is a lovely echo chamber that resembles nothing in the real world.
- jimbokun 1y ago
  I think the main lesson here is that most entities shouldn't be writing serious software themselves, but purchase software from reputable software companies whenever possible. At least who to hold responsible or sue is clearer in that case.

anonzzzies 1y ago

Sure, but we actually thrive here; my company gets called in when systems are not functioning, badly broken, etc and they cannot fix it themselves (usually because the people who built it are gone for decades and they just kept it running with ductape for this time). We never stay for long, we just patch the system and deliver a report. But for figuring out what went wrong and writing the report, we find out how it got to be that way and it's always the same; they suck. Talking banks, hospitals, factories, it really doesn't matter; it's all garbage what gets written and 'TODO: will refactor later' is all over the place. We see many companies from the inside and let me tell you; HN is a lovely echo chamber that resembles nothing in the real world.

jimbokun 1y ago
I think the main lesson here is that most entities shouldn't be writing serious software themselves, but purchase software from reputable software companies whenever possible. At least who to hold responsible or sue is clearer in that case.