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.
Oldest comments (46)
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).
I got to agree with Adam on this. There might be a lot of reasons for the developer to not "levelup" in the company's eyes. The only thing you could have done differently.
It might be just opening doors for the person through your network. If you think that he/she is a awesome developer and you have full confidence to refer the person to your developer network. Due to their work ethic or value, they bring through their work.
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.
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!
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.
Completely depends what you mean by 'levelling up' - can you elaborate?
Agreed. Reading the responses, it seems like this is being interpreted a lot of ways.
A developer that doesn't level up, for me personally, mean he's not passionate about his job and maybe the best course of action for him is to leave and maybe change profession.
I myself always learn at home, try to be better, and I know there's always room for improvement, not because of the money, but because it really interest me (not always of course, but most of the time)
I think that having a "turned off" dev in the team also have a negative impact on the spirit of the team, so it might be better to either move him to a one-man team for simple tasks, or just talk to him and understand why he's like this, maybe there's something blocking him from growing (either professional or personal issues)
My personal feeling is that talking is always the best course of action and can reveal most of the solvable problems without bad blood.
Why would you say that man, that's pretty cold-blooded imo (granted, this is the internet where things are easily misinterpreted. So I apologise if this is one of those cases).
All of us posting on dev probably love what we do—I just don't think it's right to assume that our experiences must hold true for every other developer or else there's something wrong with them.
Maybe someone doesn't love being a developer, but it's the only way to put food on the table. Or maybe they do want to learn more, but they're too exhausted from raising a family. Or maybe they suffer from mental illness etc. etc. etc.
For instance, I used to study dentistry. You soon realise that 80% of dentists don't particularly enjoy what they do, they just chose it for the financial security. This also doesn't mean they are incompetent; they just don't go learning more about teeth in their free time.
We must acknowledge how lucky and privileged we are to love our jobs, and understand that this is not the norm for most people. In turn, we can avoid imposing our ideals on others—just how we wouldn't want theirs imposed on our lives.
Hey, sorry for sounding (reading?) arrogant or cocky - it's far from the truth.
I just meant that maybe he's not willing to put in the extra effort because he doesn't like what he does. I personally saw a lot of devs that quit the development world to become something else because they didn't like it too much.
If he enjoys development and likes it where he's at now, good for him! And happy to hear that you chose something else that you love because you didn't enjoy what you first chose. It takes a lot of courage to switch careers after you've started pursuing one.
All good I hope :)
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.
Finally a clear explanation on leveling up, thanks for sharing.
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.
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.
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.
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.
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.