3 ms·
As someone who just wrote a quick hack for a temporary problem, I agree. It's not just the shitty programmers who do this. Sometimes we have shitty product man
by ianamartin 9y ago
As someone who just wrote a quick hack for a temporary problem, I agree.
It's not just the shitty programmers who do this. Sometimes we have shitty product managers who won't push back against this kind of thing. And you're forced into a creating something evil because most of the job is very good but this one time, you have to suck it up.
My response to that, though I agree with you, is that when a supervisor or PM or whoever gets on you about something you know is bad, you negotiate.
"Yes, I'll do this for now because the company needs it now. But only if you guarantee me the time (and possibly people) to do it right later."
You get agreement in an email, create the ticket and assign it to yourself as mustfix two months from now. And you shove it down their throats.
That's not an ideal place to work if you have to do that, but I have worked at those places and this is how you deal with that situation.
"Yeah, I'll give you a shit solution in 1 day right now. But only if you give me a a couple of weeks for a good solution later."
In reality, I've mostly only had to deal with this situation in startups. Mid-level and mature companies are usually open to pushing back and getting things right. But there are exceptions. Today was an exception. But that's also one of the reasons I don't really want to work at startups anymore.
- new299 9y agoShitty solutions are usually the right answer. At least in the areas I work in (mostly startups). I would estimate 99% of the code I write gets thrown away. Most of it is trying something out. Even for code that was intended to hit production, the company/project often gets cancelled before it ever hits production. I'm not saying this is true in your case. But there are so many different classes and types of programmers and projects that it's hard to generalize.
- ianamartin 9y agoNothing about this comment is okay. 99% of your shit code isn't getting thrown away. It's sticking around making life hell for people like me. Stop writing shit code because it's going to get thrown away. If you work for startups, you are always operating in protoduction mode. Everything you write ends up in prod. Write code that doesn't suck. It doesn't have to be perfect or optimal, but make it not suck before you push.
- new299 9y agoHmm no. That's what's happening in your world, but you're imposing that world view on me. Probably about 80% of the code I write doesn't even get looked at or used by another developer. If the technique/analysis proves useful, it gets rewritten/refactored. That has the added advantage that I then understand the model better.
- wpietri 9y agoYeah, same here. For me there's a giant difference between code that lasts, which needs to be sustainable, and disposable code, which doesn't. I'm also very big on YAGNI; my code gets so much cleaner and more maintainable when I'm only solving problems that are at hand or reasonably close. Speculative building for the future can get insanely expensive: there are many possible futures, but we only end up living in one. Indeed, I think a "do it right" tendency can prevent people from really doing it right. If we invest in the wrong sorts of rightness up front, we can create code bases that are too heavy or rigid to meet the inevitable changes. So then people are forced into different sorts of wrongness, working around the old architecture rather than cleaning it up.
- wpietri 9y agoGood for you. That's my approach, too. And to rig the system such that technical debt gets cleaned up continuously and gradually without the product managers knowing the details. When there are real business reasons to rush something, I'm glad to support that by splitting the work like you suggest. But the flipside is them recognizing that not every thing is an emergency, and that most of the time we have to do it right if they don't want to get bogged down.