6 ms·

Great article. The one that hit home for me "One lone engineer on a big project silo’ed away". Was on a project where we had multiple applications. The team ha

Great article. The one that hit home for me "One lone engineer on a big project silo’ed away". Was on a project where we had multiple applications. The team had a new employee code an entire system as a prototype but then it was decided to put it into production. Nobody ever reviewed this code, and that engineer told me himself that the code was crap. He left the project to get away from this code and I inherited a mess, with nobody to ask questions from. To make matters worse, the entire company relied on this system and there were about 20 regular users of this system. I was responsible for handling all of their feature requests and support which was often. Many bugs I fixed were extremely challenging edge cases, and there was zero appreciation for the complexity of many of these. My manager was telling others at the company the code was solid, and it's "just python code" which can be figured out. I notified the company I was leaving and they begged me to stay. Even offered to "release" me and hire me at a higher salary under another manager. The only issue was I would be required to support this same project. My manager refused to give me a release date so I had to call HR and tell them I needed to leave at any cost. Pretty sure it's a disaster there since I left.

chatmasta 9y ago
This happens a lot with non-technical founders hiring contractors or employees. At first, the goal is “build a prototype,” then it’s “make this an MVP,” and then finally “what’s left to get this to production?” I don’t blame founders for this; I blame the programmers, especially if they’re consultants. This is a symptom of failure to manage expectations of stakeholders. As a developer, your job is to show the stakeholders what the tradeoffs of different decisions are, both in terms of immediate time to results, and technical debt. If you hear “make a prototype,” you better ask for a projected lifetime of the prototype, and discuss with the stakeholders the tradeoffs of quickly building a prototype, making sure they understand it could mean more work later to productionize it, in exchange for less work up front. Also as a developer, you should realize that nothing is ever a prototype. Don’t use “it’s a prototype” as an excuse for writing unmaintanable and insecure code, because eventually someone is going to want to add some features to it. Good luck telling the stakeholders after three months of building a prototype that you need to start from scratch because the code is awful. This is especially difficult if the prototype looks like a fully functioning product (with minimal features) to the stakeholders, but you as a developer know that under the hood it’s completelty unmaintainable. It’s better to take the time up front to put in place whatever you need to write quality code, than it is to take shortcuts and write bad code. A good developer will be able to explain this to a stakeholder, instead of caving under pressure to rush a prototype.
- s73v3r_ 9y ago
  No, I completely and fully blame the managers/founders for this. No matter how much you try to drill into their heads that this is throwaway code, once they see something, they get excited, and say "Ship it!"
  - chatmasta 9y ago
    If the tradeoffs were valid and fully understood, the stakeholders would not logically come to the conclusion to “just ship it.” The only person who can explain the tradeoffs to them is the developer. Therefore, if they say “ship it!”, they are either wrong or missing information. If they are missing information, the developer is at fault for misinforming them of the tradeoffs necessary for decision making. If they are wrong, then either the developer has cited irrelevant or incorrect tradeoffs, or the developer made valid points but the stakeholders understand the tradeoffs and are willing to accept them.
    - s73v3r_ 9y ago
      Or, the managers are idiots. You're trying really hard to bring this back to always being the developer's fault, and you're ignoring that, many times, management just doesn't listen. You can explain until you're blue in the face, but if they don't want to listen, nothing will make them do so.
      - chatmasta 9y ago
        Everybody is an idiot about most things. As an expert in a domain, your job is to help non-experts be less of an idiot when making decisions that depend on things you know better than them. You won’t get very far with a stonewalling attitude of “well, the manager was an idiot.” You need to establish trust and a working relationship where you both listen to each other.
        Nnuie21 9y ago
        Making my boss less of an idiot is something outside of my control. I can tell them "don't do this" over and over again. If they do it anyway, how is that my fault?

chatmasta 9y ago

This happens a lot with non-technical founders hiring contractors or employees. At first, the goal is “build a prototype,” then it’s “make this an MVP,” and then finally “what’s left to get this to production?” I don’t blame founders for this; I blame the programmers, especially if they’re consultants. This is a symptom of failure to manage expectations of stakeholders. As a developer, your job is to show the stakeholders what the tradeoffs of different decisions are, both in terms of immediate time to results, and technical debt. If you hear “make a prototype,” you better ask for a projected lifetime of the prototype, and discuss with the stakeholders the tradeoffs of quickly building a prototype, making sure they understand it could mean more work later to productionize it, in exchange for less work up front. Also as a developer, you should realize that nothing is ever a prototype. Don’t use “it’s a prototype” as an excuse for writing unmaintanable and insecure code, because eventually someone is going to want to add some features to it. Good luck telling the stakeholders after three months of building a prototype that you need to start from scratch because the code is awful. This is especially difficult if the prototype looks like a fully functioning product (with minimal features) to the stakeholders, but you as a developer know that under the hood it’s completelty unmaintainable. It’s better to take the time up front to put in place whatever you need to write quality code, than it is to take shortcuts and write bad code. A good developer will be able to explain this to a stakeholder, instead of caving under pressure to rush a prototype.

s73v3r_ 9y ago
No, I completely and fully blame the managers/founders for this. No matter how much you try to drill into their heads that this is throwaway code, once they see something, they get excited, and say "Ship it!"
- chatmasta 9y ago
  If the tradeoffs were valid and fully understood, the stakeholders would not logically come to the conclusion to “just ship it.” The only person who can explain the tradeoffs to them is the developer. Therefore, if they say “ship it!”, they are either wrong or missing information. If they are missing information, the developer is at fault for misinforming them of the tradeoffs necessary for decision making. If they are wrong, then either the developer has cited irrelevant or incorrect tradeoffs, or the developer made valid points but the stakeholders understand the tradeoffs and are willing to accept them.
  - s73v3r_ 9y ago
    Or, the managers are idiots. You're trying really hard to bring this back to always being the developer's fault, and you're ignoring that, many times, management just doesn't listen. You can explain until you're blue in the face, but if they don't want to listen, nothing will make them do so.
    - chatmasta 9y ago
      Everybody is an idiot about most things. As an expert in a domain, your job is to help non-experts be less of an idiot when making decisions that depend on things you know better than them. You won’t get very far with a stonewalling attitude of “well, the manager was an idiot.” You need to establish trust and a working relationship where you both listen to each other.
      - Nnuie21 9y ago
        Making my boss less of an idiot is something outside of my control. I can tell them "don't do this" over and over again. If they do it anyway, how is that my fault?