Have you ever worked with an engineer who never leveled up?

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

1. Evolving into any kind of leadership role
2. Learning new skills that have nothing to do with your day-to-day work
3. Learning new skills that directly relate to your day-to-day work
4. Becoming more proficient in your day-to-day work (i.e. working more efficiently and/or creating higher-quality work)

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.

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.

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:

if (isSomethingTrue()) {
    return true;
}
else {
    return false;
}

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.

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.

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.

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.

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.

"Leveling up" is not always good.

Be wary of The Peter Principe when making promotion as a developer.

I've met enough school examples in my life which were good developers, but were the worst persons for the job as scrum master or dev team leader. Mostly because they lacked soft skills.

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.

It's a violation of the "KISS" principle. A code should be short and simple. A 1 string of a code is better than 6 strings of a code.

return isSomethingTrue();

Let's not turn what's fundamentally an economic issue into a moral issue.

There are always companies that need junior developers. If your company has decided it needs senior ones, that's no reflection on the junior dev's qualities. There are other companies looking for someone with his skillset, and not willing or able to pay more experienced devs.

Furthermore, for all we know, a person like him could be a genius at what he does in his spare time. After all, Einstein did much off his early groundbreaking work while employed in a patent office doing what he himself acknowledged as grossly undemanding. That's why he took the position, for heaven's sake.

And such a person doesn't need to be a genius anyway to make their choice defensible. Think of the sacrifices required to "level up". Perhaps he doesn't do so because he considers spending that time enjoying the pleasure of watching his kids grow more valuable. Can you begrudge anyone that?

There are many paths to a good life. Those known to each of us are but a fraction of the vast possibilities available.

After losing a relationship that meant the world to me because I was overworking, I have been forced to reconsider my career priorities. Did anyone at work give a shit I spent all that time on the project trying to make it succeed? Not really. Did my girlfriend notice where my hyperfocus was directed? Definitely.

Most careers don't seem to have this problem. I can't imagine accountants looking down at a coworker for not making spreadsheets in their spare time, but for some reason we're expected to dedicate all our time to pursuits which may or may not pay off and everyone acts like they always love the work they have been assigned. Then we wonder why we see such a massive burnout rate and some people walk away thinking the solution to burnout is to code even more.

Completely depends what you mean by 'levelling up' - can you elaborate?