A co-worker of mine was let go and the consensus amongst the team was an unspoken understanding that although they have 4+ years of experience, they never leveled up past the Junior level.
Have you ever had a co-worker like this?
Is there anything management could've done differently, or are some engineers just hopeless? Is there something we as co-workers could've done differently?
I wouldn't like to add further details for privacy's sake, so I'm more hoping to hear about others' experiences rather than the circumstances here.
This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment.
Top comments (46)
From the different comments, it's clear that 'levelling up' means different things to different people. As I see it, it could be interpreted as any of the following
For the first, while some/many people may aspire to that, others don't feel they have the right character for it, feel it includes too many things they don't like (e.g. lots of meetings), feel it will reduce the time they can spend on things they really enjoy (e.g. coding), or may simply feel content in what they do now. All of those are entirely valid personal reasons for not doing this kind of 'leveling up'.
The second is what a great many people see as 'leveling up', i.e. expanding your skill set beyond what they know now. Often, it's a part of maturing beyond a 'junior' competency level. That said, people can also specialise in particular skills, without having the inclination to increase their amount of skills. Chastising people for that is like criticising a carpenter that makes fine furniture, because they don't regularly learn other types of woodwork, or given the scope IT skills, criticising them for not taking up pluming or masonry.
The third is a fairly sensible request, within reason: it makes sense for an employer to require of their employees that they educate themselves in the skills that are needed to do their job properly. That may include a junior learning 'on the job' or a senior getting acquainted with a new technology that the company wants to start using. There's however a world of difference between that company then making the arrangement for that employee to start learning via paid-for courses as part of their job versus that company requiring that that employee do the learning in their own spare time. The first is obviously reasonable, while the second is only seen as reasonable in some lines of work, while it's seen as ridiculous in others.
Finally, the forth one comes down to this: that a person is able to learn from their mistakes, and to take the advice of colleagues into account to progressively get better at what they do. Think code review: you don't expect having to give the same type of comments over and over again. This kind of leveling up is qualitatively different than the other three, and my view at least, the only kind that you absolutely can't do without.
So basically, it depends. Except when it doesn't.
Dude, just want to let you know that I've created an account here just to congratulate you for your comment.
I don't remember the last time I've seen something something so accurate taking so many different point of views.
Can't agree more with you.
Bravo!
This is very thoughtful and accurate. Really appreciate the coherence!
This is beautifully worded than my comment with same points.
Awesome!
We need to be very careful not to unconsciously create a tech culture which assumes every developer loves their profession and is thinking about how to "level up" 24/7. As others here have alluded to, sometimes you just need a train driver to show up and drive the train. How they spend the other 16 hours of their day is no one's concern but their own.
I appreciate your sentiment that maybe there was something you could've done to help your co-worker. But being empathetic also means understanding that your co-worker's life goals and issues may be completely different to your own.
It's entirely possible that they were happy where they were. Come in, write code, go home.
Leveling up would mean more paperwork, more meetings, more expectations, more thinking about the job at home... if the pay doesn't make that worth it, and the pay where they are funds what they do care about, it'd entirely valid to just keep maintaining rather than pushing to grow.
As you saw, that means they're more likely to be on the chopping block for layoffs, but a company can't have everyone fighting to get the lead positions and commanding more money.
There needs to be a healthy amount of people who you can depend on to just do work.
If that's what leveling up means for software developers, then you are doing it wrong.
I think the question was about getting more skilled, not getting a higher/different role. I've seen plenty of developers in my current company who did not grow past junior or mid-level. i.e. they could not take on more complicated work, or produce better quality work.
You don't want to keep juniors around, as they will take down the rest of your team. These people should probably also reevaluate their career choice. Programming isn't for everybody, it's really difficult stuff. However, it could also be that the developer can grow in a different environment, that this job simply isn't a good fit.
Note: I'm assuming here that the company has tried their best to get the junior to a higher level. You cannot expect them to do it all by themselves. Only a few are able to really do so.
As for mi-level developers who get stuck. Nothing wrong with these, as they generally form the large part of most teams. Just make sure the team also has more senior members, otherwise the quality of work this team produces will start to go down.
Not everybody has to be a super hero. It is just work. Some people are trying their best to put food on their table. May be there is nothing better they know. Neither does everyone needs to be a super genius like you. I don't know why lead dev, senior devs have so much ego. They have to remember they were there once. Some people learn at a slower pace than others and not everybody has to be the best of the trade. If a team is not interested why someone is struggling and how they can help them to make the member a better version of themselves, what is the point of being in that team? I have seen many devs getting promoted just for being good at corporate politics--just for kissing someone's *ss. This whole dev experience is getting toxic these days just for people with massive ego, thinking they are better than the rest. I believe that coding is for everybody-- provided that they have the passion and right attitude to learn. People have life outside of work-- family and friends and also their own 'me' time. For some people even to move their body from one place to another could be a struggle. Besides, he could also be going through mental issues/ other forms of suffering that he never told anyone about. I have never heard/seen anyone writing on why others are not trying to be the shop manager or willing to go the extra mile to be the top doctors in the country or why other participants are not winning the first price in the competition. Why do we see so many arrogant developers/personalities in the industry that they look down upon others?
I agree in the office politics and boot licking skills might be one of the reason as well. Which he/she might not want to do it.
From my experience, this was always the stopping factor and the reason behind moving from one to another company. Yet everywhere I go there is solid factor of egocentric sharks that just didn't like the colour of your socks on a Friday morning, or even worse you made them look like a fool in front of a whole team, putting their professionalism to a doubt.
These days the majority of developers take up this type of career for the money, provided you can just complete a quick coding bootcamp.
The worst part that bothers me is that many companies these days consider amount of years of experience you had as skills metrics, rather then what you can actually offer as a professional.
Hooray for mediocrity.
It is not your concern in all honesty. But I will say this, there is always an underlining reason. I would spend time understanding what is holding this lovely developer back when they have been at it for so long (or not so long depending in your perspective).
That would be me. There's a lot of reasons why I'm not "there", but if you ever did an interview with me, I explain why. 1. I never went to school for CS 2. I had to practice time management and hone in my ADHD 3. I just like coding and making stuff.
I should have added I had a different career and when I switched for the first 2 years I didn't believe I was good enough to make the cut as a dev and applied for non dev jobs I was overqualified for (Emails, support, blah) and took the first thing that came my way often times. I realized I wasn't going to "grow" into such roles unless I aimed and didn't give up on my own projects. Now I'm doing the type of work I want. Even if I'm mediocre or have "potential", I get to enjoy every challenge and task. And thats pretty good for me!
Junior developers, by nature, are in a phase where they take up a lot of the company's resources and don't produce a lot of value.
The expectation is that they will grow to a mid-level where they can work independently, do meaning-full code reviews, mentor juniors, etc. If they never level-up, they are not worth the early investment. If an engineer is at a mid-level and stops investing it is an entirely different story: they can be very productive while maintaining a nice work/life balance.
Then there's the nature of this business: new technologies appear -for better or for worse- at a breakneck speed. Companies and devs need to keep on top of these developments. If an engineer is not intrinsically motivated to keep up, it doesn't bode well for the value they can deliver in the future. Companies can work around this by providing training, but if people aren't motivated to learn, it's not going to work.
I have worked with one guy, really nice dude, but he was stuck at the same skill-level and technologies for 8 years. Unfortunately, after years of investing in him and sending him on courses, we had to let him go.
He's still a developer but in a less demanding setting, maybe it is for the best.
I think many companies view the world unrealistically.. And expect that they can add people like pieces of a puzzle and all will just magically fall into place.
I prefer to see a company as an evolving organization of evolving people. The people need to grow, build new capacities, and so does the company. I think successful companies are those that know how to nurture they're people's capacity as well as that of the organization.
Regarding junior programmers, I've often found more success with then than "senior" programmers. Maybe our expectation has been too high or we haven't yet learned how to do so, but we had trouble making senior developers "level up" in many cases, while the juniors were eager to do so. Our home grown senior developers (we have very low attrition) tend to be better than the ones we try to bring in. But that may be our own idiosyncrasy.
But definitely its important that people be able to evolve hand in hand with the organization (and the organization hand in hand with the people). That is key.
Finally a clear explanation on leveling up, thanks for sharing.
To be honest, I don't really like the terminology, as it implies some kind of gamification which work shouldn't really be in my opinion. But that's probably for another discussion. :)
But of course I know the phenomenon and I've seen it happen in many different ways.
I worked with people who were simply not cut out to be a developer. They hated every second of the job and were really difficult to work with. I always wondered why they were doing it in the first place.
Then there were those who reached the end of their abilities. Maybe not the absolute end, just a point where it took tremendous effort to learn more stuff. They were much easier to work with but you had to account for extra time to explain problems and be aware of their limits. The main problem here was when management weren't aware of this and lumped everyone in their charts as 1 developer-month.
The third category were the 9-to-5 developers. They came surprisingly often with maths PhDs and were undeniably clever but they had no motivation to do anything beyond the bare minimum. At first I found this irritating but once I got used to it, they were one of the best co-workers to have around: they were very reliable in their output and fun company.
And I'd add a tentative fourth subgroup too: those who at some point realised their calling was elsewhere. They'd go on to become middle management or project managers, architects or something even less technical. My experience in dealing with them post-transfer is that they were generally competent in their new jobs and their ability to switch perspective to see the dev team's view served them very well.
All in all, I think it's perfectly fine for people to approach their work however they want so long as they deliver what is expected of them. Whether it's financially worth it for a company is another matter but I'm not the guy making THOSE decisions.
I would however gently ask people in group 1 to try to find a more fulfilling job, for their own sake really.
A few years ago, I had been working in a company where I was working with a developer with 10+ years of experience. I never met that guy's face to face, but when I was doing a code review of his code, I often found things like that:
I tried to talk to him, but I did't find understanding between us, but he had been correcting all the remarks about his code, so I just had been checking his code more thoroughly than code of other team members.
Obviously I don't know about the specifics of the senior dev you're talking about, but sometimes junior and mid level developers can spend too much time sweating the unimportant stuff (when viewed from a senior developer perspective).
So for someone who is in the first few years of development (or someone who has OCD), coding is hard enough without also having to deal with brackets in weird places, inconsistent spacing and code like the sample you just posted. I get that, and I think it's something that senior devs should probably consider more.
The thing is, most senior devs will know that development wise that kind of stuff is never what kills a project, what kills a project is things like: sloppy architectures (or no architecture, or 3 architectures in the same app and no communication about which one should be followed), or a lack of tests (or too many pointless tests), or a team that hates each other, or team members competing over who is the smartest, or too much team churn so that the vision or expertise gets lost. All those things usually cause a build up of bugs which in turn slows the pace of new development to a crawl. Eventually the person who is paying for the project decides to re-write the whole thing from scratch or scrap the project entirely.
It is possible that the 10+ year developer you have encountered just doesn't care about the small stuff because they understand that the higher level code structure and its testability is much more important. When you provide endless nitpick code reviews, rather than argue and tell you it's barely worth the 5 seconds it would take to fix it - they just fix it, because they are also aware that arguments about pointless things among team members are a genuine serious risk to the success of a project.
Again - I'm only speaking generally, possibly your 10 year dev would just rather be on their boat or on a beach somewhere ;)
Although probably a violation of the YAGNI principle, this is an entirely valid way to structure this code with an eye for future maintenance. Perhaps the dev who wrote this has done the refactor from
return isSomethingTrue();to this structure so many times -- to add logic to one or both branches -- that they now default to the latter. And they expect that in the average case it will save time.I don't do this thing in particular, but I will sometimes opt to do longer-form ways of structuring things when they are more amenable to maintenance in the future.
Oh man, this is everywhere.
Shit regular happened, but fortunately, there are companies where code quality is still very important.
Of course the code quality can be sacrificed for the sake of performance, but I had to do it only once in my life when I had to optimize the algorithm from 120 processor clock signal to 10.
At my first job I felt the same for almost one year.
I was a junior developer, passed interview and got to work on a massive embedded Linux C project, over 2 million lines of code. The project was also in maintenance, with very few features being added.
My first 3 months were spend writing unit-tests, but management didn't care about the tests or if they were written correctly or not, code reviewers (which were more seasoned developers) didn't care either, all they wanted was to raise the code coverage so they could have a nice tests report, the higher the better...
After finishing with the unit tests I got some dev tasks, extremely boring and unsatisfying. Half of the time I'd triage tickets to send them to another team to fix, and the other half I'd look at a file of 800MB of logs, with very little time spend doing coding. Imagine that you've never saw the code that handles Bluetooth and you get a task complaining that some random phone brand from china can't connect to the device via Bluetooth, all you had was your code and a huge log file.
This has been going for about one year.
Luckily, I got moved in a different team and this is where I got my first promotion from Intern to Software Developer 1. I've began to work closely with a brilliant senior developer. The component on which we've worked did well and got signed off, although the project didn't and in the end It failed.
I left the company about 5 months before the project was announced a failure and right before I left I got promoted to Software Developer 2 for some reason.
Now, I still have friends working at that company, they aren't very passionate about coding and they spend most of the time doing "unit tests" to raise the code coverage. From my perspective I don't think they will evolve if they just come to work, do the tasks and go home. You have to do something extra to improve your skills if your job doesn't challenge you, or else you fall behind.
I think the best thing management can do is to pair a senior developer with a junior developer.
While reading this and the comments, I was asking myself this question:
How do we judge objectively the skills of a developer?
It's not that easy. I saw many talented people judged very hardly by others because they were less extrovert, for example, or because people around them loved to control everything. Worst, some people who think differently can be rejected, even if, I believe, it's a major quality to increase the collective intelligence of a team. That's why diversity is so important.
Now, I saw developers who didn't really care of what they were doing, too. They were introducing a lot of complexity in their codebase, often for nothing. They weren't really motivated to learn anything either. It was just a job, and putting some efforts in it was too... demanding.
For CRUD applications, I think that's fine. Somebody is not good in general (or I need to meet him!), but in a specific context. Everybody has quality which can be developed in strong skills, and you need to find them. Then, you need to decide if this potential will help your company, or if you want to invest time to grow it.
In short, if there is a problem with somebody, one should speak about it with this somebody. Good communication to find the root of the problem is always my tool of choice.