Comment by rampage101 | Hacker News Reader

Comment by rampage101 | Hacker News Reader

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.

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.

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!"

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.

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.

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.

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?

In an ideal world, sure. But I live in the real world, where there are lots of managers that are just plain shitty, and no amount of explanation will change their mind. It just does not work at all. Blaming the developer is not a reasonable thing to do in that situation.

> you're ignoring that, many times, management just doesn't listen

And ignoring that, almost all of the time, the programmer has very little power in these sorts of transactions.

Always write quality code or when bugs occur or new feature requests come up, they will call you. If you wrote something awful now you have to support it.

But you cannot blame the developer. Many app are prototypes to get them over a certain point to get funding. What happens is the technical debt is never paid and you are forced to scale the prototype while adding new features.

Unless you're paying top dollar for contractors, what you describe is way beyond the job duty of typical contractors brought in by non-technical founders who have no idea what they're doing. Even technical founders with a lot of experience make this same mistake. If you're not paying seriously high money, you might think that this is something you're paying for, but it's not. Someone at an overseas sweatshop isn't going to push back on a request for a prototype. It's not part of their job and it sure as hell is not in their own interest. People get what they pay for and most of the time, people who hire contractors without proper oversight are just burning money and have no idea what they even want to pay for, let alone what they've actually bought. Intelligence cannot be contracted for by stupid people.

Reply on news.ycombinator.com