Ask HN: What do you do when your entire being opposes the task at hand? - <AUTHOR> It seems I am fighting with myself. This has happened multiple times and seriously affects the quality of my life.
I am assigned a feature to implement, usually vague and something that I feel adds unnecessary complexity to the codebase. I try to reason with my managers, but usually their minds are already made up. I then struggle with finishing this feature, logging hours upon hours against it...not because it takes so long to code, but because I can't make myself do it and waste hours motivating myself to do it. Also I waste considerable amount of time trying to do things in the most readable, maintainable and simple way possible. This means weighing merits of different solutions and choosing one. I am a really hesitant decision maker, resulting in more wasted hours.
The haranguing part is that my managers don't fire me. They don't see how many hours I have wasted, how unmotivated I am. Instead they treat me as one of their most valued employees (oh the irony!). (I am not in a position to change jobs at the moment. I am helping my BF's startup by doing this job.)
Have you been in such situations? How do you get in the zone and get it done when your entire being is revolting against the task? <comment><USER2> Oh boy, so I get to be the contrarian again.

First of all, isn't it a bit dramatic to say "your entire being opposes" your task? It's not like you're out committing genocide or something. You're programming, and you have to work on a crappy programming task. Every programmer who ever worked a professional job has had to do this at some point. If the very fiber of your soul is wrapped up in your employer's MegaAccounting Client V3.0 REST API, I'd recommend re-thinking your emotional attachment to your job.

That money you get every two weeks is called "compensation" because it is compensating you for your time, which you would probably otherwise spend doing something more pleasant. This is the realistic world of grown-up work life.

If your company's Marketing bone-head says the customers want a green oval button instead of a system-standard button, well, it's stupid, but I'd laugh at how much they're paying to get this ridiculous code written and just write the damn code. It's really not worth losing sleep or sanity over. Not being emotionally attached to your work allows you to shrug off the stupid stuff that Really Doesn't Matter.

<comment><USER3> you come pretty close to invoking godwin's law, here.

if you depend on a place for compensation, then you should be interested in its' success, and if some bonehead (let's not pick on marketing, since it's not always them) has a stupid idea, and money is being wasted on you doing that, it's actually your responsibility to do something about it.

per the law of supply and demand, it's also completely reasonable to leave them behind. a lot of companies with good ideas fail because they can't retain talent enough to get any cogent work completed.

"This is the realistic world of grown-up work life."

^^ This is the statement of an unimaginative individual with no creative juices. I wouldn't employ you to sweep the floors.

<comment><USER4> > "This is the realistic world of grown-up work life."

Actually this sounds like a statement from someone who is fulfilled outside of work, or on different projects within work. I'm of the same opinion. Most people can't have ann interesting workload, so why does this guy have to be "unimaginative" and "uncreative"? Why attack anyone for a statement like that? I'd much rather not work with someone like you.

</comment></comment></comment><comment><USER5> People tend to reserve pair-programming for tasks they perceive as being unusual, complex, or otherwise needing extra review. Personally, I've found it can be helpful even when you simply need to stay on task. When you both have the same goal, you can rally each other; it's typical to become more productive together than you would have been apart.

If this sounds like it could be your style, grab a buddy and see if you can hammer out some of the small stuff together. If not, some of the other suggestions here are good as well.

<comment><USER6> Back when Pivotal Labs largely made prototypes for wealthy people's ill- conceived ventures (think social networking for dogs), the saving grace was that you were pairing.

It's amazing how much better a boring project is when the sample files you upload are image macros with your boss's head photoshopped on a walrus, and there's someone next to you laughing.

</comment></comment><comment><USER7> I felt obliged to comment because I feel I know what you are talking about and I also worry that much of the advice posted so far is wrong at best, dangerous at worst.

I am 42-year-old very successful programmer who has been through a lot of situations in my career so far, many of them highly demotivating. And the best advice I have for you is to get out of what you are doing. Really. Even though you state that you are not in a position to do that, you really are. It is okay. You are free. Okay, you are helping your boyfriend's startup but what is the appropriate cost for this? Would he have you do it if he knew it was crushing your soul?

I don't use the phrase "crushing your soul" lightly. When it happens slowly, as it does in these cases, it is hard to see the scale of what is happening. But this is a very serious situation and if left unchecked it may damage the potential for you to do good work for the rest of your life. Reasons:

* The commenters who are warning about burnout are right. Burnout is a very serious situation. If you burn yourself out hard, it will be difficult to be effective at any future job you go to, even if it is ostensibly a wonderful job. Treat burnout like a physical injury. I burned myself out once and it took at least 12 years to regain full productivity. Don't do it.

* More broadly, the best and most creative work comes from a root of joy and excitement. If you lose your ability to feel joy and excitement about programming-related things, you'll be unable to do the best work. That this issue is separate from and parallel to burnout! If you are burned out, you might still be able to feel the joy and excitement briefly at the start of a project/idea, but they will fade quickly as the reality of day-to-day work sets in. Alternatively, if you are not burned out but also do not have a sense of wonder, it is likely you will never get yourself started on the good work.

* The earlier in your career it is now, the more important this time is for your development. Programmers learn by doing. If you put yourself into an environment where you are constantly challenged and are working at the top threshold of your ability, then after a few years have gone by, your skills will have increased tremendously. It is like going to intensively learn kung fu for a few years, or going into Navy SEAL training or something. But this isn't just a one-time constant increase. The faster you get things done, and the more thorough and error-free they are, the more ideas you can execute on, which means you will learn faster _in the future_ too. Over the long term, programming skill is like compound interest. More now means a LOT more later. Less now means a LOT less later.

So if you are putting yourself into a position that is not really challenging, that is a bummer day in and day out, and you get things done slowly, you aren't just having a slow time now. You are bringing down that compound interest curve for the rest of your career. It is a serious problem.

If I could go back to my early career I would mercilessly cut out all the shitty jobs I did (and there were many of them).

One more thing, about personal identity. Early on as a programmer, I was often in situations like you describe. I didn't like what I was doing, I thought the management was dumb, I just didn't think my work was very important. I would be very depressed on projects, make slow progress, at times get into a mode where I was much of the time pretending progress simply because I could not bring myself to do the work. I just didn't have the spirit to do it. (I know many people here know what I am talking about.) Over time I got depressed about this: Do I have a terrible work ethic? Am I really just a bad programmer? A bad person? But these questions were not so verbalized or intellectualized, they were just more like an ambient malaise and a disappointment in where life was going.

What I learned, later on, is that I do not at all have a bad work ethic and I am not a bad person. In fact I am quite fierce and get huge amounts of good work done, _when I believe that what I am doing is important_. It turns out that, for me, to capture this feeling of importance, I had to work on my own projects (and even then it took a long time to find the ideas that really moved me). But once I found this, it basically turned me into a different person. If this is how it works for you, the difference between these two modes of life is HUGE.

Okay, this has been long and rambling. I'll cut it off here. Good luck.

<comment><USER8> > I am 42-year-old very successful programmer who has been through a lot of > situations [...] Early on as a programmer, I was often in situations like > you describe. [...] If I could go back to my early career I would > mercilessly cut out all the shitty jobs I did

You know, it's hard to believe it, but at some point parents forget what it felt like being a teenager, and senior developers being junior. I know I'm going hard against the grain here, but I think you're better off doing as jblow did, not as he says.

Priority #1: survive, life gets better. In any organization that's large enough to have a pecking order, sh*t rolls downhill. Your CEO meets the customer's CEO and sees some fish on the office walls. He decides that an aquatic theme will increase sales, and passes it on to project management. PMs are slightly bemused, but figure out some web pages that can feature animated fish, and vet the idea with senior developers, who agree it can be done before the next trade show. The senior developer creates the fish_type, group_of_fish and fish_animation tables, grabs a few morsels that are fun to implement (new web technologies, yay!), and passes the rest to you. Congratulations, you're the junior developer at the bottom of the scrap heap! You not only have to deal with all the crap nobody else wanted, but will also explain it as lines of code to your computer. And, after re-implementing several times to address all concerns from meetings you were never invited to, it turns out the customer's CEO had borrowed the office and actually hates fish since choking on a herring bone 32 years ago.

How do you deal with all this? Well, maybe quitting will find you a better job as a junior developer. (Also, maybe an uncle you never knew suddenly leaves you his fortune.) But realistically, the way most people do it is the same as jblow's. You find ways to survive, improve your resume, and eventually move uphill to have more choice in kinds of crap you need to deal with. Sharing your hard-earned wisdom with junior developers will only be the cherry on top at that point...

<comment><USER7> You are presuming a lot about what my early career looks like. Really I never worked any jobs as bad as what you describe. Well, maybe the time I did data entry during my first year of college. The longest I ever worked in a highly corporate environment was 7-8 months, but at least at that time I was doing something at least slightly cool (a port of Doom 2 back when that was a new game, and with which I had full autonomy).

What you seem to assume is normal is some kind of career hell I would never want to be in (nor have ever been in).

<comment><USER9> I'm someone graduating from college in a few months, and this is one of the most striking things to me about a programmer's expected outlook on jobs. The career path of going and getting an internship, then becoming a junior developer, etc etc at some corporation is something that seems like it would suck the soul out of anyone that is even moderately creative.

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?

<comment><USER10> For me, it came from understanding what I did not know, and that to do high- level creative work you need a large base of background knowledge. I just took every job as an opportunity to learn and fill in the gaps in my knowledge, so that I'd be better prepared when I did strike out on my own.

I have gaps in between every job I've ever held, but those gaps are strategic. In them, I figure out what I really want to do, and whether I have the tools to do what I really want to do. I applied to YC's first class of S05, as I was finishing up college. I didn't get in. I figured that if investors wouldn't talk to me, I'd learn how to do a bootstrapped startup, so I went to work for a bootstrapped financial software startup. After 2 years there, I quit and founded my own bootstrapped startup, this time in Web 2.0 casual games. It failed too. In examining the failure, I figured that I lacked enough real- world experience to understand what the real markets were, I'd exhausted my pool of potential co-founders, and I had this continuing anxiety about how to do software development "the right way" and make programs that scale. So I moved out to California to work for Google Search. I'm on my own again, but I got everything out of Google that I hoped to get out of it (and more!).

If you're doing it right, each job is an opportunity to get a lot more than money. It's a chance to build technical experience, to challenge yourself, to look at how people with way more experience than you make decisions, to understand how an industry works, and to see how an organization fits together.

<comment><USER11> This is a _very_ insightful comment, and I hope everyone reads it.

It reminds me of my favorite quote from one of the _best_ books about building any type of "Professional Services" company:

"The health of your career is not dependent so much on the volume of business you do, but the type of work you do (whether or not it helps you learn, grow and develop), and who you do it for (whether or not you are increasingly earning the trust of some key clients). In any profession, the pattern of assignments you work on _is_ the professional development process - you just have to learn how to manage it."

</comment></comment></comment></comment></comment></comment><comment><USER12> _Also I waste considerable amount of time trying to do things in the most readable, maintainable and simple way possible._

Is _waste_ really the right word here?

 _They don 't see how many hours I have wasted, how unmotivated I am. Instead they treat me as one of their most valued employees (oh the irony!)._

"When given a vague, annoying feature to implement, very carefully considered approaches and built it in a surprisingly readable and maintainable way"

What you're experiencing isn't atypical - sometimes programming something sucks! Your employer values your ability to power through it and still get good results.

</comment><comment><USER13> Yes, I left such a position to go and get a doctorate, because I was fed up with the dumbing-down of the codebase, the way that my colleagues wrote absolute undocumented spaghetti cruft, I had to keep fixing their bugs, and management were making some very dumb decisions about key features. As far as I know they are still going fine, which is surprising given I was the only one who could understand how whole subsystems worked, mainly because I knew how to write safe threaded code.

But, enough on that. A few years before then, I _felt_ like you did, but I wasn't actually in that situation. There is a very real positive feedback loop in effect - you feel like you're doing a bad job, so work longer hours on it, end up taking longer, feeling like you have "wasted" hours, and feel worse about doing a bad job.

Believe your employers when they say you are doing great, otherwise you're likely to be heading down the burnout route which had me off sick for half a year. It's not every coder that has such high standards as you, and that is not something to be ashamed of. Be proud of the code that you have produced. Think to yourself "It's just as well I wrote this bit, because if X had, it would have been awful".

I know this sounds like extreme arrogance, however sometimes it is necessary for the purposes of regaining balance. It sounds like you are being a little too humble. If it gets too bad though, get some help from someone.

<comment><USER14> Something else that can help is that once you've learned how to write clean, safe, reusable code, the next step is learning when _not_ to. Clean code is an expense, and there's times to put in the extra effort, and there's times to not. Code's needs are not evenly distributed, in fact they are _very_ unevenly distributed (power law distribution I suspect without proof)... carefully crafting to the n-th degree an end-user GUI page for a marginal feature is probably a waste of time, just make it work. On the other hand, adding a hack to a core routine used by huge swathes of the code may have much bigger negative effects than it even feels like now, and it sounds like it already feels pretty bad.

Consider working on the next level and using this as a chance to study when and where the effort is actually worth it. It may _feel_ like you're handing yourself a license to be sloppier, but if done correctly this actually turns you into an _even more_ capable developer than someone who finely engineers everything, because you'll have that much more time to finely engineer the things that matter once you clear away the time of fine engineering of the things that don't, and on the whole you'll be creating much more value in your code.

<comment><USER15> I wouldn't mind writing unclean code if I weren't the one who's going to have to maintain it and add new features to it in the near future or the years to come.

<comment><USER14> This is part of what I mean by learning when it is and is not appropriate; I tried to make it clear it was not a blanket permission slip to be sloppy (anticipating that obvious misunderstanding of my point). If you end up having to seriously maintain "unclean" code, you did it wrong. You _will_ do it wrong before you get the hang of it, no sarcasm. Untrained gut intuitions are not very reliable here, and the only training available is practice.

And on the other hand, "maintain" is a very ambiguous word. If you are frustrated because it took you ten minutes to add one field to a form, once in the course of 3 years (to put some concrete numbers on for example's sake), you _still_ came out ahead not spending an additional 10 hours polishing the code to a fine sheen, so you could be happy adding that one field 3 years later and saving that ten minutes. If you're frustrated because you actually have to overhaul it significantly, and it's a mess, and now you've also dropped all your context and can't remember what is what at all, and you could have cleaned up up three years ago in three hours and now lose two weeks just to understanding what the hell, then you've lost, yes. And of course "maintain" can mean a lot more than either of those two cases, too.

And as a final note, it's all gambling, and that is also something you must come to grips with. You don't really _know_ where the changes are going to be in three years. However, you can learn to guess with a success rate much higher than mere random chance. (Don't forget to discount future time appropriately.)

</comment></comment></comment></comment><comment><USER16> You can add meaning to your work by picking goals and accomplishing them. It doesn't matter what they are -- just as long as they can be accomplished and you know that you did.

Pick things that incidentally accomplish the assigned goal. For example,

1\. Pick an amount of time, like 3 hours, repeat this cycle

2\. make a branch

3\. implement the feature in the fastest way you can

4\. think about why this isn't acceptable

5\. throw away the branch

6\. do it again avoiding one thing that made the last one crappy

Also, weighing merits of different solutions and picking one is your job -- no need to feel bad about that. Come up with an assessment tool that will help you decide. Time-box decision making, but don't stop thinking about your solution -- just give it the appropriate amount of time, not unbounded.

Making progress is motivating. You want to end up at the same place but have the feeling of progress making throughout the process. I believe that it's possible you are taking the appropriate amount of time to do the work at hand, but you are getting into an anxiety/depression cycle because you can't get into a flow state.

</comment><comment><USER17> As a manager I've had to ask people to do work like this. I try to share it out as best as possible, so everyone's getting the least unpalatable tasks for them. I've also made myself available to talk through why it's required.

Those conversations have taken my team and I to interesting places. I've discussed brand positioning with developers, and shared spreadsheets of time- to-value models with designers, at times going far outside of people's skill sets and comfort zones. If someone insists a piece of work is a bad idea, I invite them to argue against it but insist that I need them to make their case rigorously. Sometime they'll convince me, sometimes they don't want to work through the reasoning, sometimes I'll try and develop their case and argue against myself. I want to reach a position where we either change the task, or we're both satisfied that the task should be done. If that's too hard, then I'm after a position where they at least have rational faith in my request and my reasoning, and are ok to do the work on trust.

I spend a lot of time on this, for a few reasons.

First, I don't want to ask anyone to do something meaningless. Burnout isn't caused by workload. Workload causes exhaustion. Burnout is caused by resentment. If my team resent their work, that's a deep and important problem. I'll tolerate a only very small amount of that, but I'll let everyone know I'm conscious of it, don't like it, and am working to get away from it. Burnout is toxic and damaging to people and the group as a whole.

And secondly, this kind of explanatory work strengthens everyone's investment in the team and the work. It strengthens the team's ability to think together. As people become better informed, all of our discussions become richer and more valuable. People enjoy the work more, and can relax and trust each other more, knowing that decisions are made in ways they can understand and agree with.

Finally this is also a litmus test for me. If a company won't let me in on it's decision making, dismisses my concerns as unimportant and tells me to just get on with something, they're indicating they don't value the team in the same way I do.

<comment><USER18> As others have said, thank you for articulating this so well. As a developer, I've often gotten feature requests which seem crazy at first, but then make sense once I understand better the context in which it will be used or the degree to which it will make a customer or other user happy.

At the same time, it's really valuable to have a manager (and other stakeholders) who listen to the "This __really__ complicates our code and will take X weeks to implement, why don't you try this as a procedural workaround ..." suggestions that I make at times.

I really agree with your point that this type of thing strengthens my investment in the team and the product.

</comment></comment><comment> martin-adams I can identify a few times I've experienced having something vague and complex thing to work on. If I were in your situation I'd look at the following...

1\. If I'm working on something vague, try to extract more information about it. It's very hard dealing with frequent changes on a complex code base. I'd try to find out who the stakeholders are, customer is, and most importantly, what they are trying to achieve that this serves.

2\. Break it down into smaller tasks and measure myself against these. I want to leave work having completed something and not return to work knowing I didn't complete something.

3\. Try bringing a colleague in to help you, such as talking through the existing code and bouncing ideas off them. The energy a colleague puts in can help with motivation.

4\. Make sure there is an end to it and that it's not an open scope. You'll never finish something if the stakeholder doesn't know what they actually want.

5\. If this looks like it's the norm and you're not happy, while you say you can't change jobs now, put the plan in motion for when you can. Think about your CV, learning new things, etc that help. When the time is right you want to be ready to jump.

6\. Get enough sleep. I find I procrastinate more when I'm tired. Of course, eat healthily and exercise.

7\. Try to remove other distractions, such as any other commitments at work as a 10 minute interruption can cost you an hour if you're not in the flow of the work.

<comment><USER19> In addition to this excellent post, try to use the five minutes rule. When you need to tackle an undesirable task, tell yourself that you'll try it for five minutes. After you got started, you will lose the five minutes mark out of sight and you already mastered the hardest part - getting started.

</comment></comment><comment><USER20> Hi,

I'm a manager, and sometimes I feel like you. Sometimes I need to ask developers to do things I don't believe in or things I'll throw away in a few months. This also demotivates me. You need both a lot of discipline and just a bit "aloofness" to keep going. Care less about those tasks, think about friday.

If your managers are any good, they know you have wasted hours, they know you are unmotivated, and they know those meaningless tasks are the reason, this is why you are a valued employee. I'd rather argue to death with an employee because he thinks his idea is best for the company than one that will just accept any task like a robot. But sometimes you have to implement ridiculous things into software, from clients being just crazy or because of some strange contract clause. This is when discipline kicks in. Such situations shouldn't happen often, but if they are, that's when you should move on.

You don't need to get "in the zone" to get the job done. Just start by doing smaller pieces, put your headphones on. You could just ask why feature is being built, but I doubt knowing the reason will motivate you at all.

</comment><comment><USER21> It sounds like symptoms of burnout. I am not an expert but I have personally suffered from burnout before...and it took me a while to get over it. It sounds like you are additionally hampered due to being personally obligated.

As far as I know the only way to get over burnout is to stop. If you do not you will suffer more. I wish I had better news.

<comment><USER22> Yeah, I've been there and felt the same way. Your best bet is to either find a different job, or one thing that can help a lot is just take a vacation. I was working on a project for months and months, and every few months some new requirements would appear. It's easy to feel unappreciated at a point like that. What really helped me was taking time off and working from home. A week or two of relaxing can really help you jump back into your dreaded project with a fresh perspective and not feel burned out.

<comment><USER23> I agree, this is primarily why I'm leaving my current position for a company with realistic expectations. I've had months without a single day off working 60 - 90 hour weeks every week because they refuse to compromise with deadlines or adding additional developers. I'm planning on taking a few weeks between jobs to just unwind so I'm not frazzled for the next position.

</comment></comment></comment><comment><USER24> First and foremost, remember that you're writing code to bring in customers. Your codebase can be beautiful, pragmatic, semantic, and have 100% test coverage; if you don't have any customers, you don't have anything.

"Unnecessary complexity to the codebase"

It depends on what you mean by unnecessary. If you mean "won't bring in anymore customers", have that conversation with your managers. Not all of them are brilliant, and no one gets it right 100% of the time. If you can prove that the feature doesn't provide value, have that conversation with them.

On the other hand, if your boss ignores your input, and you're 1000% sure that there are other features that are more valuable to your business than the one in question, you can always push that one to the back and work on something that's more productive to the company. Depending on your political and professional circumstances, your boss may not notice or care, and their boss may forget about their red herring feature; you might be able to side-step the conversation altogether. This will only work if there's more than a few items on your plate that need to get done soon, and this feature can get pushed aside without delaying or blocking anyone else.

Bear in mind that if you go this route, you're putting yourself, your career, and your neck on the line. If it turns out that it wasn't a good idea and everyone agree with you, you'll look like a genius and gain some clout as a clairvoyant; if it turns out it was seriously necessary, you'll look like someone who pouts when they don't get their way. Either way your boss may also hold a grudge. I'm not saying it's the greatest way to go, just adding it as an option. It's helped me more than a few times in my career, but it's also frustrated my bosses a few times. Be gracious if you're shown wrong though, and quick to admit defeat if it's obvious you chose the wrong path, and you should be fine no matter what happens.

</comment><comment><USER25> Time to gently move on to something else. There is a secret they don't tell you early enough, there is no "prize/goal/win" at the end of your life, you just die. Your life is the sum total of all the time you spend with friends and family and colleagues. And every day of that life you spend fighting yourself is a day you will never get back, you will never be able to change, and you will never cherish.

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.

</comment><comment><USER26> Why would your managers fire you?

Your managers demanded a stupid feature, and you took long time implementing the stupid feature due to its complexity.

The only thing missing is you need to warn your managers before you start coding such as "This is going to take long time due to the complexity, many many weeks. Also I don't think it's right for the product either."

As long as expectations are clear beforehand, and you met those expectations, then no one is getting fired, and therefore you should relax and enjoy coding Easter Eggs into each shitty feature.

</comment><comment> Jean-Philipe Unless it's morally against my ideals, like violating privacy, stealing money from kids with phones, etc., I don't see that many problems with features I don't agree with. They want it, they pay, why not? Surely, if it was my own company or a team I'd value, then I'd hesitate to implement that feature and argue with everybody about it. But at some point, I leave the project and once I don't I own it anymore, I don't have problems with features I don't like. That is, unless they tell me /how/ to solve the task.

What helps me most is finding a technical challenge that makes the feature interesting and fun to implement. This shouldn't be too hard, if you are free to design the feature technically. Hope that little hack helps you getting things done.

</comment><comment><USER27> It seems your internal struggle about your perceived inefficiency is burning you out. Rightfully so if you are wasting time on what's not particularly important. Do your managers value the quality of your work as much as you do? If not, do you think you'd be able to live with a slightly lower quality deliverable that frees you from the stress? Perhaps it would allow you to work on that feature you do want to work on.

We have a right to be happy. We should make decisions that satisfy the majority of our lives and where do what we love. For things not under our control, we still need to love what we do.

The easiest solution to your problem is creating discipline and decisiveness. When you give yourself more hours to work than you are expected to, you create a vacuum of inefficiency. You work unsustainably on things of little value. Instead I would force you to a) figure out your success criteria, b) what are those steps, c) prioritize those steps, and most importantly d) set time limits for each of those steps. The constraint of time will force you to get to the 80% quickest. I have written some articles on these exact problems and in the process of creating an app with those insights. Feel free to read more here: [https://medium.com/produce- productivity/ee13c1600b6b](https://medium.com/produce- productivity/ee13c1600b6b)

</comment><comment><USER18> > I am assigned a feature ... that I feel adds unnecessary complexity > [My] > managers ... minds are already made up.

One of the things that I found helped me the most when dealing with features like this is to Let Go of Caring about that particular thing. We fight for what we believe is best, but when a customer, manager, or other higher-ranking stakeholder decides otherwise, it's out of our hands. You did your professional duty by arguing for the Better way (as you see it), but now it's time to make the new direction work.

UX team decides buttons should be the way that pisses you off the most? It's OK, you're not the main user. Manager decides that a "Calculate" button is better than auto-re-calculating? That's ok: the users are happier using that. (We can transition later.) They want an e-mail based workflow for approving things, rather than a web-based one? That's OK: these execs spend most of their time with their phones, and don't want to be logging into the website.

Often what we feel is "unnecessary complexity" is a workaround for a key use case that we didn't realize, or yields customer happiness because it's what they asked for. In that case, it's __necessary__ complexity, just like a bit of ugly code that patches a bug. Try looking at it from the perspective of the user or the manager, and really understand why they feel it is important -- quite often, it's addressing a weakness of your software product that you were not aware of, or which you felt was unimportant.

</comment><comment><USER28> I know the exact feeling you're talking about - I used to work at a wonderful small dev shop where things moved fast; whole projects were wrapped off in a week or two.

Until this one project where we were asked to 'fix' an already written Android app (written by an Indian outsource then sent to Canada). The contract was for a massive amount of money, everything looked clear cut and straight forward, how could we say no?

For almost 7 months (!!!) my team and I had endless meetings next to a wall map containing the 5000+ classes that each had to be dissected, understood and reimplemented properly. All the comments were in at least two different foreign languages, and even the best translation services (human included) could only give us at best translations like: 'not class, forwards' or 'use brick making way here', most likely due to the comments being poor in their original language in the first place (not due to the translation).

At first I had great momentum, I was an unstoppable force; then quickly things started slowing down - each task started taking hours longer, than days longer, than weeks longer. Ultra trivial fixes like the placement of one statement outside a try catch, could easily take a whole month to locate (by a team of 4!).

After pouring my heart and soul into this project day after day, grinding myself literally to the bone; I started getting depressed, physically sick to my stomach for days at a time, starting fights with co-workers over absolutely nothing, just so I wouldn't have to look at that fucking code one more time. Anything to just not look at that code one more time.

By the end of the project (which we did actually manage to complete), I was waiting for that moment of euphoria, that release of completion, that I would never ever again need to look at that code, or work on that project.

But it didn't come.

I was paid more than 100k for completion of the project, so I was well reimbursed for my time.

That's when I realized that it's really not about the money, it's not about the team, or the language; It's not about your repo, or your source control techniques. It's not about agile, and it's not about problem solving. It's not about working from an office or from home, and it's not about the mother fucking 'culture'.

When you're lying on your death bed, and you look back; will you be proud that you spent all that time and suffering to fix an app for some asshole who is trying to make a quick buck by exploiting people who aren't technologically wise enough to realize what they are doing?

The next day my boss asked to meet with me privately; thinking I would be fired (and happy with the idea) we met briefly at a local coffee shop. She said that all the anger, depression, and self loathing was 'worth it' because 'I made a lot of people rich' in the process (myself included) and they were happy to deal with that (and even to pay for therapy).

I was offered EVEN MORE money to continue working on projects exactly like these, to the company we had just discovered a cash cow of an app crop, and I was the golden goose. I could easily do this the rest of my life, and lead whatever life I wanted to outside of work.

I quit on the spot, and laughed and cried the whole way home. Knowing that I would be blackballed in the community that I had worked so hard to establish myself in.

Literally career suicide. The company didn't recover, and a lot of people were (and still are very pissed off with me - like angry emails, restraining orders, fucking pissed).

I promised myself that from now on I would only do work that I believed in enough to starve to death for (and it was looking for a long time like that was going to be the case). The truth is, if you want a job where you can make 6 figures (or even 7 if you're doing it right), you will find it. You will always find it, and they will always be there.

There is a vacuum of talent on the community of expert programmers caused by major corporations like ibm, amazon, facebook, twitter, and snapchat just filling up cubes in their 'programmer cluster'. A group of people they can throw whatever stupid, or trivial tasks at - and you won't say shit, because damn that pay is tasty. You're breaking peoples rights to privacy, doing WAY less than ethical things, and you probably don't even know it (because that's how it's supposed to work, or someone else above you clearly isn't doing their job).

My only advice is to get the fuck out. Run, run as fast as you possibly can and never look back.

Never respond to any recruiters for any reason, never respond to job offers, and don't even think about looking for another position at another company (I promise it's the same thing, no matter how they promise you otherwise, and tell you that their culture is the dopest - nothing like clubbing seals with some rad people right?).

Get off your ass, and do something worthwhile. If you can't do that, then learn how. If you can't do that, then you're a drone and you should keep that shitty job because it's the best you're ever going to do (in which case, fuck you, you make the world a worse place for everyone by whoring your skills out to unethical assholes for cash).

Make something that garners zero profit, make something that only helps people, make something that changes the world for the better. You will quickly see your entire world, and all the people in it change before you eyes. You will get more job offers in your inbox than spam, because the world will see that you don't give a fuck about anything but getting shit done and helping people.

Today I run a few companies, the largest of which is a NPO machine learning research firm offering free services to help cure cancer, track missing children, follow and assess viral outbreaks, and front line ML research pushing the needle of science forward (email: firstname.lastname@example.com for services); and some of the others include: organic vegetable gardening as a service (physical outdoor labour, everyday, which I enjoy more than anything) and free apps that assist paramedics and doctors (without ads or bullshit).

If you want to be happy, like, really, actually happy (and not just wealthy) you're going to have to risk it to get the biscuit; and it's going to be the hardest battle you've ever fought in your entire life, by at least a few magnitudes.

Good luck, it's a jungle out there.

<comment><USER29> Wasn't it possible to create the exact apps from scratch? You get to pick the technology you like, you don't have to waste time understanding and refactoring those stupid classes.. Sometimes, from scratch means faster, easier, cheaper. There's a famous Joel Spolsky post where he argue that you should never start from scratch.. but that sounds like a case where it would have been worth.

<comment><USER30> On the other hand, Alan Kay argues you should start the same project from scratch every 3 months. :)

</comment></comment></comment><comment><USER31> Welcome to programming!

"Also I waste considerable amount of time trying to do things in the most readable, maintainable and simple way possible"

Motivation is tied to your attitude here as you are looking to do more 'interesting' work, whereas the task at hand looks boring. However the task at hand could be important for the company, so it is important to take trouble understand the big picture here. Most engineers (and I am one of them) are too self-centered to do this, and this can be debilitating.

It involves coming out of your shell, being proactive to talk to the business, product and other areas and see why these set of features that needs to get done has important implications.

At the end of the day, everything is about service. If you enhance your attitude to think more in a service-oriented way (it is not all about you), this changes your 'attitude profile', and in turn can boost your motivation factor by several orders. Suddenly what looked boring becomes very important. It may mean to be more pragmatic ( no ideological fixations on 'purity of code'), roll up your sleeves and get it done.

The valuable service to the customer, can lead into repeat business, which adds to the bottom line, and that later could mean more bonus for you, which you can use it up for that special time with your BF that you have been planning for a while.

</comment><comment><USER32> You might be burning out, and not even realize it. I've been in a similar situation. The unmotivated mindset leads to additional hours compounding the effects.

My suggestion go on a vacation, if it doesn't get better... leave. You say you're not in a position to leave... but you have to, because its not going to get any better. You're not really doing anyone a favor by burning yourself out for them.

</comment><comment><USER33> 1.) Doing things you don't want to do, but are necessary for a paycheck or otherwise is a basic part of being a grown-up. Lacking the discipline to simply get such things done and move on is a huge handicap as it's burning loads of time and energy that could be better spent elsewhere.

2.) This is surely arguable, but I think agonizing over a lack of satisfaction/motivation in a job is likewise a waste of time. If you can get those things at work, great - if not, don't try to force it - redirect it to side projects, friends, family or hobbies.

3.) Life is really short and full of trade-offs. Be sure to regularly re- evaluate your position or you might find yourself stuck rather than simply compromising.

 _> 'How do you get in the zone and get it done when your entire being is revolting against the task?'_

Through each of the things I described above. Whenever necessary I remind myself that:

* I'm a provider and professional, my family depends on me and I'm paid to do good work - getting this done is not optional.

* My time is short, delay buys me nothing.

* I have no shortage of great things to look forward to when I'm done.

<comment><USER34> "1.) Doing things you don't want to do, but are necessary for a paycheck or otherwise is a basic part of being a grown-up. Lacking the discipline to simply get such things done and move on is a huge handicap as it's burning loads of time and energy that could be better spent elsewhere."

Realizing that changing your environment so that it encourages the right outcome is orders of magnitude beyond being a basic, mediocre grown-up who relies on discipline and will power, which is easily depleted, to overcome an onfavorable environment. No one should settle for relying on discipline and will power. That's a moralizing exercise in futility. I've had this argument with my stepfather until he became abusive. The result: I stopped talking with him. It has been one year. Reserve your discipline for differential association and for improving your environment.

<comment><USER33> My third point addressed this and the OP pre-emptively stated he/she isn't open that at the moment.

 _> 'I've had this argument with my stepfather until he became abusive.'_

That's not terribly surprising given your selective comprehension and tendency to speak in absolutes [1][2][3][above] about who other people are or what they should do.

Chill out.

1: [https://news.ycombinator.com/item?id=7451659](https://news.ycombinator.com/item?id=7451659)

2: [https://news.ycombinator.com/item?id=7486177](https://news.ycombinator.com/item?id=7486177)

3: [https://news.ycombinator.com/item?id=7452011](https://news.ycombinator.com/item?id=7452011)

</comment></comment></comment><comment><USER35> Mark Twain is rumored to have said something along the lines of "Eat your frog" (it may be apocryphal, but whatever: [http://quoteinvestigator.com/2013/04/03/eat- frog/](http://quoteinvestigator.com/2013/04/03/eat-frog/)). The point is that you should get up in the morning and make a point of doing the worst, most boring, most disgusting task you can think of. And don't think too hard, just get it done. You can decide whether to improve on it later. Then, the rest of the day, you'll be freed of all the worry, wallowing and indecisiveness.

The other thing is that if they value you, it's probably for a reason. You're fulfilling their expectations and providing them with value. Take the compliment and go with it! [http://en.wikipedia.org/wiki/Impostor_syndrome](http://en.wikipedia.org/wiki/Impostor_syndrome)

</comment><comment><USER36> When this happens to me I take the time to refactor all sorts of "dependencies" in the process. It ends up being a net positive. Yeah, I added some complexity where it wasn't needed in one area but I've removed some legacy code or redesigned an ugly hack.

They don't know this code is generally unrelated or don't complain to me about it. Only problem with this is I can now be opening up new bugs because these revisions aren't always fully QA'd.

</comment><comment><USER37> I'll throw my hat in with the folks who are saying to get out early before you find yourself in the midst of a truly debilitating burn-out.

That being said, I've worked a couple jobs in the past where I felt similarly to you--one of which I objected to much of what I was working on not only from a utility standpoint, but from a moral/ethical one as well. The only thing that kept me going was the social network I built of similar-minded coworkers. The ability to vent, joke, and commiserate with people who felt the same way I did at the company was extremely cathartic and served as my therapy. I don't think that's a good substitute for getting out and finding something else that you actually enjoy, however, which I eventually did when I realized how it was affecting my mood even outside of work.

</comment><comment><USER38> I get like this more often than I like to admit. I just break the entire thing down and write a multitude of check box's. Personally I'm using the bulletjournal technique (www.bulletjournal.com)

If I cant get the motivation then I need more abstraction. Abstract until you drop! You are naturally conditioned towards completing things and positivity. That's why people get badly addicted to games like farmville and such. You do something simple, you get something back, you do something else, you get something else. Really your just baking time. But the psychology of achieving is where the addiction comes from. It's not the game. It's the fulfilment from completing something. You need to see this progress visually so you feel like your moving.

It's not uncommon for me (when I'm really low and scraping the barrel) to have a task like for a job such as this;

[ ] Open Sublime [ ] Set-up folder structure [ ] Skim read spec [ ] note areas of concern for later [ ] Describe required method to self / colleague / rubber duck [ ] pseudo code initial method [ ] expand pseudo to code [ ] looks in spec for extra details [ ] list who needs to be contacted for further information [ ] email manager estimate [ ] take a break ...

Now you can start to get "little wins" even on something you don't really agree with / want to do. The goal now becomes to tick those damn boxes, not to implement some feature you don't agree with. It might seem strange to tick a box for something as simple as opening a program, but if that's the level you need for your motivation then that's OK. The reality is these check box's are just mental milestones for progression. What's really important is your ticking them though. If you find yourself for hours on end not doing the list, the list is wrong somehow. Perhaps you don't have small enough tasks. Perhaps the tasks are too hi level and need to be split into sub tasks on those. Just tick, tick, tick.

Try it, it might work for you, it might not. This sure helped me though! Good luck.

</comment><comment><USER39> I'm in a state that you've described pretty much every day. This is reality I'm afraid. Only the best of the best of us get to choose what they want to do, the rest are having a hard time surviving most of the time. I work in a software company and absolute majority of my coleagues are not interested in technology at all. Some of them sit on the same chairs for 15 years turning some ridiculous specs into useless code. As soon as the clock strikes 5 they get up from their chairs and proceed to the exit with unchanged zombie faces. I can swear I saw cows doing that somewhere in the countryside. I spend all the spare time I have to get as good as I can so that I could eventually not be ignored anymore and find a job that I would really like.

<comment><USER40> You can do it! Keep learning and switch jobs as soon as you can. You don't have to switch to your dream job right away, just trade up a little at a time. You'll learn even faster at the next one.

</comment></comment><comment><USER41> _Also I waste considerable amount of time trying to do things in the most readable, maintainable and simple way possible. This means weighing merits of different solutions and choosing one. I am a really hesitant decision maker, resulting in more wasted hours._

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.

</comment><comment><USER42> The biggest thing you can do is to align yourself as working together with your managers. You are not a code monkey.

What does this mean?

Well, if they assign you a vague task, you get clearer about it, you ask them why they want to do it, what the objective is. A lot of the time, you could be wrong, and with their objective it makes sense. A lot of the time you'll be right. The best way to show it is to mock it up, and explain your thinking on why it's wrong.

The biggest killer is when you feel like a code monkey, it's usually not the work.

</comment><comment><USER43> Every job has some aspect of it that you will resent, and we've written about it on our blog ([http://blog.sandglaz.com/how-to-do-tasks-you-simply- resent-d...](http://blog.sandglaz.com/how-to-do-tasks-you-simply-resent- doing/http://blog.sandglaz.com/how-to-do-tasks-you-simply-resent-doing/)).

I've been there before, and had some periods of time at a previous position where it felt like every minute of the job was a struggle. Getting things started was the most difficult for me, but once they were started, I could get them done.

If this job is just to pay the bills, and is not critical for your career, then: * Work on autopilot. Do what is required of you, and use some of your time on the job to learn things that would advance your career. For example, for each 4 hours worked, allow yourself an hour of learning something new to advance your career. * Find outside activities that you look forward to each day. Don't let the job define who you are. If you do, it could crush you. * Since they value you, ask to work reduced hours if possible. The less time you need to commit to the job, the less likely you are to burn out.

However, I can't help but recommend that you stay on the look-out for a job that brings you satisfaction and challenges you to do your best everyday.

<comment><USER43> link is broken: [http://blog.sandglaz.com/how-to-do-tasks-you-simply- resent-d...](http://blog.sandglaz.com/how-to-do-tasks-you-simply-resent-doing)

</comment></comment><comment><USER44> Actually, you could probably quit and it wouldn't be as big of a deal as you expect. Most people over-estimate the risk of quitting. And most people are a lot more understanding than we give them credit for.

Every time I've reached that point that you have described, I've quit. It was the best thing for me every time, too. There is no point wasting your time doing something you don't want to do, _especially_ if it's for someone you care about. You'll just do a shitty job and you don't want to dump shitty jobs on people you care about.

Is it just that the work is boring, or are you being asked to do unethical things? I mean, either way, I would quit, but if it's anything unethical I would urge you to run as fast as possible.

However, if it's just "boring" work, perhaps recasting it in a different light might help. Look at it as a game of seeing how many you can finish in a single week. Stop worrying about doing the "best" job on it. If the project is so boring to you, then you probably shouldn't care so much about the quality of it. Just dump out some garbage, get the checkboxes filled, see how much you can get away with. Make it a learning experience, a chance to test your boundaries.

<comment><USER13> The other point is that if this is your BF's project, you are in serious danger of building up a load of resentment for him and breaking up the relationship if things get any worse. It may actually be better to tell him that you're not getting on with the project and it'd be better for your relationship if you work in different places. There's nothing wrong with that.

<comment><AUTHOR> This job is not directly for the startup. I have been contracted out by the startup to this job and the money it brings is important for the startup atm.

<comment><USER45> That changes things a bit. If you believe strongly in the startup's strategic goals, then perhaps you can convince yourself that your current goal is purely tactical, and can indeed force yourself through it with willpower alone. Sometimes -- rarely, IMHO -- flogging yourself to get through some necessary shit work does make sense.

If you were actually working _at_ the startup, on its principal mission, then your problem would be more complex. Not only would you have to think about the appropriateness/advisability of the particular feature you're implementing, but you'd have to constantly evaluate it in light of your relationship with your SO and your prospects in the new company. It would be very difficult to separate these questions in your mind, so IMHO it's a good thing you don't have to.

</comment></comment></comment></comment><comment><USER46> Wait, how long have you been programming? 'cause this is essentially the job description of every programmer I know.

</comment><comment><USER47> Currently fighting that same problem, I'm more of a programmer, but I'm being placed on really, really fiddly UI 'features'.

I've made about 10 cups of tea, gone to the toilet about 6 times, read every tweet tweeted in the past 24 hours. Started three arguments, considered quitting and storming out... it's horrible and I'm glad you posted this because I've been going through exactly the same thing.

<comment><USER48> Quit gracefully. Even the taking the first step can be relieving.

</comment></comment><comment><USER49> Not a therapist, but have a look (or better, have a professional have a look) at ADHD-PI. What you've said describes perfectly how I feel at work a lot of the time, and it's what I was diagnosed with.

I seem to have a finite pool for motivating (or more accurately forcing) myself to do work. And when that pool is empty, it's off to HN or Reddit I go. Frustrating, and I still don't have a solution yet.

Hope this helps.

<comment><USER50> Have you tried modafinil? I've heard it works for some people, but lack first hand experience. I'd be curious though.

<comment><USER49> Working through some non-medicinal remedies first (changing habits, setting up routines, etc). Not quite having the effect I hope for, but we'll see.

The consensus of what I've read is that most pharmaceuticals are temporary fixes, at least for adults. But that's just heresay from the internet, so I might be wrong.

And for the record, since they are always so highly advised, yes, I already have good exercise, recreation and mental reflection routines in place. :)

</comment></comment></comment><comment><USER51> This is par for the course for programming. I usually just shrug, write it their way, and figure it is their money they are wasting. It's my job to mention better ways, but in the end, do it how I'm told. One work place in particular we often rewrite the same thing 3 times over. Sometimes it gets better, sometimes worse. On rare occasions, things do actually work out better their way if they knew a different product was coming down the line with different requirements, or a graphics designer pushed really hard for something that ended up making the app look cleaner or kept her engaged in the project even if it was a PITA for the programmers, etc.. So sometimes you'll discover it isn't so bad after you implement it. For the rest of those times, just grab a personal project, or hit a hackathon, and do it your way. Then don't grasp so hard on having it your way on work projects.

</comment><comment><USER52> You have no power to choose the features you're assigned to implement. The most, then, for which you may reasonably be held responsible, even by yourself, is that you implement a bad idea in a good way. From the sound of it, you've got a lot of practice at that, and you've made it a habit. That being so, you have nothing for which to reproach yourself. Cultivate detachment, and relieve yourself of the need to try to take on more responsibility than your authority can support. This will free you to concentrate on what you can control, i.e., the quality of your implementation.

And, if you can't change jobs, then consider coming up with a side project. It doesn't have to be commercial, or even of particularly general application; even if you're just scratching an itch of your own, it'll give you scope to exercise the agency whose absence in your day job is giving you fits.

</comment><comment><USER53> I can't say how much this post speaks to me. I've felt similarly for the last month or so, or ever since I was assigned my current project. I don't have any actionable advice, so I'll just share my current situation.

Without going into details, in my case the task is implementing a terrible, hacky solution for a total edge case problem. It's something I will probably never do again in my entire career.

It's draining. It claws at my self esteem, as I sit in the office wasting literal _hours_ during a day not doing anything. The output of the 4-5 hours of actual work I put in over the course of a week appear satisfactory to the stakeholders, which is mind blowing.

I know that the sooner I get this done, the sooner I can move onto something more interesting. However, just working on this particular task has sapped my will like _nothing_ I've experienced before in my career as a developer.

</comment><comment><USER54> You're there by choice because your BF needs your help, yet you write about how you're surprised they won't fire you. That probably makes less sense than any feature request they have sent you.

It's a good question though.

After analyzing requests I have issues with, I will setup a meeting to discuss what I think are the issues, and propose a better solution.

If they push it off as "This is what the customer (or some other decision maker) wanted", I ask if we know if they have considered the issues and if we can propose alternatives.

If they still want to move forward, I ask or work with them to discover more detail about how it will be developed, and make sure they fully understand and explicitly acknowledge each piece I think is insane, irresponsible, or otherwise.

It usually doesn't get to that with good managers or clients. If it does, and it happens regularly, it's time to fire them and move on.

</comment><comment><USER55> Don't get so emotionally attached to the job, it is not professional.

Sometimes I have the impression that the younger don't know how to take it like a man. There is a difference between complaining and whining, guess which one makes a man miserable...

Reality is hard to change, but perception is easy. You can really improve your happiness by reworking your perception.

Take some distance and look at the big picture: as an Employee, your main concern is if the pay check cashes. Everything else is ultimately a problem for the business owners (professionals are pragmatic, not cynic).

If your vision does not align with management and you happens to be right, it is a lot more sad for the company than for you personally. It is not your baby - wish them good luck, do your side of the deal as well as you can and don't suffer over it. You have your startup, your own baby to look after.

<comment><USER56> This is really bad advice--realizing that you've spent years of your life punching a clock, working on projects you don't care about, and failing to grow as a person is awful.

The "taking it like a man" thing to do would be to leave, or present concerns to management.

<comment><USER55> I understood he took the job to get the funding he needs for his startup. This is not a purposeless clock-punching job, the man has a plan, stick to it or change it.

</comment></comment></comment><comment><USER57> I was in the same position as you five years ago. I decided to leave and work on my own product. I worked 80-hour weeks for months and years, sacrificed my health and relationships, but the motivation of working on my own thing kept me going. It was incredible. Just a few months ago, the product was acquired, and I joined their team. And now I'm dealing with the same nonsense I was dealing with at the original job.

As developers, this problem isn't going away any time soon. Our options are basically to create our own thing and be our own boss so there is no management to frustrate us, or just give in, write the code, take the check, and enjoy our lives outside of work. It's that simple, but it's also quite liberating when you allow yourself to accept it.

</comment><comment><USER58> I might be playing a devil's advocate here, but isn't our job as an employee to follow the direction and vision of the management? I am not asking you to sell your soul. It's just that sometimes in a career one might need to do work that one considers below his/her capability. My manager sometimes makes me fill up excel spreadsheets of who is working on what and for how many hours. It sucks, I hate it. But I have to do it.

I am not mocking your situation. If it's really bad for you, follow jblow's advice. But if it's a once in a while demotivation, swallow the pain and go on. You will reach greater heights and from there these menial times won't matter.

Just my two cents.

<comment><USER59> > I might be playing a devil's advocate here, but isn't our job as an employee > to follow the direction and vision of the management?

Yes and no.

There's something to be said for just knuckling down and getting on with things once a decision has been made. But, prior to that, any half-decent manager who doesn't know the subject area should have a certain degree of respect for a subject specialist telling them, 'I don't think that'll do what you want it to.' (or words to that effect.)

<comment><USER58> Totally agree with you, Managers do need to respect specialized people, and also vice-verse.

</comment></comment></comment><comment><USER60> Yes, I have been in these situations. For me, there was no getting in the zone - I used to spend a lot of time pushing back, trying to oversimplify a solution, or just freezing because I was not stimulated enough by the task at hand.

Ultimately, I chose the path of gritting my teeth and getting over it. During that phase, the code quality suffered a little, but I did not have to waste hours and hours of my life freezing on it. This phase lasted for a few months in some cases.

This is by no means a long term strategy - I accept it as part of any programmer's life and simply deal with it without being emotional about it as much as possible. I have been fortunate enough to get more exciting work than mundane stuff

</comment><comment><USER61> I don't think that's specific to programming. It's what we all experience when we procrastinate.

Set yourself small very clear goals which you write down and where you commit yourself to finishing them in a given amount of time.

However, what your mind is telling you with the feelings you experience in my opinion is something along the lines of "Don't do this, it's not great".

So when you experience this very often, you need to change something in your life, or else you'll fall into depression because you have overcome your inner hesistation one time too often.

Don't take this as a scientifically accurate account, just my personal experience.

</comment><comment><USER62> You can't care about the problem more than the customer, or you'll go crazy.

That is not to say you shouldn't be proud of the workmanship of what you build (not quite the same thing as being proud of the product).

Unless you have a position where you have design authority, stop worrying about the why, and focus on the workmanship. Impress those that do have this authority with how well you do with what you're given.

If you believe that you have insights into making a better end product, then learn to communicate those insights at the appropriate time (before they've made up their mind). Try to get ahead of the curve and propose your ideas.

<comment><USER63> I'd agree that design and building are separate tasks and they can easily become too complex for one person, so it's best if it's divided. As long as someone 'owns' the design (for good and bad), it's less frustrating as a builder.

It sounds like in OPs case, vague specs means not good ownership of the design.

</comment></comment><comment><USER64> I don't have any tips for you. I am stuck in the exact same situation. I'm actually thankful that you shared your story and several of the comments posted here. It made me feel less lonely with my situation.

The quitting part, moving on to a new job is not an option for me as I am convinced that it is the same exact situation in most businesses around my area.

I started working on some personal projects which helps a lot, but does not solve my problem.

I find myself pushing to the last minute before the task at hand is due. The extra rush of adrenaline from the looming deadline gives me the kick I need to overcome the meaningless work I am about to do...

Good luck.

</comment><comment><USER65> So there's this feature, and you don't like it. You don't want to write it. So your brain starts backing away from it like it's a burning ship. You begin to give yourself excuses. You subconsciously imagine it will take a long time or that it will be tedious. You are basically subconsciously convincing yourself that you will hate it, for any reason. And the less you want to do it, the harder it will be to make yourself do it.

But it's in your head. Using simple tricks you can change how your mind interprets the thing, and put yourself ina more receptive state to be able to accomplish the task without it seeming like a battle of wills.

First, put yourself in a good mood. Listen to your favorite music, eat or drink something pleasant, think about the fun things you'll be doing soon. But whatever you do, don't villify the work or think "I can't wait for this to be over!"; that's just more avoidance.

Once you're in a better mood, walk through the work in your head so you understand everything you need to do, and estimate the time it will take, but shorter. Try to find something positive about it to work towards, or something good or interesting you want to see come out of it. It could be something as simple as timing how long it takes for you to write five methods. To prevent further avoidance behavior, remove your watch and hide your clock. If you can, move to a quiet place where you can focus with the least distractions possible.

At the end of the day, if you really don't enjoy your job, you probably need a different one. But it's a mistake to confuse a bad job with an unwillingness to do work you don't agree with. Consider yourself their savior, and do it in the best way possible so that it minimizes their crappy decisions and emphasizes your skills. Imagine you are a woodworker; maybe you didn't want to build a cabinet today, but you're going to build the best god damn cabinet those jerks have ever seen.

(Also: consider if you will be with this BF in five years and whether wasting this part of your life will have been worth it. Kind of a crappy thing to imagine, but you can't spend your life doing things you don't like just because it makes someone else happy)

</comment><comment><USER66> I stated a new job after living in Europe for 6 months for a change and immediately realised it is the same job I had back home, with the same destination. The mind numbing drain of the IT work juxtaposed with the non office lifestyle I had before taking the job and was literally destroying my soul. I hated it. I now joke that I became an alcoholic in 2 weeks, because I needed to be so blind drunk every night trying to justify how this will be good for my future. And the same as you, the worst part is that my new colleagues liked me and my managers lauded my on how fast I was, delivering great work. I spent the second weekend walking around trying to imagine other jobs, other people, the work culture. Eventually I decided that I could handle the work and push through it, but only if it guaranteed that I could hang out with interesting colleagues and work on interesting problems in the future. I went back my second week and tried to analyse what opportunities I would have given my current role and handed my resignation in after lunch. My boss was shocked, asked if I'd been poached or wanted to work on something else, but I had made up my mind and couldn't wait to try the next thing.

If that story doesn't bring any comfort because you have to stay, one approach is to be open about how you feel at a team meeting and see if anybody else is willing to timeshare the task. However, if this is the sort of task you will always face day-to-day, you will eventually have to decide if that's how you want to feel everyday.

</comment><comment><USER67> I'm glad I'm not the only one that gets this sometimes.

I can completely identify with some of the points made, my particular frustration is working with appalling specifications that are 9 times out of 10 incorrect/incomplete quiet often leading to features being written multiple times. It's demoralizing. I have no particular solution, some will say just knuckle down but it's easier said than done, there are some tasks that just can't be made interesting. Unlike the OP I can change job and am, next week.

</comment><comment><USER68> Argue more compellingly. Your managers don't 'get to' make the decisions, they are responsible for making decisions, using the best information available. As their best programmer, you are the source of that information.

When I am asked to do what is not rational, I refuse and give argument. But to play this card you have to be willing to pick up your coat and leave, not as a threat but as a last resort.

You say you're stuck there, but the reasons are not yours, they are someone else's. Get over that and your options open up.

</comment><comment> peter-row Grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference, right?

Your problem is not really knowing if you _can_ change things. Or whether it's worthwhile to change things. Ultimately, you can't really know whether it's better to try to change things (communicating better, focusing more on design vs writing code faster, getting a new job), so you have to accept that.

So ... whatever you choose to do, you can't really beat yourself up over making a bad choice. It's a hard decision. Whether you stick with the job and try to change people's minds, do things the way you currently are (but without stressing so much), or find a new job is a difficult decision, but no choice really stands out as a clear winner (from the little you've said), so just pick one and go with it.

If you want a new job, go hit up linked-in.

If you want to do things the way you currently are, just accept that programmers "waste time" \- there's a reason why competent programmers often only write 10 lines of code a day - it's not easy work.

You can try to communicate better, but really, some people just don't listen. Or maybe the managers don't have a choice - they either have managers or customers.

Finally, work harder on documenting / presenting your progress. It never hurts to write stuff up, and explain the decisions you're making or the technical reasons why progress is slow.

</comment><comment><USER69> I can't comment on the situation of writing code for useless features for bad managers. That is a separate mental hurdle.

But I think all of us sometimes struggle with sitting down and getting things done. When we have a bad day, it's because we struggled making decisions and didn't end up accomplishing very much in our own eyes. We're our own harshest critics.

One thing that I've realized (actually just in the last few days) is that you simply feel 10 times better at the end of the day if you write a lot of code, knock of tasks on the to-do list, and generally "get things done".

Knowing that diving in and doing hard things will make you feel good makes a huge difference for me. It's like "Ok, this might suck a little getting started, but it's what will actually make me feel good and happy." It's really easy to sit and think, or read the internet, but it's not a good feeling at the end of the day.

As far as wasting time, whenever I'm struggling coming up with an approach or solution to a problem, I start writing it down. It usually doesn't get too far just in my head. But if I map it out, write it out, I get back to working on it much faster. An inefficient solution that works gets you much closer to the final product than struggling to find that "perfect" solution right off the bat. Make it work, then optimize.

</comment><comment><USER70> What are you feeling doesn't have all that much to do with what you do and what perceived atrocities you are paid to commit.

I have same feelings and I notice that they stem more from being responsible (often self assumed internal responsibility) for the state of the system no one else cares about the state of.

You are just lonely with what you do. People love you for the effect of your work, but you see that they don't care about what you do. And it makes your work meaningless (or even detrimental) from your point of view.

You imagine you could take solace from the fact that you system would be architected beautifully without all this crap people who pay you make you put in there. But that's not true. Artists are generally unhappy. They get happy though appreciation, but not appreciation of common-folk that just don't get art. Only by appreciation of fellow artists.

Programming is a puzzle. It doesn't matter what puzzle you solve. Solving a puzzle of not increasing fragility of your system by adding crappy feature is also a (hard) puzzle that can be solved better or worse. Sometimes solving puzzle brings pleasure if your solution is especially good and programmers think that's the right and only way to get pleasure out of what they do. But that's rare. For each time solution itself brought you pleasure you should have at least 10 times where your solution brought you pleasure just because someone seen it, understood it and respected it.

tl;dr Make company hire more competent people that can share your burden.

</comment><comment><USER71> > (I am not in a position to change jobs at the moment. I am helping my > BF's > startup by doing this job.)

Quit. Get out. Work out a plan with your BF. It's no good to you or him if you destroy yourself on work you hate. Be happy and poor together rather than rich and dysfunctional apart.

I've never had to work (for a long time) in a job I truly hated, but I've felt the pain of working in a company with a poor management culture -- it's taken me a long time to get back the joy of development since I left. I now work in a completely different, low paying job -- but it's better being payed less and not having to compromise your work every day. I'll probably end up with another job in the industry (well, I hope, anyway!) -- but I'll be very careful in choosing where I apply \-- unless I manage to make a living independently.

For you it sounds pretty much anything, anywhere would be an improvement though...

I had a gf that worked in a job that crushed her (she did the right thing, moved away, got certified as a padi instructor and now lives with her husband and their child, both working as diving instructors -- I'd say she made the right choice :).

Quitting might not mean that everything works out for you and your current BF -- but it sounds like staying will ensure that things will not work out for you.

Anyway, good luck, whatever you end up doing...

</comment><comment><USER72> As a programmer and perfectionist with Impostor Syndrome ([http://en.wikipedia.org/wiki/Impostor_syndrome](http://en.wikipedia.org/wiki/Impostor_syndrome)), I've learned some ways to mitigate these frustrations and stress causing issues, and figured they might be worth sharing.

I think many of us know your pain, and as a consultant I'm exposed to it on a pretty regular basis. It takes some of the fun out of my job for sure, but I don't let it stress me out. First, we should always want to be passionate about the projects we work on, and I think this is a result of being passionate in general. Being passionate makes it enjoyable, and it allows you to bring your best work forward (which is rewarding), but in our industry we must always create a balance of cost and quality in the midst of a very complex process. To me, this all boils down to priorities and expectations.

When you take your own priorities and combine them with those of someone else, you will never be able to get them to mesh completely. Your priorities may be to make quality code, or to make it elegant or smart -- easily maintainable, extensible, etc. etc. These are things that make it fun, and programmers all know the benefits of these things. Clients, or your bosses, may not understand the importance of these things, or they may, and they may be willing to pay it down later, whatever the case may be, there are conflicting priorities at play and this is the thing you must mitigate to avoid stress.

For me, I must either disregard the external priorities entirely and do it the way I believe it "should be done", or I must disregard my priorities entirely and adopt the external priorities as my own. This may result in technical debt, or a slow progression in the future, or can raise the potential of bugs to be introduced, but these are not my concerns if they are not part of the external priorities.

It's important that you communicate all of my concerns up front, and if it doesn't impact the priorities that are communicated, you must trust that it's ok. If you don't trust that it will be ok, or think you will be negatively impacted by doing it the way you're being asked to do it, you should leave. A management(or client)/ employee relationship is built on trust, and if you don't have that trust you will be less happy than you could be.

</comment><comment><USER73> For one thing, stop feeling guilty.

Whatever the reason you are feeling depressed with your current situation (already lots of good suggestions in this thread), feeling guilty about wasting time or cheating your managers is basically a form of inflicting self- harm on top of everything else.

You're getting paid for whatever you do, and apparently the people that pay you are happy with the results even if you aren't, so just put that aside and focus on what makes _you_ happy.

</comment><comment><USER74> The question I thought this title was asking, and one I'd like to hear answered, is: "What do you do when you're asked to do work that you feel is unethical, as a developer?" For example, I was recently asked to build a system wherein users would be refunded actual money into "credits", and allow the administration to modify the value (1 credit != $1) arbituarily.

</comment><comment><USER75> Just check out. Hang an "out to lunch" sign on your brain.

There is no solution within your reach for management that is ignorant with respect to your job. Stop putting forth extra effort that will ultimately be wasted. Clearly, you have discovered serendipitously that no one can tell the difference between you doing your job well and you doing your job poorly. So stop trying. Just relax and do the first thing that could possibly work. Really build up some technical debt. Management probably does not even know what that is.

That way, you can use the ever-increasing bogosity of the code base as an argument for being resource constrained. Lobby for junior employees that report directly to you. The end goal is to set yourself up for a job hop into a better position at a better company.

The one you are working for now can be definitively marked as a dead end. So milk them for cash and emotionally disengage. Get your spiritual fulfillment by investing your creative talent elsewhere. Meanwhile, coast until you can bail out safely.

That's about what I'm doing at my crappy, soul-crushing job.

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

While that can work in the short term, I don't think it's a very professional thing to do long-term, especially when one couples it with lobbying for things to help you bail to a "better" company. Let go of your caring about the existence of technical debt __temporarily__, but then take some time to go back and address that later.

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?

<comment><USER75> In the situation described by the OP, and shared by many of us, myself included, your managers simply do not care about the professional integrity of the software developer.

My boss has explicitly told me to forget about industry best practices or retiring technical debt. It interferes with the prime directive, which is to log 40 billable hours per employee per week, for as long as the contract gets renewed. The technical debt is simply used as a justification to extract more money from the customer while doing less actual work. In that case, informing the manager gets you reprimanded for destroying his plausible deniability and ass-covering.

There is simply _no way_ to act professionally in this situation. The best thing to do is simply keep quiet and leave ASAP. The emotional detachment is simply to _delay_ burnout and preserve any potential enthusiasm for the next thing.

I can truly say that there is no way I could possibly make the codebase noticeably worse than it already is. It was like that when I arrived. When I suggested that it could be fixed if approached prudently, I was shot down. When I suggested that the developers read a book on better development practices, I was shot down. That was when I sensed the knife against my back ribs and checked out.

Stay sane. Use the opportunity to be more selective in your continuing job hunt.

</comment></comment></comment><comment><USER76> 1) Look at the problem a different way and try to find a way to make it more interesting, attractive and (most importantly) impressive. I had to find and fix a tedious problem so I wrote a visualization, defect detection and automatic correction tool. If you have the freedom, try solving it with a new language or technology that you've always wanted to learn.

2) Challenge yourself to finish the project as quickly as possible. If a realistic estimate is that the work will take 1 week then try to finish it in 1-2 days. If it is awful work, try to get it over as quickly as possible. It helps if you can find an existing solution that you can use as a starting point.

3) If you're paid hourly, you might consider outsourcing the problem to someone off of elance. You should reframe the problem so that it doesn't require you to share any info (source code etc) from your employer with the person you outsource to. Ideally, ask the person to create an open source project on github.

</comment><comment><USER34> OP, do not listen to the moralizers who tell you that you need to exercise discipline and will power. Let them deplete their limited reserves of will power and see how far it gets them: you can change your environment so that you thrive in it. And that beats relying on will power and discipline by orders of magnitude. Quit early and often.

</comment><comment><USER77> I spent a lot of time forcing myself to conform to others' wishes and will. Or to "work around" the problems, e.g. by staying late -- both to get some quiet time at work in which to concentrate, and to avoid some nasty neighbor issues at home.

Ultimately, I ended up at another definition of that word: "Spent".

I'm just saying...

</comment><comment><USER78> Have I been in these situations? All the time. I care about the software we produce, so I have strong opinions about the development of it.

How do I handle it? I say my piece, I listen to the response from my boss. If he disagrees with my analysis, then I accept it, sit down and do the work to the best of my ability.

</comment><comment><USER79> you have to make a choice imo. you can either suck it up and get on with it or flat refuse to do it. if you feel strongly enough then refuse to do work and quit the job... fulfil your contract to the minimum possible whilst giving them every legal reason possible to want to pay you to go away.

however i feel inclined to reserve that for serious problems, like weak leadership, oppressive or immoral behaviour etc. rather than poor features or undesirable work...

doing things you don't want to do is part of work. letting your leaders make their mistakes and learn from it is part of it too. i'm strongly inclined to say you just need to grow up a bit and get on with it... and be grateful that this is a 'problem' for you because its nothing compared to what most people consider to a problem in the workplace.

</comment><comment><USER80> A very short mantra that has helped me: "Own what you own".

That is, if I see a project as someone else's, and my job is to help them do their best, I am happier than if I see a project as "mine" and other people are just screwing it up.

Like many important life lessons, I learned this one a day too late.

</comment><comment><USER81> Find something about the task that intrigues you, and build your motivation around that. A new gem, or new language feature, etc.

I've also found focusing on tests helps. Write as many tests as possible - focusing on getting those to pass. In theory, by the time you're done, the feature will be to.

<comment><USER63> Just first ask yourself if the next person to work on this code will appreciate the 'new features' you used.

<comment><USER81> Always a good point. Based on OP's description, they may not feel the next dev would appreciate the code at all, and it's just a matter of fighting through this feature on a personal level.

</comment></comment></comment><comment><USER82> Like others, I would encourage you to take some time off before you burn out. However, I also understand what you mean about not being able to escape this job.

I've had numerous jobs where I felt I couldn't leave for certain reasons. I would stay usually a few years too long and later come to regard the decision with a mixture of regret and weird, sanctimonious pride.

Take a few hours today and read Man's Search for Meaning by Viktor Frankl. It's a short book, written by a psychologist and concentration camp survivor. The book demonstrates that is possible to find meaning in the worst situations, especially those you "cannot" leave. It may also help you understand why you need to think about choosing a different path.

</comment><comment><USER83> I wish I was done with the series of blog posts that helped me get over this! :)

I struggled with this for years and years. This is not one problem , but three: it is a problem with wisdom, speed, _and_ discipline.

Luckily, we can learn tricks to improve each one.

If we want to attack this from the wisdom perspective, it is this: You are afraid of making the wrong decision because you are afraid to refactor. You are afraid to refactor because you don't have sufficient test coverage.

The good news is, for developers like us, test driven development is very helpful as a technique for getting us over these problems. If our team is not test-friendly, however, it will be difficult for us to make the jump because their code will not be written in ways to make it easy to test.

There are a few books I can suggest to help us jump the chasm:

1\. Clean Code by Bob Martin. This book helped me think in more testable code, and also helped me understand how to make better decisions the first time around. It helped me by seeing patterns I didn't know first.

2\. Refactoring by Martin Fowler. This one is old, but knowing the patterns of changing code gives us more confidence in knowing what is right, rather than hemming and hawing over what is readable and maintainable.

3\. Refactoring From Legacy Code by Michael Feathers can help get from here to there. All of these help from three aspects: They help us develop a set of tests so we are less afraid of breaking existing things, they give us the freedom to experiment, and they help us break things down into smaller, more manageable problems by letting us think about "what is the next thing I can test?"

If we have the tests, we can be more aggressive in reducing complexity.

___

If we want to attack this from a Speed issue, then look for these things.

1\. Look for patterns you use repeatedly, and try to settle down into a process. The fewer choices we make, the faster we can go.

2\. Look to learn more about your chosen stack and language. It is possible that we are rewriting the wheel over and over. The more you understand the zen of your stack, the faster you can go and the more time you can devote to writing the same thing twice (without them knowing.)

3\. Instead of hemming and hawing about the right solution, write all three. It is often faster to write all three and choose one than to get stuck in analysis paralysis. (That isn't to say you shouldn't think before you write code!)

___

Finally, you can attack this from a discipline angle.

1\. Learn to meditate. By doing so, you can become more self-aware of analysis paralysis, calm your mind quickly, and mindfully choose a path.

2\. Exercise. In the same way as meditation, exercise helps us learn to clear our mind and focus on command, and it helps sharpen our discipline chops.

With these, we can develop an awareness of how our body feels. Then we can develop an awareness of how analysis paralysis feels. If we can catch ourselves in the act, we can then institute something from our analytical skills: When caught in the trap, set 30 minutes on your timer, and bring out a pad of paper. If you feel you have the freedom, turn off the monitor.

Take deep breaths, and sketch out the solutions in the first ten minutes on the first page. Use UML or your own system.

In the next ten minutes, write a pro/con analysis on each path.

In the final ten minutes, make the decision. After this, your analysis time is up and you must code.

I suggest a combination of the above.

Good luck! It was one of the hardest things for me to defeat.

</comment><comment><USER84> It seems to me that this kind of situation is what some types of programmers try to escape by creating "amazing" code. This is the kind of code that you come back to a little while later and wonder what you were thinking when you wrote it.

</comment><comment><USER85> Been there before, luckily just few times. \- Put yourself in a good mood, music helps a lot, energizing beats, try Panjabi MC! \- Slice the feature into small deliverable, hint: use index cards and a sharpie, yes, it's magic. \- Finish one story (index card) at a time and have a tiny celebration (coffee, cookie, walk ...) every time you do that. DON'T skip the fun part.

Always think of yourself as an explorer collecting and connecting clues on a mysterious adventure!

Keep in mind, business drives programming, not the opposite. The codebase is only worthy as long as the product is selling (with the help of your managers).

</comment><comment><USER86> Could be just laziness maybe. Mixed with possible relationshop pressures (hinted by earlier submissions I noticed).

"My managers don't fire me". Perhaps show managers the post written here? I dare you! But they pay your wage.

Put headphones on and listen to the right music or something to encourage focus. Yep!

I think everyone is in the same boat as you in some way or another. "wasting considerable amounts of time" could be a worry though.

"Seriously affects the quality of my life"... surely the quality of your life is not a consequence of "unnecessary complexity in the codebase"? Good luck anyway :)

Edited - I'd had some wines

</comment><comment><USER87> >>Have you been in such situations?

Similar - not coding though.

>>How do you get in the zone and get it done

I treat it as an optimization problem. Specifically because I have a problem with this too:

>>I waste considerable amount of time trying to do things in the most readable, maintainable and simple way possible

So I consciously aim to force that compromise between quality & time more towards the time side. That goes against my fundamental nature, but I've come to the conclusion that I must learn this...and as a result it feels more like a learning & personal development challenge rather than me doing something I don't want.

</comment><comment><USER88> Consider the following - maybe your managers realize how vague task is, they also realize that you put a lot of pressure on yourself to make it, as I understand without strong support. I have been many times in same situation, usually when this happened first: I read "The humble programmer" :-),which reminds me that there is always something that I don't know, second: look again on the task and try to find its challenges, things that after completing them will make me a better programmer.

</comment><comment><USER89> Great question and I imagine many people have been in similar situations. I can offer a few lessons I have learned over the years. 1\. When I found myself in a situation where I didn't connect with the mission or purpose of company/project, I would eventually hit a wall similar to the experience you described above. If you can't find any way to connect with the cause, I would at a minimum be open to making a job change. 2\. There have been many occasions where I felt like I couldn't influence something to make the outcome more in-line with my ideal outcome. Two changes in my behaviors greatly reduced situations like this for me. First, Be open and honest with your manager. Explain to he or she that you feel more connected to a task/role when your input is valued. Keep in mind someone valuing your input doesn't always mean it will be implemented or acted on at any greater frequency. Second, I used to focus on what I can do to produce positive results without much consideration for others needs. One of my mentors suggested I spend an equal amount of time learning what is important to my managers/leaders and peers. Doing so enabled me to think more deeply about the outcomes I was striving for and how those would resonate with the folks calling the shots. I started to proactively address concerns I new would be present and any proposals?ideas I shared were positioned in a way that would show consideration was given to all the main issues that were important to them. Over time, I earned a greater degree of trust and my leadership team started to take my advice/input more seriously. One final thought and related to what I previously shared. Your situation above makes it seem like the spec for a feature was handed to you after it was already determined it would be implemented the way it was provided to you. In my experience, that has almost always been to late to influence change I viewed to be favorable. Circling back to my first point above, being more open about the need to contribute and share ideas will hopefully open the door for you to get involved before all the details have been finalized.

I could share several other examples from my work experience. On a more personal note, I noticed you are doing this for your BF. In the short term this might make him or both of you happy. I was in a somewhat similar situation before and the resulting unhappiness from doing work for an organization that had goals/mission I didn't connect with started to negatively impact my marriage.

</comment><comment><USER90> I just read this stern but lovely dirge in a novel last night..

"Do you wrestle with dreams? Do you contend with shadows? Do you move in a kind of sleep? Time has slipped away. Your life is stolen. You tarried with trifles, victim of your folly."

Life is short. It is time to see through the trap you have woven around yourself and move along. Just do it constructively so that in the end, EVERYONES interests will be better served.

</comment><comment><USER91> You've got a huge opportunity here to practice the art of Managing Up and Managing Oneself -- impacting your quality of life.

\- Eliminate ambiguous requests. Can you probe for your managers stated/unstated objections & needs?

\- What's the expected outcome? Are your recommendations easily understood and compelling? Is your business case sound?

\- If the managers are happy with schlock work, can you ever be OK with that?

Ultimately, the power is yours.

</comment><comment><USER92> The advice of burnout, changing jobs, etc is well covered already.

I have been doing sole crushing work for years in school. When you don't have a choice, the most useful thing for me to get started is the pomodoro method. Spend just 25 minutes of agonizing work and plan what you want to do for the 5 minute break. Usually after 1 or 2 cycles I actually get focused and motivated enough to make some progress.

</comment><comment><USER93> This advice was given to me by a friend when I was dealing with less than ideal employment situations.

1) Change the way you feel about the situation. Is this a me issue?

2) Change the situation externally. Talk to management, etc.

3) Leave

It sounds like you've tried #1 and #2 to some extent. I was in a similar situation. I left the company, and found a much healthier environment where I can actually use #1 and #2.

</comment><comment><USER94> I recognize the situation. Seems like the project is lead by people who have not failed before because of feature creep. If you get paid by hours then keep logging hours and try to be happy. But make sure they know about your concerns and feelings that their decisions may derail the project. And keep looking for a peaceful way out.

</comment><comment><USER95> If I was in that situation I'd try to get a different job. I know how hard it is to do that in the current economy though, so failing that I'd just do the minimum needed and be uncompromising about working only the assigned hours so as to maximize my utility outside of that particular employment role.

</comment><comment><USER96> Just search the internet for "get the shit work done" to find the answer for your problem. Really. You can find also some good practices.

I believe that most of our jobs can be divided to two parts:

-the fun part (interesting/fun/profitable work)

-the shit part (boring tasks/emails)

So, just get the shit work done when it needs to.

</comment><comment><USER97> You should change jobs. I know you are trying to support your BF's startup (do you have equity in it?) but if he really cares about you he'll understand that you are on the brink of utterly burning out and need a change.

</comment><comment><USER98> Coffee and smoking make this much worse for me. (In fact when I don't smoke and drink coffee I don't have this problem - whereas when I do, I do.) Leaves me to conclude that it's based in anxiety.

</comment><comment><USER99> I wouldn't say that my, "entire being opposes the task at hand". I would reserve that sort of language for ethical reservations about a task. I do not do things I consider unethical.

But I do encounter many chores in my work that are boring, that are bad ideas, that are for difficult customers, or often all three. I can have the same problems getting those tasks done, just like you describe. Actually, you seem to be way ahead of me because it took my far to long to figure it out. I thought I was losing my ability to program. I was wondering if I was going to have to find another career because I had lost my ability to concentrate. I was reading books on getting things done, and concentration and trying to figure out what the hell was wrong with me. I would sit down to do a task, check email, check reddit, check hacker news, check reddit, get coffee, go to the bathroom, check reddit, "Arg! I have shit to do!" Check reddit, check IRC, etc. I caught myself more than once closing a browser tab with some distraction, pausing for a half moment to organize what I should actually be doing and then open a browser tab to the same thing again.

The insite came when I finally got something engaging to do, and I just powered through it. I _could_ still program! How did I get in the zone? How do I get there again when I need it? Well I worried about hat for a while, thinking there was some combo of sleep, nutrition, environment and task management software that I could line all up and get back to "the zone". It finally dawned on me that I subconsciously find distractions to avoid doing things I don't want to do. What a revelation.

How do I get over it? Well I still struggle with it, but simply identifying the problem was a huge step towards fixing it. Here are some techniques that I use:

Pomodoro technique. This is a productivity trick that actually works pretty well for me. The short version is that that you make a list of very small tasks, then work for twenty minutes (straight! no phone, no emails, no coffee, no bathroom), then take a five minute break. This helps with distraction problems because you can tell yourself, "I can goof off in 7 minutes". It sounds like a lot of interruptions, but I'm amazed at how much I get done with it.

Creating crisis. I work harder with the Sword of Damocles hanging over me, so I put those swords there myself. Call me back at 2:30 and I will have this done. Then I'm good for two hours of, "oh shit, oh shit, oh shit," type production.

Pair programming (and rubber ducking). This really helps to power through crummy tasks. Unfortunately, I work from home for a tiny company. I don't have anyone to program with. But if I am really stuck, I can ask my wife to sit next to me, while I explain what I am doing, and what I am trying to accomplish, and the details of what I am coding as I code it. I can use this occasionally to get over a hump.

Change of venue. I have struggled to find some shitty bug in some shitty spagetti code for a crappy website selling stupid things for WAY too long. The only way I broke through was to take my computer somewhere else, in front of other people. David Sedaris has a great story about a book suggesting he make a change in his house to help him quit smoking. Buy a new couch or something in order to change the venue. In our comfortable habitual surroundings we act in comfortable habitual ways. So he moved to Japan to stop smoking. I can't do this every day, it's just for breaking major blocks.

Anyway, I need to get back to work. Good luck!

<comment><USER100> Just wanted to chip in to say that the pomodoro technique works really really well, but maybe best when I actually know what I should be doing. Setting a pomodoro task of 'let users choose colours' is easy, but 'improve load times' is harder. I think the specificity has something to do with it.

But when I get tasks that lend themselves to it, I often find myself skipping the breaks and starting another session straight after, which is great.

I stand up when the timer goes off to try to combat the effects of sitting for long periods.

</comment></comment><comment><USER101> Frankly, it's just called programming. Programming is that pesky, resilient three-headed monster between your idea and the finished product, you have to give in and tame it.

</comment><comment><USER102> My suggestion: Major lifestyle change before you burn out and involuntarily go out of business for six months. Take control of this while you still can.

</comment><comment><USER103> Don't let yourself get paralysed by indecision.

</comment><comment><USER104> Learn to write GOOD test suites. Once you realize that they are preserving your sanity, they will actually become fun to write.

</comment><comment><USER105> Exercise.

Meditate.

Cook.

Listen to music.

I never found the ability to rationalize a task I dislike. Instead, I find joy elsewhere and try to preserve that feeling as I tackle the task.

</comment><comment><USER106> > What do you do when your entire being opposes the task at hand?

...anything other than the task at hand, obviously. :-)

</comment><comment><USER107> sounds like you might need therapy. I've had a similar problem and speaking to a therapist helped.

</comment><comment><USER108> Express your concerns, do the work as well as you can, find another role.

Basically.

</comment><comment><USER109> I feel you. I don't have a solution.

</comment><comment><USER110> Open HN.

No, seriously. I go work somewhere where people can see my monitor. Helps me keep out of Facebook, etc.

<comment><USER111> This is a good advice for people who are temporarily in a bad mood.

However, it is the totally wrong way to fight an upcoming burnout.

</comment></comment><comment><USER112> I'm not going to tell you about your job or surrounding, but a little about how your brain, or rather everbody's brain works.

The problem at hand is a relatively unknown psychological issue.

There are many theories about motivation. Most of them don't account for a specific type or situation, where someone is just not able to do a certain piece of work, without having a reason like lacking the time, health, skills or energy. These types are often just dismissed and dubbed underachievers, because, for some reason, they fail to acomplish tasks which they should be perfectly able to do. They procrastinate and do a million other things first or just give it up completely.

It doesn't matter whether this task is about work, university grades, doing lab-experiments, the laundry or else.

== The theory ==

There is a austrian psychologist, Brigitta Rollett, who coined a term called "Anstrengungsvermeidungsmotivation" which translates to "effort avoidance motivation" or "stress avoidance motivation".

The first essential postulate of the theory is, that having the "motivation" to avoid stress, or efforts that cause stress, isn't an illness or failure, but rather an evolutionary advantage to prevent burnout and similar issues. All people tend to avoid activities, which cause them stress or more specifically the very basic emotion of disgust. People have different pattern and triggers which lead to the feeling of disgust. This is heavily primed by upbringing, schooling, bad experiences etc. You seem to be disgusted by "useless features". (I am too. :))

The second essential postulate of the theory is, that this disgust is more or less "invisible". Most of the time it goes unnoticed. It is such a strong emotion that people never even want to "go near it", because it would cause them IMMENSE emotional pain. This pain can even translate to physical symptoms like head-aches etc.

This is how the afore-mentioned "underachievers" are explained. They don't have a problem per se. As long as nobody forces them to do the specific tasks they don't like to do, they live happily ever after. People with a high IQ tend to learn a lot of these "disgust" pattern, because on the one hand they are often confronted with teachers, who don't understand them or meet them with antipathy and on the other hand they never needed to learn to deal with "repulsive efforts". Contrary to most people they get by, without ever having really stressed themselves. Should they come into a situation, however, where they HAVE or WANT to deal with a task, which for them is linked to disgust, they fall into complete despair. They do everything to get away from the triggered emotion. It's literally TERRIBLE for them to do some kinds of work, which aren't a problem for most others.

There have been many scientific studies, tests and validations of this (in german).

== Your situation ==

First you have to acknowledge and understand that what you are experiencing is an irrational and immensely intense emotion.

Emotions don't think. When you encounter one, you have to decide how to act on it. If your job sucks it's probably a good idea to just work somewhere else.

But you like your job. In your case, the emotion just tells you that you HATE this type of work-situation. And for whatever reason you are not able to just acknowledge that, bite the bullet and move on. (Which is how people are able deal with most bad emotions.) In this particular case your brain throws one hell of a fit. Neurologically speaking and simplified, your rational forebrain looses control over your amygdala and the "more emotional" parts of your brain.

== What you can do ==

You can always make sure the situation never happens again, and avoid the dreaded tasks, but this probably won't work without giving up programming.

What you have to apply are the same strategies which are needed to conquer other emotions-gone-wild like irrational fears.

~ You NEED to work on it SLOWLY but STEADY. ~

* The bad news: I hate to tell you this, but if you want to change your behaviour, you NEED to sit down and start doing the exact work which triggers this cascade.

* The good news: Each day, or session, you only need to conquer it ONCE.

Sit down for the task and start with the tiniest bit. Just open the first file. When you FIRST feel the terror overwhelming you, you HAVE to force yourself to keep at it and wrestle it down. When you feel the terror approaching a SECOND time, you can stop. If you have the energy to continue, do it, but I doubt you will. Don't stress yourself too much, or it will backfire. (You won't)

This might sound incredibly stupid, but be proud of yourself at this point, because you have just delivered an immense piece of emotional work and it's ok to be tired now. Even if you just typed three words.

Keep repeating this practise each day, twice a day or how you see fit, and slowly but steady the terror will fade. It will come slower, lighter, less often. If you keep doing this, i will GUARANTEE you that these shenanigans will stop. You will slowly replace the old neurological patterns which trigger your pain. (And pain is exactly what it is.)

Unfortunately there is no faster way for this. You can look into hypnotherapy, which can accelerate matters a bit, but working on emotions always takes it's time. I have applied these techniques myself for a couple of situations. It was immensely exhausting, but it's worth it and it works.

Good luck.

<comment><AUTHOR> Thank you for your advice. "Your brain throws a hell of a fit" sounds just how it feels :)

</comment></comment><comment><USER113> you quit.

</comment><comment><USER114> While I can 100% relate to your scenario, a big part of being a professional at any job (not just development) is being able to set aside your personal feelings and emotions and get your job done.

It's good that you are getting your job done, but it seems that you are still having issues setting aside your personal feelings and emotions. This is pretty normal for inexperienced developers. It's something you should focus on working on.

Here's how I developed that skill:

1) Remind myself that this is not my company or my project. It's someone else's. There's no reason for me to feel so personally invested in the project as a whole. If I've voiced my concerns and thoughts and been overruled, then my job is to get what is asked of me done to the best of my ability.

2) Have side projects that ARE personal and that I CAN be emotionally invested in. When you have a side project where you do call the shots and it's done 100% the way you want, you will find it is easier to not be so emotional over your day job.

3) Lastly, I have found that as I get more experienced and better at explaining myself, situations where managers overrule me and tell me to do something that is against my own recommendation become more and more rare (they'll still happen sometimes as long as someone above you can make unilateral decisions, so never expect it to fully go away.)

It's good that you've recognized your situation needs to change. Best of luck.

<comment><USER63> I like all your points, but option 2 is very intriguing. I've never had the time for that, given I use all my mental and physical capacities for my day job. So I'm conflicted; I just don't think I'd have enough time to do a side project to the standards I'd expect of myself.

I think that's also why many posters here are saying 'use some new language feature X to make your work project more exciting' \- basically adding a side project into your day job. [I think that road can lead to ruin, if you're making it harder on the next person to work on the code. Be careful and considerate.]

<comment><USER114> I know a lot of people work that way (using new technologies in their day jobs) but personally I take my day job too seriously to do that. I learn new technologies by doing side projects. Then once I feel comfortable with them I can start using them in my day job. I don't want to look my boss or coworkers in the face and say "Yeah that fuck up was because I was using this project to learn a new thing."

I think you're over estimating how much time you need for a side project. You can even just spend a couple hours on a couple weekends a month on something. Or even every other month. You don't have to work on it every day or anything. That's the great thing about it being a side project. There's no rush. No timetable other than whatever you choose for yourself.

</comment></comment></comment><comment><USER115> Get someone else to do it.</comment>