Ask HN: What do you do when your entire being opposes the task at hand?

Dealing with a rough situation that you have no external control over is one thing, dealing with a lousy job you do have control over it. Let go, walk out the door, and look for something more fulfilling.

This time is not entirely wasted. Even in the worst case -- where the code you are so carefully writing winds up not being used after all -- you are getting good practice in code craftsmanship. The next time you are faced with a decision similar to one you are making now, you will make it more easily: not only have you considered the issues before, but you know how one of the possibilities actually worked out. This is how one builds experience.

I usually find that writing code slowly and carefully is in fact the fastest way to get it done, because it minimizes debugging and rewriting. There are exceptions, such as exploratory programming, when you know you're going to throw the thing away anyway, and in small utilities built for personal use; and there are times when getting something working quickly is important (for a demo, for instance) even though you know you'll have to rewrite it. But these are exceptions. When you're implementing important functionality that's going to be in the product for the foreseeable future and that others will have to maintain and build on, the slow, careful way is best.

It seems to me the real problem here is that although your managers value your work, they don't listen to your architectural opinions. That's a serious problem. Maybe at some point you'll need to tell them, "if you want it done that way, you'll have to find somebody else to do it". Pick your battle carefully though -- it needs to be a case where their way is clearly and substantially suboptimal.

The problem is young programmers tend to be hot headed and emotional about their work. This is anti-professional.

While being motivated is great, and important for big projects, every job is going to involve tasks you disagree with or think are a "waste of time." Part of being a professional is doing them anyway, and doing them without getting bent out of shape about it. That's not a sign that your soul has been crushed or that you've lost your love of programming (or whatever), it's a sign that you're mature and realize that work is work sometimes.

If your job is an unrewarding nightmare and you're miserable, then by all means you should find a new one. I'd go so far as to say if you're unhappy with your job overall, find a new one.

But if you have to sometimes do tasks you don't agree with? That's just normal. If you go running for the hills every time you have to do something you don't agree with you'll never be anywhere for long.

During my first internship at a "normal" corporation, I felt exactly like septerr does now. I can't imagine following the career path most programmers go down, even if it is going to pay well. How did you avoid (or is it even possible to avoid) going through that corporate phase and skipping right to working on something that you may love but may harbor more intrinsic risk?

  > So stop trying. Just relax and ... build up some technical debt. 
  > Set yourself up for a job hop....

Our job as developers should not just be to churn out code, but to inform our managers of the costs of doing so. "This feature will take X weeks, this will take Y. We racked up some technical debt implementing Q and QQ, so we need to spend Z weeks addressing that before we can do QQQ." Most bosses like being told that you're making the code easier to maintain, as it means you will make future features happen faster.

I realize I'm lucky not to be in a burnout phase like you are. I just wanted to suggest caution for others when considering a plan to mess up the codebase and then leave -- how will our future coworkers (or later people that read our code) feel when we do that?