How to break this vicious circle?

Question

I was hired one year ago in a small company that works on utility apps, as a frontend developer. This company is very small and has more apps than developers, and often we work on very small features than in my opinion are not enough challenging. IMO we have low quality code and I think that the whole company often focuses on formalities and small details (e.g. "should we put a newline at this point of our code or not?"), while neglecting important things (e.g. using outdated practices that can lead to bugs). The feeling is to work in a small and boring company where no important things happen, and the most pressuring thing that you can get is to work on a bug that affects a a few hundreds of users. So since everything is boring I can feel that problems are magnified, often because there is nothing to discuss so issues that normally would have low priority become important in the eyes of my colleagues.

The thing is that I really didn't like it, I was also working on micro-features and I felt that I had coding-monkey tasks, so I made the horrible mistake of not giving importance to my tasks, also because I though that they weren't so important for the company, since I couldn't realize how those micro-features were somehow important for them. So I was often making pull requests without double checking, and it was happening sometimes that my features were breaking existing functionalities, or that my bug fixes weren't working; and for this reason, I lost the trust of my senior. And he didn't directly tell me that, he went straight to my manager and I wouldn't say that I was nearly fired, but he told me that if I didn't improve certain points I was not going to have my contract renewed.

So I've promised some change and I started making an effort to double check everything and to do my micro-tasks with extra attention, and after some time I was told by my senior that he noticed some real improvement, and I think that I have good chances of getting my contract renewed. But the fact is that now the development manager (who is also the product owner) has no idea of why I was underperforming (I felt like telling him the real reason was going to put me in further troubles), so he really thinks that I was underperforming because I don't have enough programming skills. As a result of this, I can see that often I don't get assigned hard tasks. My tasks are way too simple. So basically I underperformed because I didn't like my tasks, for being way too simple, and as a result I am getting assigned even easier tasks.

Now there is also a parallel problem going on: the company culture. The mentality is: "if we have to do the feature Y, we go to mister X [let's call him this way, He is not really a single developer, it may be one senior or another who is expert on the matter], who is the most expert on the matter [also because he learned how to work on Y on his extra time], and we tell him to do the feature". As a result, mister X's knowledge improves even more, but other developers' knowledge don't improve. I would say that the more you know, the bigger are your chances to learn; the lesser you know, the smaller are your chances to learn because they think "this task is too hard for you, let's give it to mister X". My colleagues don't seem to give too much importance to this issue, but my feeling is that the company really doesn't care about the personal growth of its developers.

Now I really don't know how to break this vicious circle. It would be easy to say "change company", I am trying but now it's hard for me to find another company since I have few experience and most companies want already experienced developers. I would like to have some suggestions.

Answer 1

"Underperform[ing] because [you] didn't like [your] tasks" is the sign of a very poor employee, and, in my mind, you are rather lucky that you didn't get fired given that you repeatedly made changes where your new "features were breaking existing functionalities, or that [your] bug fixes weren't working".

It seems like you are now aware of that, and are working to reestablish your manager's trust, and have actually been successful in dong so.

The best way that an employee can convince his manager that he or she deserves more complicated projects is by having a history of success on their projects. Keep doing the best job you can do on your assignments.

At the same time, take the initiative to fix some of the "neglect[ed] important things". In your spare time, research solutions to these issues, and then propose that your boss let you build a proof-of-concept of one of those solutions (or develop a plan to do so, etc.).

This is a great way to learn new, exciting things; help your company solve some of their problems; and (most importantly) develop a track record of success.

In my experience, at least in a the field of software development, the best, most successful employees are those that take initiative to solve some of the actual problems the firm is facing.

Answer 2

I used to have similar thoughts and problems, frowned upon my colleagues for not respecting best methodologies and thought I was better than most (not saying you think this, but I did when I was junior), but as I eventually become more experienced, I understood I was missing a big part of the picture.

I underperformed because I didn't like my tasks

Well, no, you underperformed because you lacked professionalism. Being a developer doesn't mean exploring new grounds of algorithmic every day. Some of my tasks don't even involve programming, just changing configs somewhere. You could call it straight boring, but doing so reliably and without breaking anything is what engineering is about. "double check everything" is part of the job, the least you could expect from a bugfix is that the engineer would certify it fixes the damn bug. The fact you should test that is implicit; it's simply professionalism.

Another field of improvement regarding your work, is to understand the impact of your work. It seems you don't, and don't try to. You think the company have low quality code and the focuses on formalities, on the other hand, you admit later "I couldn't realize how those micro-features were somehow important for them". You are working for this small company for a year, yet you don't understand what are important things for the business. How would you want the company to give you freedom, if you show so little interest in satisfying the clients ?

---

Update:

After discussing via comments and chat, I get a more nuanced vision of the story than your initial post describes and think my answer disregard too many important real issues you raised about your current situation:

• You are in a context where people are suspicious of your skill and give little credit to your input
• The job involves repeated and extensive testing, to the point you don't feel valued as a programmer
• You have few prospects that the situation improves on the short run and quitting is uncomfortable

You have objective reasons to feel demotivated in that context, and there's no easy way out. You made choices in your career path you may regret, but a career path is not something you are powerless on. You can work on what motivates you and could improve situation, and give yourself small objectives regarding that:

• Take some time to learn new things browsing when you feel allowed to i.e. doing technical watch, and technical pet projects outside of work, learning new frameworks, languages, libraries
• Take some time to learn how things work currently by browsing source code and asking questions to more senior developers, question their development choices and discover reasons why things are the way they are

Dig on professional interest, especially if related to company life or programming. Improving your skill set is good to your career path regardless if you eventually leave or not. Some of this may mean extra effort or extra work, but you have to weight pros and cons of pulling that vs staying in a situation where prospects are really bad.

Answer 3

The thing is that I really didn't like it, I was also working on micro-features and I felt that I had coding-monkey tasks, so I made the horrible mistake of not giving importance to my tasks, also because I though that they weren't so important for the company

This is indeed a horrible mistake. For your company these tasks might indeed be not that important, but you forget that they are important for you, to demonstrate your capabilities.

The company has no reason, to take a risk and give you an important task, if you haven't shown that you can handle it.

but my feeling is that the company really doesn't care about the personal growth of its developers.

Now the most important lessons: It is not your companies responsibility to care about your growth, it is your responsibility! Your company might or might not have in interest in growing their developers, but usually they would invest in what they see as high-potential candidate rather than under-performers.

Now to answer your question from the title:

How to break this vicious circle?

1. Work on your motivation issues and take every task serious. Show that you are reliable.
2. Seek a dialog with your manager, tell her that know you made a mistake by not taking tasks seriously and tell her that you don't intend to do that again. Your manager might be relieved that it is a motivation issue that can be fixed and will notice when your work improves.

There is a chance that this won't work, and you cannot salvage your reputation. If that is the case, shit happens, then it is time to move on and look for a new job. But even if you start looking for a new job that doesn't mean that you can stop taking your job seriously. Being a good developer isn't something you can just turn on and off, it is a muscle you need to train, so you better keep it trained you will need it for your next job, to make a perfect impression from the beginning ...

Answer 4

All bolded words are my emphasis:

I was hired one year ago in a small company that works on utility apps, as a frontend developer. This company is very small and has more apps than developers, and often we work on very small features than in my opinion are not enough challenging. IMO we have low quality code and I think that the whole company often focuses on formalities and small details (e.g. "should we put a newline at this point of our code or not?"), while neglecting important things (e.g. using outdated practices that can lead to bugs). The feeling is to work in a small and boring company where no important things happen, and the most pressuring thing that you can get is to work on a bug that affects a a few hundreds of users. So since everything is boring I can feel that problems are magnified, often because there is nothing to discuss so issues that normally would have low priority become important in the eyes of my colleagues.

It sounds like you are an expert in a set of fields and work functions as a front end developer, however your company is small. Your direct boss, might not be as knowledgeable as the same fields as you are. What is simple for you, might be a foreign concept for him/her. Have you had a 1:1 conversation with your boss and voice your concerns?

The thing is that I really didn't like it, I was also working on micro-features and I felt that I had coding-monkey tasks, so I made the horrible mistake of not giving importance to my tasks, also because I though that they weren't so important for the company, since I couldn't realize how those micro-features were somehow important for them. So I was often making pull requests without double checking, and it was happening sometimes that my features were breaking existing functionalities, or that my bug fixes weren't working; and for this reason, I lost the trust of my senior. And he didn't directly tell me that, he went straight to my manager and I wouldn't say that I was nearly fired, but he told me that if I didn't improve certain points I was not going to have my contract renewed.

This is a warning sign from their perspective. You didn't verify the importance of a task, no matter how small, and the stakeholder of that task was not happy. You also lost the confidence of your boss. If anything else, you should sit down and understand where you screwed up, communicate what steps you would do to improve, and most importantly, keep your eye on the ball and make sure you deliver on your promises.

So I've promised some change and I started making an effort to double check everything and to do my micro-tasks with extra attention, and after some time I was told by my senior that he noticed some real improvement, and I think that I have good chances of getting my contract renewed. But the fact is that now the development manager (who is also the product owner) has no idea of why I was underperforming (I felt like telling him the real reason was going to put me in further troubles), so he really thinks that I was underperforming because I don't have enough programming skills. As a result of this, I can see that often I don't get assigned hard tasks. My tasks are way too simple. So basically I underperformed because I didn't like my tasks, for being way too simple, and as a result I am getting assigned even easier tasks.

I do some grunt work from time to time. Sure, I'd like to have an intern to offload some of my more monotonous tasks to, but ultimately, the job still needs to get done. Right now there is a perception that you are unable to perform to the level they were expecting, so they are giving you tasks that they believe you would be able to handle. This sucks, but you need to demonstrate to them that you are able to handle the easy tasks before they trust you again with more complex tasks. For example, if you failed your algebra exam (even though you are a straight A student) I will not give you a calculus exam.

Now there is also a parallel problem going on: the company culture. The mentality is: "if we have to do the feature Y, we go to mister X [let's call him this way, He is not really a single developer, it may be one senior or another who is expert on the matter], who is the most expert on the matter [also because he learned how to work on Y on his extra time], and we tell him to do the feature". As a result, mister X's knowledge improves even more, but other developers' knowledge doesn't improve. I would say that the more you know, the bigger are your chances to learn; the lesser you know, the smaller are your chances to learn because they think "this task is too hard for you, let's give it to mister X". My colleagues don't seem to give too much importance to this issue, but my feeling is that the company really doesn't care about the personal growth of its developers.

The company cares, to those who have demonstrated capability and a proven rack record, you have not. I am sorry to be blunt, but a company has limited resources to spend on a given problem, leadership will naturally be drawn to personnel who have proved themselves in the past with successful performance. Given that you have underperformed, why would you expect them to look to you for advice and insight?

Now I really don't know how to break this vicious circle. It would be easy to say "change company", I am trying but now it's hard for me to find another company since I have few experience and most companies want already experienced developers. I would like to have some suggestions.

You sit down and buckle down. You got off to a bad start with your company. But that does not mean you change companies (although you can) just because of a bad start. Take a renewed focus on your "easy" tasks and accomplish them with maximum effort. Once you have a record of performing well on "easy" tasks ask that you are allowed to work on "medium" and then "hard". We all start somewhere in our careers. If it means that when we do grunt work initially, then so be it, you are paid to do that.

Answer 5

I see two non-exclusive solutions

Leave

You are in a small app company that has only easy tasks. If there would ever be an interesting and challenging task it would not be assigned to you because you have broken their trust by doing bad work.

Get certified

Because you have easy tasks you probably have a lot of mental energy left for studying so getting a certificate should not take that long. After you have a certificate you can use that as a reason to get those more challenging tasks. It also makes getting hired easier.