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, the...
For further actions, you may consider blocking this person and/or reporting abuse
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.
"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.
that's changing roles, not "leveling up"
I have to disagree with you.
The job of senior developer comes with additional leading/coaching tasks compared with the job of junior and medior developer.
I don't disagree with that. I'm just saying what constitutes changing skill levels. I'm talking about professional development.
You're talking about job roles.
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.
I would love to be told this at work. At some point he'll learn!
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.
Your point about other careers.. Wow. I have never thought about it. Really opened a whole new perspective for me. Thank you!
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.
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.
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 :)
Yes plenty, and it goes to show that years of experience is a terrible indicator of skill, expertise or passion. But I think it has to do with their perspective and possibly the developer culture at the company. Some people are just doing it for a paycheck without any passion behind it which means minimal effort and stagnation, and a friendly culture that promotes learning and doing your best goes a long way to reinforce that self improvement mindset that we like seeing.
is not breaking under pressure also one of those reasons people might be not given contract renewal... I smell churn.
However, I came to read this post because it seems to apply to me too! I have not really levelled up.
Imprecise terms in the problem description.
1 Consensus
Didn't let you pollute the environment with yet another JS framework? Uses the wrong shell scripting language? Sounds like an office politics problem, not a technical issue.
2 Leveled up
People don't "level up" in roles, unless they are happy with employer exploitation. You get promotions and raises. You get what you pay for. Leveling up is doing 80 hours of work and getting paid for 40 of them.
That's not what I understand as "leveling up". What I understand is:
Other aspects also include the ability to estimate code and actually meet your estimates, organize your time well, ask the right questions before jumping into coding, etc..
The problem is when someone starts in #1 and can never make it to #2. Or gets to a certain level in this list and years later is still stuck in the same level. If you're going to work for me for 5-10 years, and you get at least annual raises, the expectation is that over time you're contribution will be more. If your contribution level stalls, then you're stagnant and we may consider either freezing or limiting your raises or even firing you.
Your reference about "employer exploitation" doesn't seem fair. Most place I've worked in, if you do your job, you get some nice raises, you get stock options, you get profit sharing or other benefits. If you've never seen that then you either: live in the wrong place, work for the wrong sorts of companies, or are limited by your own attitude. After college I was quickly making a lot more than my non-tech peers. I never felt exploited. Rather I felt guilty that a lot more hard working folks with a lot more experience (like teachers with over a decade experience ) where making about the third of the salary I was making.
Everybody is arguing about the semantics of the question, but I think it is fairly obvious what is being asked.
Personally, no I do not believe I have worked with a "first year of experience repeated X times" developer. I have certainly worked with developers whose coding practices I disagreed with. For example, our team once got a coding contribution from another team, and the employee had a more senior job title than mine. It was using all static classes and Hungarian notation. I was completely floored and didn't want it in my code base. Later on I discovered Joel Spolsky's blog and read Making Wrong Code Look Wrong. And then I also started to think about this employee's situation, the team they were in, the kinds of tasks they routinely did, their history. And their strategy made sense in context. And their code was sound, just not organized according to the best practice of the day. Sure, it was going to take some work to adapt to our code base, but my initial assessment of the developer was misguided. And maybe I also felt some competition because their title was above mine. Before I realized all that, I ended up wasting political capital with management attempting unsuccessfully to avoid integrating their code. And that pointless exercise could have been avoided by not presuming myself to be an impartial judge of code quality.
Some people simply don't care to level up while some others can't. If you're experienced and are bothered by this behavior maybe stop thinking that everyone understands how problem solving or programming works, and maybe they're already trying their best.
Yes. From my previous company,they from company started until now. When telling the Management, move the data to the cloud , they just entertain the management ,just mention in Planning.
Current company, still got little co-worker does not upgrade their skills from time to time.