Bsrgvty

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.

So you say that the tasks were too remedial, basic and simple to be worthy of your best effort, but you couldn't perform those tasks without breaking the apps? — Sep 19 at 17:55
I know it sounds like a paradox and it's hard to believe, but yes. And most of them were not even programming tasks. Let's imagine that you have to update the current version of a library (written by someone else) that is used in your project, and you don't even write one line of code for that. You just run a command and after that you have to verify that the app works for many cases (e.g. paid version, free version, plus many variants). A task like this one looked like a coding monkey task and this is why I skipped many verification steps and made "broken" pull requests. — Sep 19 at 20:02
@BohBoh Do you have an example of a task you wouldn't consider "coding monkey" ? I ask this because essentially breaking things in simple assignments is what a working, functional management is about. In the end, there is always a fair deal of testing. If you have too much to test per task and you don't like testing (and I can't blame you for that) you could suggest to automate some part of it, this could be of great added value for your company. — Sep 19 at 20:14
Let's summarize it like that: normally you have a set of boring things to do, and some interesting things. E.g. (1) cloning the repository, installing the libraries and making sure that everything works, (2) investigating the problem (if applicable), (3) solve it by coding, and (4) a lot of testing for multiple versions of the app and scenarios. Now imagine that the whole coding investigation + coding task (points 2 and 3) consists in spending only five minutes to figure out the problem and write one or two lines of code. This is what I consider a coding monkey task, or even a tester task. — Sep 19 at 20:17

score 32 · Accepted Answer · 2019-09-19 18:03:41Z

"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.

For me personally, the most important factor for being most productive is my motivation which in turn is based on my satisfaction with the tasks assigned to me. I really do not see myself as a "very poor employee" though. Please keep in mind that other people can have different priorities than yourself. — Sep 20 at 8:38
@NotTelling you certainly can have different priorities, but the reality is that we all have to deal to a certain degree with stuff we do not particularly like. That's what separates work from a hobby (and even there this might happen). A good employee also does the stuff that he/she dislikes properly and doesn't shortcut it - or find's ways to automate them away. It's obviously about balance, i.e. a good job will make sure you can also work on stuff that you are happy to work on. But you cannot expect to get more complex, risky tasks if you fail at simple ones. — Sep 20 at 13:14
@NotTelling - This isn't about priorities, and of course, everyone should choose employment which matches their priorities. The OP accepted a job, had continued to be employed there, and then, because they didn't "like" their tasks, started doing a poor job. That is a "very poor employee" to me, where a "very poor employee" is defined as someone likely to be fired for performance. — Sep 20 at 13:25
As the old Pareto principle goes, 80% of the bugs come from 20% of the code, and so on... your job will not be innovation and excitement 100% of the time, most likely it will be 20% of the time. The other 80% is the small "unimportant" things that need to be done to keep a business running. For those of us that thrive on change and improvement, finding better ways to do the same stuff not only help you stave off the boredom but also help others to do their job better. — Sep 20 at 13:27
@FrankHopkins I didn't say that you shouldn't do your tasks properly and without shortcuts if you don't like the task. I just stated that I (and I think this is something all humans share) work more productive if the work I get assigned is to my satisfaction. — Sep 20 at 13:35

sgf 1034 bronze badges · Accepted Answer · 2019-09-20 09:09:52Z

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.

I wouldn't call it "admission", I'm not under trial here. I am just being open and telling the truth. Anyways, what is important for my small company would probably be considered secondary, or even irrelevant in a bigger company with more "big tasks" to do, this is what I mean. — Sep 19 at 20:58
@BohBoh You could be surprised to how insignificant things can become when being ordered from several hierarchical levels above. Anyway, I think my views about the issue changed a bit after reading your comments, if you want we can discuss it on chat. — Sep 19 at 21:01

HelenaHelena 2,4702 silver badges19 bronze badges · Accepted Answer · 2019-09-19 18:53:07Z

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?

Work on your motivation issues and take every task serious. Show that you are reliable.

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 ...

I'm in a similar situation to OP's and I think his best option right now is just to leave. What he said about the vicious circle ("give person X this task because he's the best at it") is a sign of terrible management: this company is clearly understaffed and only aggravating their problem by overloading their best talents, while treating others as "permanent interns". — Sep 19 at 19:02
@hjf I didn't see anything in the OPs question, that hints that person X is overloaded. There is nothing wrong in giving the most impactful tasks to the most skilled developer. — Sep 19 at 19:17
@hjf I doubt you describe a real situation. I know no software that has an eternally simple task backlog that wouldn't eventually give you expertise of the software. So either the company is really bad and hires developers to do absolutely nothing, either Mr.X area of expertise doesn't grow relatively to others as you think it would. — Sep 19 at 19:41
@ArthurHavlicek I'm the only one in my company who deals with the AI part. I plan on leaving as soon as I can. The best I can do is document everything for th poor soul that has to deal with all of this alone. It took me 3 months to get up to speed when I was assigned this, after the original developer left. This is what I mean by "terrible management". — Sep 19 at 19:44
@hjf This doesn't mean they weren't growth opportunity for the devs that didn't touch AI. This is one thing to consider company loss of over-specialized developers, it's another to consider this specialization is a lack of learning opportunity for juniors — Sep 19 at 19:49

Frank FYCFrank FYC 6,9522 gold badges20 silver badges41 bronze badges · Accepted Answer · 2019-09-19 17:59:36Z

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.

From their perspective I can understand that they don't want to give me harder tasks because they think that I lack skills (while in truth I really lack motivation). But anyways, this is really a company culture, or at least the managers' culture: even with other developers, they tend to have this mentality for which if you don't know how to do something then you don't get the task assigned and viceversa. Maybe it makes sense to do so for who underperforms, but they do it for everyone. So it's really a vicious circle. — Sep 19 at 20:43
@BohBoh If you are not motivated to do a task, you still have to do it, it's part of being a professional. If you make mistakes because of the lack of motivation, they're still your own mistakes. Yes, you do lack skills, they're just not technical skills. And yes, I know what I'm talking about because I've been down that same path myself and it took me a while to realize I was the one to blame. — Sep 20 at 8:27
People can be sick or on vacation, Experts can have some high priority tasks that prevent them from fixing a smaller bug. This can give you an opportunity step in and prove you're up to those tasks. Until then, proving your worth should be your motivation - right now, you need to prove you can deliver without causing any headaches. — Sep 20 at 8:31

user3644640user3644640 1,2134 silver badges10 bronze badges · Accepted Answer · 2019-09-19 18:06:25Z

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.

Well, it's not really about energy but about time.

– Boh Boh
Sep 19 at 21:27 — Sep 19 at 21:27

score 32 · Accepted Answer · 2019-09-19 18:03:41Z

"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.

For me personally, the most important factor for being most productive is my motivation which in turn is based on my satisfaction with the tasks assigned to me. I really do not see myself as a "very poor employee" though. Please keep in mind that other people can have different priorities than yourself. — Sep 20 at 8:38
@NotTelling you certainly can have different priorities, but the reality is that we all have to deal to a certain degree with stuff we do not particularly like. That's what separates work from a hobby (and even there this might happen). A good employee also does the stuff that he/she dislikes properly and doesn't shortcut it - or find's ways to automate them away. It's obviously about balance, i.e. a good job will make sure you can also work on stuff that you are happy to work on. But you cannot expect to get more complex, risky tasks if you fail at simple ones. — Sep 20 at 13:14
@NotTelling - This isn't about priorities, and of course, everyone should choose employment which matches their priorities. The OP accepted a job, had continued to be employed there, and then, because they didn't "like" their tasks, started doing a poor job. That is a "very poor employee" to me, where a "very poor employee" is defined as someone likely to be fired for performance. — Sep 20 at 13:25
As the old Pareto principle goes, 80% of the bugs come from 20% of the code, and so on... your job will not be innovation and excitement 100% of the time, most likely it will be 20% of the time. The other 80% is the small "unimportant" things that need to be done to keep a business running. For those of us that thrive on change and improvement, finding better ways to do the same stuff not only help you stave off the boredom but also help others to do their job better. — Sep 20 at 13:27
@FrankHopkins I didn't say that you shouldn't do your tasks properly and without shortcuts if you don't like the task. I just stated that I (and I think this is something all humans share) work more productive if the work I get assigned is to my satisfaction. — Sep 20 at 13:35

sgf 1034 bronze badges · Accepted Answer · 2019-09-20 09:09:52Z

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.

I wouldn't call it "admission", I'm not under trial here. I am just being open and telling the truth. Anyways, what is important for my small company would probably be considered secondary, or even irrelevant in a bigger company with more "big tasks" to do, this is what I mean. — Sep 19 at 20:58
@BohBoh You could be surprised to how insignificant things can become when being ordered from several hierarchical levels above. Anyway, I think my views about the issue changed a bit after reading your comments, if you want we can discuss it on chat. — Sep 19 at 21:01

HelenaHelena 2,4702 silver badges19 bronze badges · Accepted Answer · 2019-09-19 18:53:07Z

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?

Work on your motivation issues and take every task serious. Show that you are reliable.

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 ...

I'm in a similar situation to OP's and I think his best option right now is just to leave. What he said about the vicious circle ("give person X this task because he's the best at it") is a sign of terrible management: this company is clearly understaffed and only aggravating their problem by overloading their best talents, while treating others as "permanent interns". — Sep 19 at 19:02
@hjf I didn't see anything in the OPs question, that hints that person X is overloaded. There is nothing wrong in giving the most impactful tasks to the most skilled developer. — Sep 19 at 19:17
@hjf I doubt you describe a real situation. I know no software that has an eternally simple task backlog that wouldn't eventually give you expertise of the software. So either the company is really bad and hires developers to do absolutely nothing, either Mr.X area of expertise doesn't grow relatively to others as you think it would. — Sep 19 at 19:41
@ArthurHavlicek I'm the only one in my company who deals with the AI part. I plan on leaving as soon as I can. The best I can do is document everything for th poor soul that has to deal with all of this alone. It took me 3 months to get up to speed when I was assigned this, after the original developer left. This is what I mean by "terrible management". — Sep 19 at 19:44
@hjf This doesn't mean they weren't growth opportunity for the devs that didn't touch AI. This is one thing to consider company loss of over-specialized developers, it's another to consider this specialization is a lack of learning opportunity for juniors — Sep 19 at 19:49

Frank FYCFrank FYC 6,9522 gold badges20 silver badges41 bronze badges · Accepted Answer · 2019-09-19 17:59:36Z

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.

From their perspective I can understand that they don't want to give me harder tasks because they think that I lack skills (while in truth I really lack motivation). But anyways, this is really a company culture, or at least the managers' culture: even with other developers, they tend to have this mentality for which if you don't know how to do something then you don't get the task assigned and viceversa. Maybe it makes sense to do so for who underperforms, but they do it for everyone. So it's really a vicious circle. — Sep 19 at 20:43
@BohBoh If you are not motivated to do a task, you still have to do it, it's part of being a professional. If you make mistakes because of the lack of motivation, they're still your own mistakes. Yes, you do lack skills, they're just not technical skills. And yes, I know what I'm talking about because I've been down that same path myself and it took me a while to realize I was the one to blame. — Sep 20 at 8:27
People can be sick or on vacation, Experts can have some high priority tasks that prevent them from fixing a smaller bug. This can give you an opportunity step in and prove you're up to those tasks. Until then, proving your worth should be your motivation - right now, you need to prove you can deliver without causing any headaches. — Sep 20 at 8:31

user3644640user3644640 1,2134 silver badges10 bronze badges · Accepted Answer · 2019-09-19 18:06:25Z

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.

Well, it's not really about energy but about time.

– Boh Boh
Sep 19 at 21:27 — Sep 19 at 21:27

搜尋此網誌

Bsrgvty

How to break this vicious circle?How to maximize your learningJunior Developer doing well but management wants to fire himCandidate talks over me during interviewHow to handle no-work situations?Helping your manager track your progress as correct as possible?Feeling overwhelmed at work

5 Answers
5

Update:

Your Answer

Post as a guest

5 Answers
5

5 Answers
5

Update:

Update:

Update:

Update:

Post as a guest

Popular posts from this blog

Tamil (spriik) Luke uk diar | Nawigatjuun

How to break this vicious circle?How to maximize your learningJunior Developer doing well but management wants to fire himCandidate talks over me during interviewHow to handle no-work situations?Helping your manager track your progress as correct as possible?Feeling overwhelmed at work

5 Answers 5

Update:

Your Answer

Sign up or log in

Post as a guest

Post as a guest

5 Answers 5

5 Answers 5

Update:

Update:

Update:

Update:

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Popular posts from this blog

Tamil (spriik) Luke uk diar | Nawigatjuun

5 Answers
5

5 Answers
5

5 Answers
5