DEV Community

Cover image for How to handle working on something you do not like
Dustin Robison
Dustin Robison

Posted on • Originally published at corpcoder.dev

How to handle working on something you do not like

The Problem

A corporate coders true dilemma: being told what to build and how to build it.

Every corporation has non software developer leaders that often are making technical choices. In an ideal corporation the business leadership would focus on what they want and leave it to the technical team to resolve how to build it. Some negotiation would take place over timelines and features but the end decision would result in the business choosing a product and the technical staff choosing a method of creating the product.

I personally have been on the receiving end of being told how to build things by non technical people multiple times in almost every corporate job. It is more common at larger companies but also happens at smaller companies as well. At one large company we were told to use a tool that really did not fit our use case but it had a large price tag and great presentation with big promises. At another large corporation a developer pitched an idea of a way to build things with "no code" and had leadership sign off creating a large complexity headache for all other developers. At a small corporation I worked on a valuable new piece of software that was shut down by an executive because he only wanted to pay for "the standard approach." The developer subsequently left and created a successful startup.

What is important to you?

This is the real question: what is important to you? Or really, what is the relative importance of how you are working vs other concerns?

  • How important are those paychecks, benefits and stability to you?
  • How important is your pride of craftsmanship?
  • How important is your corporation or business units mission?
  • How important is your company position?
  • How important is your geographic location?
  • How important is your career path?
  • What are the other important factors?

The common case: a job is just a job

For most people a job is just a job. In my opinion these people aren't wrong at all, in fact they may be the most correct. If you can be satisfied making your objection about the poor methodology choice but still work hard as normal then that is great. You must still be achieving the things that are important to you and in the end you will likely produce a good product.

There are risks with this of course. Corporations have no guaranteed commitment to their employees (or vise versa) so if suddenly you are out of a job then your options may be more limited.

The noticed path: my way or the highway

For some people the work that they do defines them and doing anything less than their optimal solution would directly lower their self worth and positive impact they can have on the world. This is a hardline dangerous road however many great new corporations have come from this. I don't recommend this path because I think there is a slightly better option that I will discuss next but if your current job is bad for your mental or emotional health and you can't take it anymore then perhaps this is your only true option.

If you think this is the path for you I would encourage you to take a step back and breathe and really consider what is important to you. What motivates you? Maybe a paycheck, benefits and stability are not important factors for you but they are sure are nice to have and it is extremely risky to drop a job without even a career plan.

There are also ways to mitigate the negative emotions of working on something you do not like that I will discuss at the end.

The patient path: the grass is always greener

Everybody has heard the adage, "never quit a job until you have another one." It is great advice but also lacking. If you don't like your current responsibilities will taking a new role be better? Maybe, or it could be worse. As corporate coders we have to understand that we surrender most of our power to decide how we go about our work by taking a paycheck. Our primary clients are often our superiors, the person paying you; not necessarily the end users of our software. Your primary customer is always right.

I encourage software developers to be patient and find out what is important and motivates them. The answer is often different than we would first think and if you do not know, then that is okay too. If you have served enough time to make your resume look good in your current role then patiently try looking for a position that you think may suit you better and learn from each role. Make friends with your coworkers to open new opportunities and get their input as well.

A simple mitigation strategy

If you are unhappy that you do not get to do the work you want to do then a simple answer would be to do the work you want to do in addition to the work you must do. Discuss with your manager if you can spend some of your work time on a new idea or just simply work on your own project outside of your work hours.

For example, if your job has you working in Python but you like working in JavaScript then do your Python during work hours and do JavaScript at home. To get a job doing JavaScript you will definitely need current experience and probably a portfolio. Learning and doing more will lead to greater opportunities.

Conclusion

Find what motivates you and what is important to you through experience, patience and perseverance. Once you know that you can be happier in your current role or you can decide how you are going to achieve your goals.

All my posts are based off my personal experience and I would like to hear if you have had a different experience or comments

Thank you for reading! My blog: corpcoder.dev

Discussion (0)