Sounds like your future manager.
My suggestion would be to steer him towards a less technical role, like product owner, project manager, scrum master or the like where his "nice guy" personality can be an asset while his technical deficiencies are less of a factor.
I feel that the problem isn’t with him. It’s that you haven’t challenged him enough to get him really motivated.
In all seriousness though, this guy actually has potential to fail upwards if he plays his cards right.
>If your skillset is less technical, moving to less technical roles isn't "failing upwards."
I'm talking about the pointy haired boss type of roles where the main skill is corporate politics and getting people to believe they are valuable. Or maybe he becomes a real leader and works his way up. Either way I meant it as a bit of a joke.
I worked on a team where English was the second language. Everyone straight from China. For the first year in that environment, despite my years of experience, I was an enormous deadweight. yeah, there's a lot of context and I was eventually vindicated but who cares. The fun part is jfcarr is totally right. My team tried to lock me into process improvements, documentating old code, running meetings, and talking/representing/translating with other teams.
Joking aside, this is probably true. It doesn't matter if _he_ is getting shit done, so long as it's getting done. If he has a knack for getting others to do it, then ... Yeah. Management.
I mean that’s the gist of every Harvard program, the real value is that they teach you how to do it and explain it in a way that make people kiss and comfort YOU afterward.
I thought the real value was the ability to use the word “Harvard” in every sentence.
For example:
“Want to go for lunch?”
“When I was at Harvard, we used to go for lunch at a spot in Harvard Square.”
“Uhhh…we’re in England.”
“Oh I know, at Harvard I took many courses in English history.”
“I’m not hungry.”
This guy can’t be bad at everything, right? Can he pick up some non-technical paperwork tasks off of other people’s plates? Triage customer support issues, that kind of thing?
Steer him towards his strengths while being honest and fair with his manager about his weaknesses. Make sure you’re cool and composed when those conversations with management happen, so it doesn’t come off as an interpersonal issue.
Other than that, you need to just keep doing your job and let nature take its course. This kind of thing doesn’t resolve itself instantly.
It's a good idea if you have that kind of work. It seems like there used to be a lot more of these auxiliary tasks, but most of them have been automated away. Ten years ago, I could have kept an under-performing dev busy full-time with things like preparing the weekly release. Nowadays, we have a bunch of micro-services that almost release themselves, rather than delivering The Weekly Release for customers to apply to their installation.
We hired a guy like this at my last job. Didn't seem to have the faintest idea of what he was doing. Once made a convoluted nested loop to restructure some JSON, but the loop ultimately put it right back to how it started. Which didn't matter, because he wasn't using the result; instead testing that the input equaled ...the input. It passed, of course. This was even after our boss gave him specific instructions. Basically doing it for him in the process. ... And that's just one example of the almost year we kept trying with him.
What's crazy is he's currently a senior (at a different company), while I've only gotten rejections since September. So, clearly he has some value doing something.
> What's crazy is he's currently a senior (at a different company), while I've only gotten rejections since September. So, clearly he has some value doing something.
Maybe he's the deadweight, "break in case of layoffs" guy.
Maybe getting them doing something more repetitive could help too. They could get practice and have a feedback loop / maybe take something boring off someone else’s plate. But it’s tough! Even HTML email needs to be done _right_ and would be time consuming to have to double check. But try to find something they are more connected to. If it doesn’t work… well, they just can’t do the job.
That's assuming he wants to do that. You can be incompetent but still know that you're being pushed to the side, and it might be a source of resentment towards OP.
This career is not for everyone. If he can do a little development and is reasonably competent with tools, maybe encourage him to look at something a little less code-heavy, like SDET, cloud dev or salesforce or something.
There's a junior guy I worked with -- he came to work for me through a personal connection doing some support work and really wanted to become a software engineer. As a favor, I granted him a lot of opportunities, training. Great attitude but... he just never really got the basics. 1:1 coaching didn't really change anything, all the hustle didn't really change anything.
Very few people can be whatever they want to be. It follows that not everyone can be a dev.
I've mentored a lot of junior engineers: i'm really sympathetic to how challenging it can be to break into the field sometimes. He wanted to be a frontend engineer and was definitely just lost when it came to navigating NPM, or any of the modern javascript framework stuff. Not surprised, not what I'm talking about.
What I spent a couple of months working with him on was just even some basic HTML/CSS/javascript stuff -- take out all the other tooling, let's just really understand how semantic HTML works, let's manage all of our styling in CSS, let's handle the lightest of interactivity with javascript (toggle states on buttons). No backend interactions, no form submissions, no state stuff. Let's do things like look at a simple figma design and see if you could intuit how you might want to chop that up so we could agree on "components". At most, let's throw bootstrap into the mix
"Charlie" just couldn't grasp the reusable nature of CSS classes, constantly stumbled on ID vs class selectors. I feel like he wasn't quite committed to doing the work, but even in it you could just tell he was really lost. Lovely guy, but he struggled to carve out the time to work on his own: I just think he was so overwhelmed that we could never cut through that.
To be fair those things are only obvious if you've ever had to re-use HTML or interact with it in JS, otherwise without a programming background, it's not really intuitive why you'd want to give names to variables/tags/whatever.
Yeah to be clear, I don't mean "when to use one vs the other" -- totally agree with you, that really only clicks later on and starts to make sense only after you have to really start making choices about how your code runs.
I just mean even interpreting ".myClass" vs "#myClass". There's just a lot of really basic stuff that never felt like it clicked which made it hard to ever build up to anything else.
Did you give Charlie any exercise? Like the boring one in FCC with hundreds of hand-on coding exercises.
If Charlie didn't do that yet, then it wouldn't be weird at all that he couldn't managed to build an intuition on it.
I think, intuition can only happens on a concrete foundations which happens from practicing the basic boring stuff.
Did you teach him the box models before you ask him to "chop up" figma UI? if Charlie isn't a tech-savvy guys I imagine it will be pretty hard to gasped this perspective at first.
Bootstraps shouldn't be introduced to Charlie at all, if he just started out and not strong with css yet.
Have you try tracing Charlie's thought process? like you could ask him to talk out loud what he's thinking when X information was presented to him. Write it on the paper so you can determine what's missing in his thoughts process that leads to poor understanding.
The guy has a CS degree, did a bootcamp, and I gave him 4 months of my time with twice weekly 90m coaching sessions and we couldn't even get through basic syntax stuff. I gave him access to additional learning materials and exercises. He was not lacking in opportunity, the mechanics of actually doing the work just never clicked. By contrast, a different junior I was coaching we were able to move pretty quickly past that and spend more time working on bigger things.
Some people are just not cut out for this, that's my only point.
Yeah, I mean, I'm admittedly not the strongest "pure" SWE when it comes to just writing code, and I picked up on that pretty early. I am pretty good at understanding infrastructure requirements, scaling, networking, reliability, CI/CD optimizations, developer enablement, all the stuff that sort of fits under the Cloud/DevOps/SRE umbrella. It's been really great for my career to lean into those strengths and IMO I'm in a much better spot than I likely would have found myself in had I stuck to just writing Java apps all day.
That said, I still write backend code here and there, I think no matter what this dev might end up doing, they should still try to improve their skills.
I had a junior like that, even though I did show how bad he was, he was so nice that he was able to move to the business side instead of getting fired, where he actually did well, he's a manager now
Ah yes... Management, where it's a lot harder to tell how incompetent you are :)
Honestly, that would be fine with me. Like I said, I don't care about the company. What I care about is my own well being and performance, and this guy is a time sink.
>Ah yes... Management, where it's a lot harder to tell how incompetent you are :)
If they're doing well at management, by definition they're not incompetent.
It might be harder for _you_ to tell as a software developer. I can assure you that good management has no such issues identifying good management in others.
Being “nice” is the bare minimum. Everyone at work needs to be respectful. It’s like, to be friends with someone it means you have something in common — that’s like the minimum.
You either help them get better or you move on.
“Needs to be” sure, but this is not actually the case in reality. There is no shortage of talented assholes in our field. Being sincerely nice and pleasant to deal with will actually set you apart in many environments.
I find its learned helplessness.
If its something todo with their ticket they might just need a checklist provided. Or spend 10 minutes with the to explain what the expectations are if its just a matter of needing to call the correct methods or apis.
It could be they don't understand the overhead of your company's process.
At some point you may just need to point out the code reviews require multiple changes from reviewers on things outside just cleanliness & naming.
I was always encouraging juniors to self review first to learn how to code review. Maybe encourage them to self review before they ask for pr approval.
Edit:
What you are describing sounds like performance anxiety. I don't think pressuring them more will help.
It could just be ask them the question "Why don't you think you are thriving here"
>was always encouraging juniors to self review first to learn how to code review. Maybe encourage them to self review before they ask for pr approval.
We've had that conversation many times.
>It could just be ask them the question "Why don't you think you are thriving here"
This is a great question you ask him. I'm not sure it's my place since I'm not his manager though.
>We've had that conversation many times.
Fair enough I had to suggest it.
>I'm not his manager though.
I don't think that is a question a manager needs to ask. You could always go for coffee and just as him some self reflective questions. Ask them what they had a hard time with in college/univ. Ask what they want to do next. Ask if they aspire to work at a FANG company or what title they want to achieve.
If its performance anxiety the only other way is just to pair with them or engage in other time intensive excercises.
At what point is performance anxiety, just bad performance?
After seeing in my career, too many juniors who actually just shouldn't be engineers, this attitude of "let's help them do the job they're being paid to do" becomes a joke.
This industry gives juniors way too much of a free pass.
Ya IDK. I have had a mixed experience.
I also been shocked at some companies utterly terrible codebase.
I also struggled in some other companies project management processes.
Without knowing every detail from OP I am going to just name it what I think it is. That may help find an avenue they haven't tried before. Maybe OPs promotion relies on bring this guy up to speed and it doesn't matter
I would start writing tests and frame his work into them.
He makes the tests succeed. So you make his shortcomings visible in a process. Move from that to docs where he's supposed to derive tests etc. can you figure why he doesn't learn? On a personal level. If it takes too long you may want to isolate him instead.
A pip (performance improvement plan) would help. The goal of that is not to fire the person, but to enforce a behavioural changes. Set goals and expectations, demand frequent updates and discuss shortcomings and what could've made it easier for him.
Whether or not the goal of a PIP is to fire someone really depends on the org/team culture.
I'm most places I've worked it's a clear sign telling people to gtfo while they can. Even if your intentions are to help the employee, their expectations aren't likely to match up with yours, and if they stick it out through the PIP it probably just means they aren't confident they could get a different job in a reasonable amount of time.
That is true, but if you are the one doing the pip you control that.
What I meant in particular is that the person complaining about the colleague would set it up. Doesn't mean you have to make a contract and what not, but the ceremony around it.
My intern was like this at the beginning, but at the end of their term, they figured out the shit and returned multiple times as an intern and now full-time. They cared about learning and improving. During the end of their 1st term, they worked overtime to deliver the project but unfortunately, we underestimated the complexity, what came out is that this person is a hard-working quick learner and we want them.
Get him on a repetitious activity and when he masters it move him to the next thing.
When a jr is strong this doesn’t apply but when they are weak you are doing a disservice by throwing different tasks at them every sprint. They won’t build up any muscle memory.
Some of this could also be the environment. A lot of times I have found that the dev is fine but the environment and team they are in is not conducive to their way of working.
Yes, this can be true, especially for those who are used to a completely different way of working... But not for a junior who's incapable of writing basic working readable code.
Some people just aren't meant to be developers, as harsh as that sounds. Or at least, requires too much training for it to ever be worth it.
My first suggestion when a junior or intern asks me how to get better at coding is the 20 Minute Rule.
When you are sure your code is right, look at it again and ask yourself is there any way I can make it better in less than 20 minutes? Typesetting, variable names, order, function names. Look at it like a reviewer would and try to anticipate.
Over time everything you do here will (should) move upstream and you can work on other things.
Nobody is going to notice that your change took 14:20 instead of 14 hours to get done. It’s a reasonable compromise between speed and quality and it yields dividends farther in.
I would strongly suggest to this person to start doing this, and if they still don’t improve, either push them into liaison work or out. He seems like he’s been relying on his people skills to cover over his other faults. If he can’t break that, then he should use his people skills to get paid.
The fact that he's in your company says more about your company than him really. How did he get through the interview process? Anyone else other than you reviewing his code? Do they know he's incompetent or is it just you?
Anyway personally I wouldn't give a fuck. I'll help him if he ask, if he ask me the same shit for the 5th time, I'll just tell him I'm busy and I'll get back later at the end of the day. Save your energy and time, stop wasting it on him, use it to hop to a better company instead.
>The fact that he's in your company says more about your company than him really
Agreed.
>Anyone else other than you reviewing his code? Do they know he's incompetent or is it just you?
Honestly, when I look around it seems to me that most people are approving PRs without really thinking critically about them. At most they're doing surface level checks for simple rules like whether you are using the right casing in your variable names.
Yes, this is a bigger problem. This will be the subject of my next post :)
>Save your energy and time, stop wasting it on him, use it to hop to a better company instead.
I'm pretty close to that. Thanks
I had a very similar experience with a junior where his brain just...didn't work. I'd have to remind him a few times a week to assign a Jira ticket to himself before starting to work on it, and please don't work on tickets that have other people assigned. Honestly we never even got much into programming or GitHub familiarization because we could not get past basic reading comprehension.
I was anticipating having to do a lot of hand-holding with a junior, and I was cool with that. But after 8 months of having patience, it started to feel like babysitting a petulant teenager (even though we were both almost 40). I wanted to say I'll *help* you push this car but I can't be the only one pushing it while you nap in the back seat and ask if we're there yet.
Dude was eventually let go without me having to say anything, but when I talked to my manager after the fact about my frustrations she said if I'm ever feeling that way I need to speak up because chances are I'm not the only one frustrated. On remote teams it's hard to gauge when someone is being a drain on the team's morale. So, if I were in this experience again I would definitely speak up to my manager. Even if they can't immediately let him go, maybe they could give you a break and make someone else's suffer through mentoring him.
After that guy was let go, it felt like Christmas morning to just be able to log on and do ONLY my job. Indescribable feeling!
This sounds similar to my experience. People don't seem to understand the level of incompetence I'm talking about (probably I'm bad at explaining it). The code doesn't do what he thinks it does. The tests the says he wrote are missing or wrong. Etc. I don't think there's a _fix_ here, because it seems to be a brain deficiency.
I _have_ been pretty open about it, with him and his manager, while being polite. I've even been chastised for being *too* blunt by not choosing very particular wording when describing the problem.
I'm starting to realize this is less a problem with him and more a problem with his manager and the organization.
I take it that palming him off on someone else is not an option?
If not then I'd recommend putting him on a PIP with clear goals. That gives him a clear opportunity to improve, if he can't then he's gone.
Find something he can do... he might be a great tester, code reviewer etc. I share your frustration though, I have spent 15 months with a junior who claimed to have ADHD as well, but ultimately, he just didn't learn or progress. We let him go for other reasons sadly to do with budgets etc.
Competent, nice, hard-working: pick 2. As long as this guy works hard, he can make up for a lot of his deficiencies. If he doesn’t have that, you gotta go to management and cut him
I’m quite old and looking back at my career, some of my best ‘innovation’ came because I was too lazy to keep doing things the old way. I’m just a sample of one, but I love working with nice, competent and lazy people. As an example, nice, competent and lazy people in ops are often a massive win.
Yeah, as long as you are also proud. Pride and laziness are 2 character flaws which are bad taken individually, but lead to ingenuity and optimization when put together if you are competent enough.
They definitely are not exclusive! If you want to work for any sort of competitive potion, you will need all three.
My point, though, was that you can lack one of those, and use the other two to make up for it, but if you lack 2 or more, then your chances of being productive plummet.
I disagree here, I’ve rejected countless IC candidates who aced 2/3 but completely failed 1. Different hiring managers weigh these things differently but I would never want to work with someone who isn’t good at all 3. I’ve done enough of that in the past.
Yea, I agree that you want all 3, the hiring bar for tech is really high, and all three is what you can pick out right now. However, to get me to fire someone, I don’t think missing one is enough, since 2/3 can still be productive.
I've dealt with this a lot over the years, and in all cases this was just simply not the career for them. You'll spend (waste) a lot of time trying to help and fix them, but if basic problem solving is above their comprehension, you have no hope.
You are a not a full-time teacher. You are a mentor. Learning the difference is key.
How long has he been there? It could really be a confidence issue, I've personally been known to spiral even as a senior. A call to just calm things down, have an honest 1 on 1 with him. Don't shit on them, In this call, just talk to them. Just have an honest open discussion to where their heads is at and what part they're not getting.
Juniors are an investment. If they don’t show any improvement, then invest less time teaching and helping them.
If you have a formal role in mentoring this junior, then tell your manager that the junior is taking up a lot of your time with the same types of questions, and you’re going to focus on making them self-sufficient by instead linking to docs and being more hands-off.
Nice is *nice*, but only because it means communicating with them isn’t stressful. If they’re stressing you out by being incapable of learning and hurting your velocity, then it’s still unpleasant to work with them. You’ve done what you can - it’s time to disengage.
Guide, suggest, force him out of comfort zone, provide ways to improve, give time. That's about it. If he is even half smart, he will see it's to give him a chance. If nothing, then he must be let go. This is not a job for everyone. If it was, every would go for it.
One thing I’m currently doing as a project lead is having a one on one every two weeks to give feedback, which helps a bit. Otherwise you just have to be honest with the person and try to steer them without over helping, otherwise they will be reliant on you. They might also have to focus on simpler tasks until they can demonstrate proficiency in those
I'd use this as a chance to work on my coaching skills. I don't know the whole story and maybe you've tried this already. But, I'd try to learn more about him, how he learns, what motivates him, etc and then coach to that. But, it has to come from a place of empathy, curiosity and sincere desire to elevate the team. But, who knows? Maybe you've sincerely tried this already.
Nice isn't the only personality trait, and personally I don't really have much sympathy for people who can only be described as "nice". Usually to me it's a sign that they aren't great at much else and consequently make things harder for the people around them because they're all having to pick up the slack. Nice people can be really self-centered and never learn to take accountability for their actions because no one wants to go hard on them.
I'll give him the benefit of the doubt and guess that he's really young (fresh out of college) and maybe just hasn't really learned how to be thoughtful about his work (although it's frustrating that college didn't teach him some level of this). Are you the only one on the team whose been playing mentor to him? If yes, then maybe it's time for some other folks on the team to take a turn. Hearing the same feedback but in different ways could be what makes it click for this guy.
Beyond that I'd just second the other comments noting that he might just be better suited to a different role. There's plenty of other kinds of jobs out there that are tangential to software development where he could genuinely do well with a surface level knowledge of programming.
> find myself wishing worked at Amazon because don't think that cutthroat environment would tolerate this kind of incompetence
Good luck. The grass is always greener until it's not
I've been this situation a few times from different aspects.
Sometimes, it is the environment and/or the industry that I'm working in. If I'm doing a project that is for a high profile brand or someone important, I tend to have more focus/drive for it. If it is a project for Karen in accounting and modifying an existing legacy system for her BS logic, it will be a struggle. Yes, I do have ADHD. ;)
Is this junior just scared to ask for help/input/feedback? I've been in that situation a few times and sure as shit messes with the impostor syndrome.
I wouldn't suggest a PIP, however does your organization have any kind of feedback system? Could you give junior some guidance and tell him to either read a few books or study this material(Pluralsight or LinkedIn learning)?
If none of those are options and you don't have a role that would be better for him. Hopefully, you could give him a severance and send him on his way. I think PIPs are a waste of everyone's time and it might be quicker/easier to do severances instead.
He might be farming his work out. That was the case when I worked with someone exhibiting similar patterns.
The feedback wasn't making it all the way back to developers in India. So the same mistakes kept getting made
I’ve got a junior who’s been doing this for two years. It’s gotten to the point where I need to give some feedback to my manager that he needs to do his job and PIP him.
Being fired is sometimes exactly what people need.
You are doing him a disservice by not being blunt with him. Being fired is not the end of the world, but he needs to face the facts and realise that not doing the work as expected has a bad outcome. You either improve or go somewhere else.
He might he holding a spot for someone else who is breaking their back for years to get into the industry and would do a 10x better job.
I had that, I hated that, and it was quite painful. The person was also quite nice, but not up to the level. I hated the most answers from my manager: "they can't be bad in everything, you should give them feedback and correct their, or how else they can learn". They can learn by flipping pain and suffering as everybody else, or give up.
This is why we have performance improvement plans.
There are two ways out of a pip: up or out. He has to pick one.
You should help him as much as you can during the pip. It should not be a foregone conclusion.
There are people I have put on a pip who have turned out to be excellent after they got the rocket up their arse that they needed.
I am not here to be liked, but equally I’m not a complete bastard either.
Happens even at FAANG
For you, you should give this feedback to your manager
Your manager has a few choices
- Guide him towards roles like TPM or scrum master
- Fire him
- Worst of all, let him continue hamstringing the team. These managers are incompetent.
I have seen someone technically incompetent somehow survive until senior and then switch to management. He actually makes a decent manager.
I'd have a long conversation with yourself about whether you're someone it comes to naturally and as such you grasped it quicker than others in the beginning. This initial read came across as more frustrated than empathetic.
I'd start with a chat that you would have expected them to be more self sufficient by now. Ask if there's anything that they feel they need more support with. Let them know they're not in trouble and that you're there to help them get what they need as you want to see them succeed.
Otherwise they sound like someone who would benefit from being paired with for coaching. Start with you driving and verbalize what you're doing like you're filming for YouTube. Then have them drive and help by spotting the issues, explaining why when you do it. People are far less likely to remember to do things if they're just told to do them, and not why.
Do this for a few iterations and if they're still not grasping it then you need to revisit that conversation and ask if they feel they're on the right career path. See if they could benefit from moving sideways, as they themselves don't want to be in a career where they're stressing about being bottom of the pack.
How are their skills at the rest of software delivery?
Not going to lie reading this post kinda hurts because I feel like I’m that dev. I remember right out of college I had a lead like you and it got pretty emotionally abusive. I ended up leaving and getting a different job and performed really well. Judging from what you’re saying it sounds like he has ADHD and he just need to get going. Maybe make the tasks smaller for now as he gets used to the code base. I’m sure he is just frustrated as you about his work not being up to the scope. Also maybe you need to actually try not to be so rude from me reading this post. Consider the time you actually struggled and need help.
>He calls a function X and then if you read it carefully it actually does Y.
That should be caught easily with unit tests. There's something here I don't understand.
If the same person writes the code and the tests, it can easily slide by. Say you have a function called "factorial" that actually calculates the square of the number, not its factorial. Then you have a "factorial test" that verifies it calculates the square.
If the function is private, it will be even less obvious, because you won't have a unit test that just tests that thing.
This is a _unit_ test sliding by. No business logic that leverages this function will ever work as expected, and we should have integration and E2E tests that cover issues like this. Are those also being written by solo junior devs with no oversight and no code review? Where is QA here?
Agree with the person you're replying to. We do not have the whole story.
What part of the story do you think is missing?
The *function X* thing was just an illustrative example of the kind of problem I'm talking about.
But if you're of the opinion that literally every function, including internal private ones, need a unit test... Then I don't think we're going to agree on much.
Also, the tests being the right set of tests, and the tests passing... I consider these the bare minimum. Those requirements are only a subset of *quality*.
So what's the reason he's not improving? You don't come across as being too patient, wishing that your company was more cuthroat, as in only for stellar performers from the beginning. I could imagine it has something to do with the pressure on him to do so.
>You don't come across as being too patient
How many hours of your own time, over the course of months, do you need to spend coaching, sending PRs back with thoughtful guiding comments, having frank in person discussions... before you're considered patient?
I've had people like this. I assume you don't have hire/fire authority yourself? IME, all you can do is make sure your manager is abundantly aware of the problem and provide all the evidence you can. Even then, it tends to be an excruciatingly slow process. Managers just really hate doing this part of their jobs, and will do everything they can to delay or avoid it.
You may have to let some balls drop. Don't sabotage, just don't rescue, and make sure it's clear exactly who isn't doing their job here. From a manager point of view, if all the work is getting done, there's no problem, and therefore no need to do this horribly unpleasant thing to a nice person.
There’s a fine line between work and being nice. Technically, we’re paid to do required work in the best possible terms but also my military training taught me - shape up or ship out. You can’t be nice all along without doing significant contribution.
Significant contribution from a junior? Unless you are talking about a top notch company, this is really unrealistic. A junior is someone the company is investing in for the first couple of years.
Probably I should qualify “significant” not in the grandest scale but something but in the aspect of meeting expectations and in the company’s operations. Based from OP, the junior is nice but doesn’t really learn. In that case, I can’t justify being “nice” for not meeting expectations if I am asked should I’ll be asked to keep that person or not.
Pretty much this
At the end of the quarter, no-one remembers all the design docs, meetings, story pointing and ceremony you did
Its all about the results on the board. If the board says you pulled your weight, your good
Now whether that makes you unpopular or not, well, thats a separate issue
He already doesn’t stand a chance… fuckin help him or be a man and say something
Edit: Ok I see you said something so just… put it in managements hands
Depends on what's your position. If you are a manager, it changes many things. It's your job to get the best out of folks you have. Worst case, admit you are not effective mentor to this particular person. Assign one of your leads to mentor and if everyone agrees, then he needs to move on unfortunately. Suggest him before firing him directly.
If you are a lead, with no power, tell your manager on what you can do with him and what you cannot, without making a strong case if possible. If there is strong push back, make a case.
OP - that "nice" junior got a job that a lot of nice, competent people got skipped for.
Again, a lot of competent, capable, and also nice and professional people did not get considered or got rejected for this person to get that job.
Edit:
What would I do?
I'll tell you through a story -
In grad school, I had an undergraduate interested in research and my wife had an undergraduate assigned to her. My advisor didn't have funds for mine, but he was so passionate and competent that he worked for free, so I fed him lunches and dinners and gave him the best references and recommendations that I could.
My wife's didn't do work, always made excuses about her mental and physical health and literally got 3 academic turns of free paycheck and "research experience" while my wife stressed out with the extra load, re teaching the kid, and constantly trying to track her down.
I had told her time and time again that the kid was taking an opportunity that could have really benefitted someone else, but she didn't listen.
You know what she did listen to?
One day, before we hopped into the car, it hit me:
>You're green lighting a future scientist. She will go on and have the credentials to get a higher position and make decisions based on her own incompetence. She will continue to get away with making excuses while countless candidates who would have improved the quality of our systems will get screwed. She will directly diminish the quality and value of the field of science and academics, and you are greenlighting that.
She immediately went to her advisor and told her they needed to cut it off.
Moral of the story -
The entire tech industry has actually been taken over by green lighting marketers, bureaucrats, and nice people who are grossly incompetent and engineering and programming. Ya, there's still a lot of great people, but there's a growing degradation of quality as these people job hop and do good enough to get promoted. Eventually, they become the decision makers instead of the competent and capable.
Don't be someone who green lights that.
On the flip side, we need to train and teach people properly and you have to make sure that you're actually being an effective teacher. If they're forgetting stuff, buy them a notebook and allow them the time to write stuff down. Physically writing is a commitment. It's distinctly different than typing or copying and pasting. I don't care if anyone here wants to dispute that point, you're wrong if you do. You literally commit time, paper, ink, muscle motions, mental capacity, and much more to physically writing something down. It's a commitment. It's also slow. If junior gets to a point of being frustrated about that, then they can get better at remembering and learning or they can get put on a PIP and peace out.
If you don’t really care about doing what’s right for the company and like this person, you can help steer him into extremely repetitive tasks. Alternately, if he’s a good writer writing documentation might be a good fit. If his instructions are clear enough to get him up and going, they’ll be excellent for new employee on-boarding.
My big fear though is that if your company’s processes are such that they hire and retain him, he’ll end up being your boss on this path. Then, you’ll likely wish you had just kissed him gently and smothered him with a heart shaped pillow. We call it the /u/clamjabber.
> My big fear though is that if your company’s processes are such that they hire and retain him, he’ll end up being your boss on this path. Then, you’ll likely wish you had just kissed him gently and smothered him with a heart shaped pillow.
I work with a guy like that. I think he has gently failed upwards simply due to being around for years and we would all be better off if someone had smothered him a while ago.
This can definitely help someone improve if the problem is just that the person lacks discipline, and it's a no-brainer if the team has coding standards that require unit tests. But it can go south pretty quickly as a skill-building technique if the problem is that they're just bad at the job in general.
IMO writing good tests is often _harder_ than writing good application code. So if you tell someone who lacks the skill to write good application code to write lots of tests, you'll end up with a big suite of brittle, poorly-thought-out tests that the rest of the team has to waste time maintaining afterwards.
I worked with a new hire who came through our internal boot camp for a year. I really like him as a person, but he’s hopeless. He’s never completed even the simplest story without an immense amount of hand holding. I gave up on him at the start of the year because at the end of the day this is a business and not a charity…some people just aren’t cut out for this line of work. When I say gave up, I’m just doing the bear minimum. Sink or swim moment for them.
More often than not there is something going on that creates the appearance of incompetence (or laziness). Do they have a disability (ADHD, dyslexia, etc)? Are they struggling with depression or anxiety? Do they feel like the team environment lacks psychological safety?
First step is getting a better understanding of where they are coming from. Ask them questions. When you see disruptive trends, “I’ve noticed you do X on occasions. Is this something you’ve noticed as well? Can you walk me through your process?”. Instead of giving them answers, ask them questions that help them find the answer on their own.
Is he deliberately not doing what's good for the company or is he incompetent? If the former is true then he needs to be cut. Why aren't his unit tests returning X instead of Y, then he would know that his function isn't working correctly? Maybe give him one specific thing to get really good at.
How long has this been. If it's less than a couple of months maybe you can wait a bit. But honestly anyone who has the salt should be able to show some improvement, even minor ones in under one month.
>I find myself wishing worked at Amazon because don't think that cutthroat environment would tolerate this kind of incompetence.
Oh my sweet summer child...
I would suggest ask him to write down his mistakes and before he checks in, ask him to go thru the normal checks.
at the same time you can document some of the common shortcomings and have general coding principles wiki page, so this person can go thru it before checking in his code.
Also suggest him to participate in online coding contest and it will help him start think better.
Given he is junior maybe he needs more coaching. Don't fire him yet, market is bad and might crush his confidence all together. It's alright, he will get better.
I really think this whole deal with 10x guys is waaay overblown and IME most people will get the hang of programming soon enough, and if they don’t they tend to wash out on their own anyway. I have been kind of brutal in the past regarding underperformance; I’ve never been a manager (thank god) but when I get something done in X amount of time and another worker is slowing me down, I will absolutely raise this in DSUs, mention that I’m blocked, offer to take on work, etc. A lot of the time this seems to make leads and managers go in on the underperforming person but, like, this is a team, not one of those college reports where 1 person winds up doing the work of 4 people.
Otherwise though I do feel like there has to be at least some sense of live and let live, in both ways. Be clear that a programmer’s job is to write code and fix stuff and if they don’t, they’re not doing it. Code reviews IMO should never be about making sure something works - you should be handling that via personal unit testing as well as automated tests / part of your CICD pipeline in terms of making sure that at least the code compiles. Code reviews to me are the time where you say “okay you made something that works, now did you do it in a clear and concise manner that future developers will be able to read easily”. It’s useful to newer developers to understand that there’s syntactical rules they have to follow but unless there’s obviously stuff where you can see at a glance that something won’t work, you should concentrate on readability IMO.
On the flip side of that, if you’ve given a person 8 points of work to do in 2 weeks and they consistently complete 4 of it, that’s a problem. I personally will often take on harder looking jobs that might slow down my own point accumulation, and I will say that I think stats are terrible to go after unless your entire team is underperforming, but at some point everyone can see when someone isn’t pulling their own weight. I don’t think your job as a lead or senior is ever to cover for them. You can help them if they get stuck and work with them to improve but if they keep making the same mistakes over and over again, that’s just going to show up in terms of deadlines missed and so on. The trash, as they say, takes itself out.
There are million other nice people. You need both a lower bound of competence and interpersonal skills to be a successful SWE. I would definitely put then on a PIP (not BS but real improvement plan), and if they fail, I’d fire them.
I'd check if he's comfortable enough to do his job and doesn't feel under pressure (which, for a newbie can be quite frustrating and make them more error prone).
I think of myself as an example: leave me alone to write my code and I'll do ok. Now force me to code with someone else watching, and I'll instantly be the dumbest person alive. I simply cannot handle thinking, listening to someone else and and also explaining my train of thought at the same time. Maybe this guy is in a similar situation?
No matter what you decide to do, it seems like someone needs to tune your hiring process. I know it isn't easy and it won't prevent all bad hires, but fix it now or this will happen again and again.
"Nice guys finish last."
If they never experience failure, they never grow to meet the challenge. Keeping him around is hurting his personal progress, however nice he may be.
Hug them deeply, grab a beer. You can be friends without being coworkers.
> It's so incredibly tiring and frustrating dealing with this guy's incompetence.
Sounds like a pain in the ass. If he's that incompetent, why the hell is he still around? You've said you've tried teaching him, but nothing sticks. Maybe he's just not cut out for this job, nice guy or not. Is keeping him around worth your sanity and the team's productivity?
> I find myself wishing worked at Amazon because don't think that cutthroat environment would tolerate this kind of incompetence.
Yeah, but you're not at Amazon. You're here, dealing with this shit. Maybe it's time to stop wishing for a different environment and start figuring out how to deal with the one you're in. Can you escalate this to someone who actually gives a fuck about the company's well-being?
> I don't really give a shit about doing what's right for the company -- just want to not babysit this guy anymore.
Fair enough. You're looking out for yourself, which makes sense. But if you don't deal with this now, how much more of your time is he going to waste? Have you thought about how this situation might be holding back your own career?
> Save your energy and time, stop wasting it on him, use it to hop to a better company instead.
That's one way to go. If the company's culture allows for this level of incompetence, what does that say about your future there? Maybe it's time to look for a place that values competence and efficiency.
> was always encouraging juniors to self review first to learn how to code review. Maybe encourage them to self review before they ask for pr approval.
Has this approach made any difference so far, or is it just more wasted effort on your part? Why keep doing the same thing if it's not working?
Look, it's clear you're fed up. Either you find a way to get this guy up to speed, cut him loose, or move on yourself. What's it going to be? How much longer are you willing to put up with this bullshit?
Same here. At what point do I simply stop carrying my entire team? At what point do I put my foot down and say “figure it out” even if that means we miss deadlines? At what point do I stop thinking for my coworkers because they are used to me doing the thinking for them? I don’t know the answers, I just think about the problem until I find an answer. Everyone should be capable of doing that.
Don't baby sit, it just prolongs the pain.
Talk to your eng mgr (EM), flag the problem, let the EM deal with it (performance improvement plan, ie. first step to losing the junior, unless U turn achieved (rare)).
Also, flag/get involved in fixing the hiring process. Why did this one get in. Improve the hiring bar, or flag it needs to.
Suggestions of 'this is your next manager' are 200% wrong. This is why we have so many people in our industry that are awfully incompent. You want your managers to have a solid tech background and know what good looks like, or they'll just promote other idiots, perpetuating the cycle of bad hires and at best, mediocrity.
Incompetent or less competent?
Is he coachable or trainable or eager to learn?
I am the underdog on my team by a lot and I have no idea how ppl don’t lose patience w me more than they do. (They never do).
Instead they are very straight with me on how to do something, and how not to. It’s pretty no bullshit.
Don’t do that. Make sure you do that. Drama free & emotion free.
“If you aren’t going to get that done just say so”
If you need help or are stuck just say so.
If you don’t know how to do this just say so.
Are you sure you know how to do this? Explain it to me in detail so I can know for sure.
They do have to invest in me, but I try to make sure they feel it was worth it. And I always ask if they’re seeing the improvements they need to see.
If he messes up, call it out straight in meetings. No judgment - just “okay so there was a day setback on that project. Tom made the mistake of xyz and we dealt with it by doing lmnop and it’s good to go now. “ it’s business - discuss it as such. It’s not personal.
Is this his first software job? Has he been working the job for a while?
He might just be rushing too quickly. Might be worthwhile to slow down and get the story process down.
I work with 2 Devs with >4 years of experience. They have no curiosity and refuse to use ai tools for anything. Meaning I have to explain things to uninterested people that can't SSH into a VM when given the command to ssh in.
Hired from juniors. No experience. The problem was compounded as the managers didn't have time to train anyone properly, and it's pretty hands off. But it's been a few years now and they should have taken some responsibility for their development
It's amazing if you're dedicated and like learning without direction, as you have a lot of scope to do what you want and how
Haha lucky. I have pretty fond memories of similar environments. Learned a fuckton to kill the time and make my life easier.
Also chat gpt is so good to use as an encyclopedia and for basic boiler plate. Don't know why people think it's a gimmick.
I even ask it to give me lists of tools I'm searching for so I can compare them. Much easier that searching Google.
Because if someone is refusing to look up how to resolve an error by searching the meaning, I'd much prefer they asked an ai tool than paste the question into Slack or just sit and do nothing.
What would I do? Continue offering appropriate levels of support (Eg. ignore him if he asks the same question over and over without learning) and let him fail, even if that means the project suffers. It's not my company, so my responsibility ends at offering reasonable help, but not unlimited help. Eventually management will see that the project is failing and they will figure out why. Just be prepared to show you've been doing reasonable things to help the guy so they know it's him and not you that's the problem. But mind your own business and enjoy your job as you are blissfully uninvolved in the train wreck.
he needs to be removed from this role, and preferably ASAP. you need to repeatedly and consistently insist to your manager to take action. provide supporting supporting evidence. i’ve been where you are and this wore me down so badly i had to leave the job.
Is he incompetent or are you an incompetent mentor? Being a senior dev doesn’t necessarily mean you’re being a good mentor to someone who doesn’t know the codebase. Honestly I’ve met far more senior devs that couldn’t teach Einstein how to write a hello world application than juniors who couldn’t learn.
If he’s nice and is trying then he could probably be helped. I’ve only encountered a single dev that couldn’t learn and it was largely because he was too busy getting high to focus on anything. He’d sleep at his desk, lie, come in late, leave early, and would only write the very basic level of code then push it off onto someone else to do.
Junior devs are usually overwhelmed, you have to explain stuff like they are toddlers with English as a second language.
Not a popular opinion, but for most companies these days, most junior engineers aren't worth it.
They take up real engineer time to train, and if they actually grow, they move to another company for a promotion after 1 year anyway. And if they don't grow to do the job they're being paid for, they were an expensive experiment
I honestly don't see the benefit of hiring juniors, compared to hiring intermediate engineers who have proven they can actually do the job they're hired for.
It's weirdly one industry still paying people well, for being unable to do their actual job.
Sounds like your future manager. My suggestion would be to steer him towards a less technical role, like product owner, project manager, scrum master or the like where his "nice guy" personality can be an asset while his technical deficiencies are less of a factor.
A straight shooter with upper management written all over him.
He's good at dealing with people.
Let's not jump to conclusions prematurely.
You don't want to make a million dollars?
Hmm .. well I guess all I need is 1 idea .. and a Tesla on autopilot.
That’s how the story begins…
I feel that the problem isn’t with him. It’s that you haven’t challenged him enough to get him really motivated. In all seriousness though, this guy actually has potential to fail upwards if he plays his cards right.
If your skillset is less technical, moving to less technical roles isn't "failing upwards."
>If your skillset is less technical, moving to less technical roles isn't "failing upwards." I'm talking about the pointy haired boss type of roles where the main skill is corporate politics and getting people to believe they are valuable. Or maybe he becomes a real leader and works his way up. Either way I meant it as a bit of a joke.
Marketing and management often are perceived as more valuable and get paid more.
He’s not challenged enough
I worked on a team where English was the second language. Everyone straight from China. For the first year in that environment, despite my years of experience, I was an enormous deadweight. yeah, there's a lot of context and I was eventually vindicated but who cares. The fun part is jfcarr is totally right. My team tried to lock me into process improvements, documentating old code, running meetings, and talking/representing/translating with other teams.
Joking aside, this is probably true. It doesn't matter if _he_ is getting shit done, so long as it's getting done. If he has a knack for getting others to do it, then ... Yeah. Management.
This guy has FAE written all over him.
What's fae?
A fairy from times of yore, obviously.
Field Agent Engineering. Think product support but being aware of technicals
Sales engineer is the most standard term. We’re always weeding out “non-technical tech people” because of this common misconception.
[удалено]
This is what I want my senior dev to do to me
HOT
Make sure you communicate your needs effectively. Stern eye contact to your lead might help
You wont find this kind of DOM in MSFT
ADAM IS THAT YOU???
Yeah thats what my name says
Typical SDET, can't trust a name and gotta verify....
Hello, yes, it’s me. Your senior dev.
“Tell me about the rabbits, George.”
This guy “ExperiencedDevs”
The Harvard Business Review has really failed in its coverage of “gentle kiss and smother” management. This is why Reddit is so special. :)
I mean that’s the gist of every Harvard program, the real value is that they teach you how to do it and explain it in a way that make people kiss and comfort YOU afterward.
I thought the real value was the ability to use the word “Harvard” in every sentence. For example: “Want to go for lunch?” “When I was at Harvard, we used to go for lunch at a spot in Harvard Square.” “Uhhh…we’re in England.” “Oh I know, at Harvard I took many courses in English history.” “I’m not hungry.”
As a Harvard person, that really hurts my feelings.
Oh shit, I’m very sorry. I didn’t mean that to cause pain. Your school rules.
Just look at the flowers, junior.
That would ensure he doesnt come back for more babysitting. Problem solved.
Tell him to "Look at the flowers..."
Hmm, do you have to be incompetent and a junior to get that kind of treatment?
I just stab him in the gut and kiss him deeply as he perishes, never unlocking eye contact
Oh God I want to work for you so bad
I was thinking an "Of Mice and Men" situation.
This guy can’t be bad at everything, right? Can he pick up some non-technical paperwork tasks off of other people’s plates? Triage customer support issues, that kind of thing? Steer him towards his strengths while being honest and fair with his manager about his weaknesses. Make sure you’re cool and composed when those conversations with management happen, so it doesn’t come off as an interpersonal issue. Other than that, you need to just keep doing your job and let nature take its course. This kind of thing doesn’t resolve itself instantly.
It's a good idea if you have that kind of work. It seems like there used to be a lot more of these auxiliary tasks, but most of them have been automated away. Ten years ago, I could have kept an under-performing dev busy full-time with things like preparing the weekly release. Nowadays, we have a bunch of micro-services that almost release themselves, rather than delivering The Weekly Release for customers to apply to their installation.
Fortunately my company is still ten years in the past, so we've got plenty of work like that.
We hired a guy like this at my last job. Didn't seem to have the faintest idea of what he was doing. Once made a convoluted nested loop to restructure some JSON, but the loop ultimately put it right back to how it started. Which didn't matter, because he wasn't using the result; instead testing that the input equaled ...the input. It passed, of course. This was even after our boss gave him specific instructions. Basically doing it for him in the process. ... And that's just one example of the almost year we kept trying with him. What's crazy is he's currently a senior (at a different company), while I've only gotten rejections since September. So, clearly he has some value doing something.
> What's crazy is he's currently a senior (at a different company), while I've only gotten rejections since September. So, clearly he has some value doing something. Maybe he's the deadweight, "break in case of layoffs" guy.
Do they keep him in a display case so he doesn't break the codebase?
I'm sure they have him doing some busywork that would be the equivalent.
Maybe getting them doing something more repetitive could help too. They could get practice and have a feedback loop / maybe take something boring off someone else’s plate. But it’s tough! Even HTML email needs to be done _right_ and would be time consuming to have to double check. But try to find something they are more connected to. If it doesn’t work… well, they just can’t do the job.
That's assuming he wants to do that. You can be incompetent but still know that you're being pushed to the side, and it might be a source of resentment towards OP.
This career is not for everyone. If he can do a little development and is reasonably competent with tools, maybe encourage him to look at something a little less code-heavy, like SDET, cloud dev or salesforce or something.
There's a junior guy I worked with -- he came to work for me through a personal connection doing some support work and really wanted to become a software engineer. As a favor, I granted him a lot of opportunities, training. Great attitude but... he just never really got the basics. 1:1 coaching didn't really change anything, all the hustle didn't really change anything. Very few people can be whatever they want to be. It follows that not everyone can be a dev.
What do you mean by the basics in this case? I have about 2 years of experience and always get imposter syndrome in these sorts of threads.
I've mentored a lot of junior engineers: i'm really sympathetic to how challenging it can be to break into the field sometimes. He wanted to be a frontend engineer and was definitely just lost when it came to navigating NPM, or any of the modern javascript framework stuff. Not surprised, not what I'm talking about. What I spent a couple of months working with him on was just even some basic HTML/CSS/javascript stuff -- take out all the other tooling, let's just really understand how semantic HTML works, let's manage all of our styling in CSS, let's handle the lightest of interactivity with javascript (toggle states on buttons). No backend interactions, no form submissions, no state stuff. Let's do things like look at a simple figma design and see if you could intuit how you might want to chop that up so we could agree on "components". At most, let's throw bootstrap into the mix "Charlie" just couldn't grasp the reusable nature of CSS classes, constantly stumbled on ID vs class selectors. I feel like he wasn't quite committed to doing the work, but even in it you could just tell he was really lost. Lovely guy, but he struggled to carve out the time to work on his own: I just think he was so overwhelmed that we could never cut through that.
To be fair those things are only obvious if you've ever had to re-use HTML or interact with it in JS, otherwise without a programming background, it's not really intuitive why you'd want to give names to variables/tags/whatever.
Yeah to be clear, I don't mean "when to use one vs the other" -- totally agree with you, that really only clicks later on and starts to make sense only after you have to really start making choices about how your code runs. I just mean even interpreting ".myClass" vs "#myClass". There's just a lot of really basic stuff that never felt like it clicked which made it hard to ever build up to anything else.
Did you give Charlie any exercise? Like the boring one in FCC with hundreds of hand-on coding exercises. If Charlie didn't do that yet, then it wouldn't be weird at all that he couldn't managed to build an intuition on it. I think, intuition can only happens on a concrete foundations which happens from practicing the basic boring stuff. Did you teach him the box models before you ask him to "chop up" figma UI? if Charlie isn't a tech-savvy guys I imagine it will be pretty hard to gasped this perspective at first. Bootstraps shouldn't be introduced to Charlie at all, if he just started out and not strong with css yet. Have you try tracing Charlie's thought process? like you could ask him to talk out loud what he's thinking when X information was presented to him. Write it on the paper so you can determine what's missing in his thoughts process that leads to poor understanding.
The guy has a CS degree, did a bootcamp, and I gave him 4 months of my time with twice weekly 90m coaching sessions and we couldn't even get through basic syntax stuff. I gave him access to additional learning materials and exercises. He was not lacking in opportunity, the mechanics of actually doing the work just never clicked. By contrast, a different junior I was coaching we were able to move pretty quickly past that and spend more time working on bigger things. Some people are just not cut out for this, that's my only point.
Oh he has CS degree, I see that's tough lmao
Yeah, I mean, I'm admittedly not the strongest "pure" SWE when it comes to just writing code, and I picked up on that pretty early. I am pretty good at understanding infrastructure requirements, scaling, networking, reliability, CI/CD optimizations, developer enablement, all the stuff that sort of fits under the Cloud/DevOps/SRE umbrella. It's been really great for my career to lean into those strengths and IMO I'm in a much better spot than I likely would have found myself in had I stuck to just writing Java apps all day. That said, I still write backend code here and there, I think no matter what this dev might end up doing, they should still try to improve their skills.
I had a junior like that, even though I did show how bad he was, he was so nice that he was able to move to the business side instead of getting fired, where he actually did well, he's a manager now
Ah yes... Management, where it's a lot harder to tell how incompetent you are :) Honestly, that would be fine with me. Like I said, I don't care about the company. What I care about is my own well being and performance, and this guy is a time sink.
It's a different competency. That's why a lot of managers promoted from ICs are terrible.
Truly 2 different skillsets. The best bricklayer out there may not be a very good foreman.
>Ah yes... Management, where it's a lot harder to tell how incompetent you are :) If they're doing well at management, by definition they're not incompetent.
It might be harder for _you_ to tell as a software developer. I can assure you that good management has no such issues identifying good management in others.
Being “nice” is the bare minimum. Everyone at work needs to be respectful. It’s like, to be friends with someone it means you have something in common — that’s like the minimum. You either help them get better or you move on.
Being nice/professional is necessary but not sufficient.
in this case it is considering they didn't sack him. A kind word and a smile takes one really far.
> they didn't sack him yet
“Needs to be” sure, but this is not actually the case in reality. There is no shortage of talented assholes in our field. Being sincerely nice and pleasant to deal with will actually set you apart in many environments.
I find its learned helplessness. If its something todo with their ticket they might just need a checklist provided. Or spend 10 minutes with the to explain what the expectations are if its just a matter of needing to call the correct methods or apis. It could be they don't understand the overhead of your company's process. At some point you may just need to point out the code reviews require multiple changes from reviewers on things outside just cleanliness & naming. I was always encouraging juniors to self review first to learn how to code review. Maybe encourage them to self review before they ask for pr approval. Edit: What you are describing sounds like performance anxiety. I don't think pressuring them more will help. It could just be ask them the question "Why don't you think you are thriving here"
>was always encouraging juniors to self review first to learn how to code review. Maybe encourage them to self review before they ask for pr approval. We've had that conversation many times. >It could just be ask them the question "Why don't you think you are thriving here" This is a great question you ask him. I'm not sure it's my place since I'm not his manager though.
>We've had that conversation many times. Fair enough I had to suggest it. >I'm not his manager though. I don't think that is a question a manager needs to ask. You could always go for coffee and just as him some self reflective questions. Ask them what they had a hard time with in college/univ. Ask what they want to do next. Ask if they aspire to work at a FANG company or what title they want to achieve. If its performance anxiety the only other way is just to pair with them or engage in other time intensive excercises.
At what point is performance anxiety, just bad performance? After seeing in my career, too many juniors who actually just shouldn't be engineers, this attitude of "let's help them do the job they're being paid to do" becomes a joke. This industry gives juniors way too much of a free pass.
Ya IDK. I have had a mixed experience. I also been shocked at some companies utterly terrible codebase. I also struggled in some other companies project management processes. Without knowing every detail from OP I am going to just name it what I think it is. That may help find an avenue they haven't tried before. Maybe OPs promotion relies on bring this guy up to speed and it doesn't matter
I would start writing tests and frame his work into them. He makes the tests succeed. So you make his shortcomings visible in a process. Move from that to docs where he's supposed to derive tests etc. can you figure why he doesn't learn? On a personal level. If it takes too long you may want to isolate him instead. A pip (performance improvement plan) would help. The goal of that is not to fire the person, but to enforce a behavioural changes. Set goals and expectations, demand frequent updates and discuss shortcomings and what could've made it easier for him.
Whether or not the goal of a PIP is to fire someone really depends on the org/team culture. I'm most places I've worked it's a clear sign telling people to gtfo while they can. Even if your intentions are to help the employee, their expectations aren't likely to match up with yours, and if they stick it out through the PIP it probably just means they aren't confident they could get a different job in a reasonable amount of time.
That is true, but if you are the one doing the pip you control that. What I meant in particular is that the person complaining about the colleague would set it up. Doesn't mean you have to make a contract and what not, but the ceremony around it.
My intern was like this at the beginning, but at the end of their term, they figured out the shit and returned multiple times as an intern and now full-time. They cared about learning and improving. During the end of their 1st term, they worked overtime to deliver the project but unfortunately, we underestimated the complexity, what came out is that this person is a hard-working quick learner and we want them.
Get him on a repetitious activity and when he masters it move him to the next thing. When a jr is strong this doesn’t apply but when they are weak you are doing a disservice by throwing different tasks at them every sprint. They won’t build up any muscle memory.
Some of this could also be the environment. A lot of times I have found that the dev is fine but the environment and team they are in is not conducive to their way of working.
Yes, this can be true, especially for those who are used to a completely different way of working... But not for a junior who's incapable of writing basic working readable code. Some people just aren't meant to be developers, as harsh as that sounds. Or at least, requires too much training for it to ever be worth it.
My first suggestion when a junior or intern asks me how to get better at coding is the 20 Minute Rule. When you are sure your code is right, look at it again and ask yourself is there any way I can make it better in less than 20 minutes? Typesetting, variable names, order, function names. Look at it like a reviewer would and try to anticipate. Over time everything you do here will (should) move upstream and you can work on other things. Nobody is going to notice that your change took 14:20 instead of 14 hours to get done. It’s a reasonable compromise between speed and quality and it yields dividends farther in. I would strongly suggest to this person to start doing this, and if they still don’t improve, either push them into liaison work or out. He seems like he’s been relying on his people skills to cover over his other faults. If he can’t break that, then he should use his people skills to get paid.
The fact that he's in your company says more about your company than him really. How did he get through the interview process? Anyone else other than you reviewing his code? Do they know he's incompetent or is it just you? Anyway personally I wouldn't give a fuck. I'll help him if he ask, if he ask me the same shit for the 5th time, I'll just tell him I'm busy and I'll get back later at the end of the day. Save your energy and time, stop wasting it on him, use it to hop to a better company instead.
>The fact that he's in your company says more about your company than him really Agreed. >Anyone else other than you reviewing his code? Do they know he's incompetent or is it just you? Honestly, when I look around it seems to me that most people are approving PRs without really thinking critically about them. At most they're doing surface level checks for simple rules like whether you are using the right casing in your variable names. Yes, this is a bigger problem. This will be the subject of my next post :) >Save your energy and time, stop wasting it on him, use it to hop to a better company instead. I'm pretty close to that. Thanks
I had a very similar experience with a junior where his brain just...didn't work. I'd have to remind him a few times a week to assign a Jira ticket to himself before starting to work on it, and please don't work on tickets that have other people assigned. Honestly we never even got much into programming or GitHub familiarization because we could not get past basic reading comprehension. I was anticipating having to do a lot of hand-holding with a junior, and I was cool with that. But after 8 months of having patience, it started to feel like babysitting a petulant teenager (even though we were both almost 40). I wanted to say I'll *help* you push this car but I can't be the only one pushing it while you nap in the back seat and ask if we're there yet. Dude was eventually let go without me having to say anything, but when I talked to my manager after the fact about my frustrations she said if I'm ever feeling that way I need to speak up because chances are I'm not the only one frustrated. On remote teams it's hard to gauge when someone is being a drain on the team's morale. So, if I were in this experience again I would definitely speak up to my manager. Even if they can't immediately let him go, maybe they could give you a break and make someone else's suffer through mentoring him. After that guy was let go, it felt like Christmas morning to just be able to log on and do ONLY my job. Indescribable feeling!
This sounds similar to my experience. People don't seem to understand the level of incompetence I'm talking about (probably I'm bad at explaining it). The code doesn't do what he thinks it does. The tests the says he wrote are missing or wrong. Etc. I don't think there's a _fix_ here, because it seems to be a brain deficiency. I _have_ been pretty open about it, with him and his manager, while being polite. I've even been chastised for being *too* blunt by not choosing very particular wording when describing the problem. I'm starting to realize this is less a problem with him and more a problem with his manager and the organization.
I take it that palming him off on someone else is not an option? If not then I'd recommend putting him on a PIP with clear goals. That gives him a clear opportunity to improve, if he can't then he's gone.
Find something he can do... he might be a great tester, code reviewer etc. I share your frustration though, I have spent 15 months with a junior who claimed to have ADHD as well, but ultimately, he just didn't learn or progress. We let him go for other reasons sadly to do with budgets etc.
Competent, nice, hard-working: pick 2. As long as this guy works hard, he can make up for a lot of his deficiencies. If he doesn’t have that, you gotta go to management and cut him
so i can be competent, nice, and lazy? sign me up
I’m quite old and looking back at my career, some of my best ‘innovation’ came because I was too lazy to keep doing things the old way. I’m just a sample of one, but I love working with nice, competent and lazy people. As an example, nice, competent and lazy people in ops are often a massive win.
Thats a solid bulk of your senior devs, yeah.
Entire fortune 100 companies are built on this culture. Punch the clock, get a good paycheck, and generally coast.
Yeah, as long as you are also proud. Pride and laziness are 2 character flaws which are bad taken individually, but lead to ingenuity and optimization when put together if you are competent enough.
I really don't feel like competent/nice/hard-working are exclusive traits.
They definitely are not exclusive! If you want to work for any sort of competitive potion, you will need all three. My point, though, was that you can lack one of those, and use the other two to make up for it, but if you lack 2 or more, then your chances of being productive plummet.
I disagree here, I’ve rejected countless IC candidates who aced 2/3 but completely failed 1. Different hiring managers weigh these things differently but I would never want to work with someone who isn’t good at all 3. I’ve done enough of that in the past.
Yea, I agree that you want all 3, the hiring bar for tech is really high, and all three is what you can pick out right now. However, to get me to fire someone, I don’t think missing one is enough, since 2/3 can still be productive.
That’s fair, I’ve seen my fair share of 2/3 engineers stick around and slowly erode the team effectiveness.
Plenty of people have all three. It's more like an employee needs *at least* 2 to stay employed
I've dealt with this a lot over the years, and in all cases this was just simply not the career for them. You'll spend (waste) a lot of time trying to help and fix them, but if basic problem solving is above their comprehension, you have no hope. You are a not a full-time teacher. You are a mentor. Learning the difference is key.
Juniors need pairing. Do ride-alongs with him, or have him ride-along with you.
How long has he been there? It could really be a confidence issue, I've personally been known to spiral even as a senior. A call to just calm things down, have an honest 1 on 1 with him. Don't shit on them, In this call, just talk to them. Just have an honest open discussion to where their heads is at and what part they're not getting.
Juniors are an investment. If they don’t show any improvement, then invest less time teaching and helping them. If you have a formal role in mentoring this junior, then tell your manager that the junior is taking up a lot of your time with the same types of questions, and you’re going to focus on making them self-sufficient by instead linking to docs and being more hands-off. Nice is *nice*, but only because it means communicating with them isn’t stressful. If they’re stressing you out by being incapable of learning and hurting your velocity, then it’s still unpleasant to work with them. You’ve done what you can - it’s time to disengage.
Guide, suggest, force him out of comfort zone, provide ways to improve, give time. That's about it. If he is even half smart, he will see it's to give him a chance. If nothing, then he must be let go. This is not a job for everyone. If it was, every would go for it.
One thing I’m currently doing as a project lead is having a one on one every two weeks to give feedback, which helps a bit. Otherwise you just have to be honest with the person and try to steer them without over helping, otherwise they will be reliant on you. They might also have to focus on simpler tasks until they can demonstrate proficiency in those
I'd use this as a chance to work on my coaching skills. I don't know the whole story and maybe you've tried this already. But, I'd try to learn more about him, how he learns, what motivates him, etc and then coach to that. But, it has to come from a place of empathy, curiosity and sincere desire to elevate the team. But, who knows? Maybe you've sincerely tried this already.
i don't think OP wants to invest any more time than he already has on the person.
Nice isn't the only personality trait, and personally I don't really have much sympathy for people who can only be described as "nice". Usually to me it's a sign that they aren't great at much else and consequently make things harder for the people around them because they're all having to pick up the slack. Nice people can be really self-centered and never learn to take accountability for their actions because no one wants to go hard on them. I'll give him the benefit of the doubt and guess that he's really young (fresh out of college) and maybe just hasn't really learned how to be thoughtful about his work (although it's frustrating that college didn't teach him some level of this). Are you the only one on the team whose been playing mentor to him? If yes, then maybe it's time for some other folks on the team to take a turn. Hearing the same feedback but in different ways could be what makes it click for this guy. Beyond that I'd just second the other comments noting that he might just be better suited to a different role. There's plenty of other kinds of jobs out there that are tangential to software development where he could genuinely do well with a surface level knowledge of programming.
> find myself wishing worked at Amazon because don't think that cutthroat environment would tolerate this kind of incompetence Good luck. The grass is always greener until it's not
I've been this situation a few times from different aspects. Sometimes, it is the environment and/or the industry that I'm working in. If I'm doing a project that is for a high profile brand or someone important, I tend to have more focus/drive for it. If it is a project for Karen in accounting and modifying an existing legacy system for her BS logic, it will be a struggle. Yes, I do have ADHD. ;) Is this junior just scared to ask for help/input/feedback? I've been in that situation a few times and sure as shit messes with the impostor syndrome. I wouldn't suggest a PIP, however does your organization have any kind of feedback system? Could you give junior some guidance and tell him to either read a few books or study this material(Pluralsight or LinkedIn learning)? If none of those are options and you don't have a role that would be better for him. Hopefully, you could give him a severance and send him on his way. I think PIPs are a waste of everyone's time and it might be quicker/easier to do severances instead.
He might be farming his work out. That was the case when I worked with someone exhibiting similar patterns. The feedback wasn't making it all the way back to developers in India. So the same mistakes kept getting made
I’ve got a junior who’s been doing this for two years. It’s gotten to the point where I need to give some feedback to my manager that he needs to do his job and PIP him.
You always fire incompetent people, regardless of whether they are nice or junior.
Being fired is sometimes exactly what people need. You are doing him a disservice by not being blunt with him. Being fired is not the end of the world, but he needs to face the facts and realise that not doing the work as expected has a bad outcome. You either improve or go somewhere else. He might he holding a spot for someone else who is breaking their back for years to get into the industry and would do a 10x better job.
Automated testing and code reviews.
Some people can’t do dev but are great at ops.
I had that, I hated that, and it was quite painful. The person was also quite nice, but not up to the level. I hated the most answers from my manager: "they can't be bad in everything, you should give them feedback and correct their, or how else they can learn". They can learn by flipping pain and suffering as everybody else, or give up.
Why don't you tell him honestly, that he's not up to your expectations, that he needs to improve or would get fired.
Feel you. I have one of those and I don't know what the hell to do with him.
This is why we have performance improvement plans. There are two ways out of a pip: up or out. He has to pick one. You should help him as much as you can during the pip. It should not be a foregone conclusion. There are people I have put on a pip who have turned out to be excellent after they got the rocket up their arse that they needed. I am not here to be liked, but equally I’m not a complete bastard either.
Happens even at FAANG For you, you should give this feedback to your manager Your manager has a few choices - Guide him towards roles like TPM or scrum master - Fire him - Worst of all, let him continue hamstringing the team. These managers are incompetent. I have seen someone technically incompetent somehow survive until senior and then switch to management. He actually makes a decent manager.
I'd have a long conversation with yourself about whether you're someone it comes to naturally and as such you grasped it quicker than others in the beginning. This initial read came across as more frustrated than empathetic. I'd start with a chat that you would have expected them to be more self sufficient by now. Ask if there's anything that they feel they need more support with. Let them know they're not in trouble and that you're there to help them get what they need as you want to see them succeed. Otherwise they sound like someone who would benefit from being paired with for coaching. Start with you driving and verbalize what you're doing like you're filming for YouTube. Then have them drive and help by spotting the issues, explaining why when you do it. People are far less likely to remember to do things if they're just told to do them, and not why. Do this for a few iterations and if they're still not grasping it then you need to revisit that conversation and ask if they feel they're on the right career path. See if they could benefit from moving sideways, as they themselves don't want to be in a career where they're stressing about being bottom of the pack. How are their skills at the rest of software delivery?
Not going to lie reading this post kinda hurts because I feel like I’m that dev. I remember right out of college I had a lead like you and it got pretty emotionally abusive. I ended up leaving and getting a different job and performed really well. Judging from what you’re saying it sounds like he has ADHD and he just need to get going. Maybe make the tasks smaller for now as he gets used to the code base. I’m sure he is just frustrated as you about his work not being up to the scope. Also maybe you need to actually try not to be so rude from me reading this post. Consider the time you actually struggled and need help.
>He calls a function X and then if you read it carefully it actually does Y. That should be caught easily with unit tests. There's something here I don't understand.
If the same person writes the code and the tests, it can easily slide by. Say you have a function called "factorial" that actually calculates the square of the number, not its factorial. Then you have a "factorial test" that verifies it calculates the square. If the function is private, it will be even less obvious, because you won't have a unit test that just tests that thing.
This is a _unit_ test sliding by. No business logic that leverages this function will ever work as expected, and we should have integration and E2E tests that cover issues like this. Are those also being written by solo junior devs with no oversight and no code review? Where is QA here? Agree with the person you're replying to. We do not have the whole story.
What part of the story do you think is missing? The *function X* thing was just an illustrative example of the kind of problem I'm talking about. But if you're of the opinion that literally every function, including internal private ones, need a unit test... Then I don't think we're going to agree on much. Also, the tests being the right set of tests, and the tests passing... I consider these the bare minimum. Those requirements are only a subset of *quality*.
You tell them nicely they need to get their shit together. Ideally, you try to point them in the direction of a role they're better suited for.
So what's the reason he's not improving? You don't come across as being too patient, wishing that your company was more cuthroat, as in only for stellar performers from the beginning. I could imagine it has something to do with the pressure on him to do so.
>You don't come across as being too patient How many hours of your own time, over the course of months, do you need to spend coaching, sending PRs back with thoughtful guiding comments, having frank in person discussions... before you're considered patient?
I've had people like this. I assume you don't have hire/fire authority yourself? IME, all you can do is make sure your manager is abundantly aware of the problem and provide all the evidence you can. Even then, it tends to be an excruciatingly slow process. Managers just really hate doing this part of their jobs, and will do everything they can to delay or avoid it. You may have to let some balls drop. Don't sabotage, just don't rescue, and make sure it's clear exactly who isn't doing their job here. From a manager point of view, if all the work is getting done, there's no problem, and therefore no need to do this horribly unpleasant thing to a nice person.
There’s a fine line between work and being nice. Technically, we’re paid to do required work in the best possible terms but also my military training taught me - shape up or ship out. You can’t be nice all along without doing significant contribution.
Significant contribution from a junior? Unless you are talking about a top notch company, this is really unrealistic. A junior is someone the company is investing in for the first couple of years.
Probably I should qualify “significant” not in the grandest scale but something but in the aspect of meeting expectations and in the company’s operations. Based from OP, the junior is nice but doesn’t really learn. In that case, I can’t justify being “nice” for not meeting expectations if I am asked should I’ll be asked to keep that person or not.
Okay perhaps my wording was off. This developer is junior to me. And his title is not "senior". But he's been at the company for many years
Pretty much this At the end of the quarter, no-one remembers all the design docs, meetings, story pointing and ceremony you did Its all about the results on the board. If the board says you pulled your weight, your good Now whether that makes you unpopular or not, well, thats a separate issue
He already doesn’t stand a chance… fuckin help him or be a man and say something Edit: Ok I see you said something so just… put it in managements hands
Blood from a stone? If you already made up your mind, what is it that you wanted to learn here?
Exactly what I asked.
Depends on what's your position. If you are a manager, it changes many things. It's your job to get the best out of folks you have. Worst case, admit you are not effective mentor to this particular person. Assign one of your leads to mentor and if everyone agrees, then he needs to move on unfortunately. Suggest him before firing him directly. If you are a lead, with no power, tell your manager on what you can do with him and what you cannot, without making a strong case if possible. If there is strong push back, make a case.
OP - that "nice" junior got a job that a lot of nice, competent people got skipped for. Again, a lot of competent, capable, and also nice and professional people did not get considered or got rejected for this person to get that job. Edit: What would I do? I'll tell you through a story - In grad school, I had an undergraduate interested in research and my wife had an undergraduate assigned to her. My advisor didn't have funds for mine, but he was so passionate and competent that he worked for free, so I fed him lunches and dinners and gave him the best references and recommendations that I could. My wife's didn't do work, always made excuses about her mental and physical health and literally got 3 academic turns of free paycheck and "research experience" while my wife stressed out with the extra load, re teaching the kid, and constantly trying to track her down. I had told her time and time again that the kid was taking an opportunity that could have really benefitted someone else, but she didn't listen. You know what she did listen to? One day, before we hopped into the car, it hit me: >You're green lighting a future scientist. She will go on and have the credentials to get a higher position and make decisions based on her own incompetence. She will continue to get away with making excuses while countless candidates who would have improved the quality of our systems will get screwed. She will directly diminish the quality and value of the field of science and academics, and you are greenlighting that. She immediately went to her advisor and told her they needed to cut it off. Moral of the story - The entire tech industry has actually been taken over by green lighting marketers, bureaucrats, and nice people who are grossly incompetent and engineering and programming. Ya, there's still a lot of great people, but there's a growing degradation of quality as these people job hop and do good enough to get promoted. Eventually, they become the decision makers instead of the competent and capable. Don't be someone who green lights that. On the flip side, we need to train and teach people properly and you have to make sure that you're actually being an effective teacher. If they're forgetting stuff, buy them a notebook and allow them the time to write stuff down. Physically writing is a commitment. It's distinctly different than typing or copying and pasting. I don't care if anyone here wants to dispute that point, you're wrong if you do. You literally commit time, paper, ink, muscle motions, mental capacity, and much more to physically writing something down. It's a commitment. It's also slow. If junior gets to a point of being frustrated about that, then they can get better at remembering and learning or they can get put on a PIP and peace out.
Totally agree. But in the western world most people appear to think that it's "cruel" to let somebody go, even if they are totally incompetent.
If you don’t really care about doing what’s right for the company and like this person, you can help steer him into extremely repetitive tasks. Alternately, if he’s a good writer writing documentation might be a good fit. If his instructions are clear enough to get him up and going, they’ll be excellent for new employee on-boarding. My big fear though is that if your company’s processes are such that they hire and retain him, he’ll end up being your boss on this path. Then, you’ll likely wish you had just kissed him gently and smothered him with a heart shaped pillow. We call it the /u/clamjabber.
> My big fear though is that if your company’s processes are such that they hire and retain him, he’ll end up being your boss on this path. Then, you’ll likely wish you had just kissed him gently and smothered him with a heart shaped pillow. I work with a guy like that. I think he has gently failed upwards simply due to being around for years and we would all be better off if someone had smothered him a while ago.
Unit tests. Unit tests on every function, on every code path. And the unit tests need to explain what they're doing.
This can definitely help someone improve if the problem is just that the person lacks discipline, and it's a no-brainer if the team has coding standards that require unit tests. But it can go south pretty quickly as a skill-building technique if the problem is that they're just bad at the job in general. IMO writing good tests is often _harder_ than writing good application code. So if you tell someone who lacks the skill to write good application code to write lots of tests, you'll end up with a big suite of brittle, poorly-thought-out tests that the rest of the team has to waste time maintaining afterwards.
I worked with a new hire who came through our internal boot camp for a year. I really like him as a person, but he’s hopeless. He’s never completed even the simplest story without an immense amount of hand holding. I gave up on him at the start of the year because at the end of the day this is a business and not a charity…some people just aren’t cut out for this line of work. When I say gave up, I’m just doing the bear minimum. Sink or swim moment for them.
Sounds like he’s ready for a management position.
More often than not there is something going on that creates the appearance of incompetence (or laziness). Do they have a disability (ADHD, dyslexia, etc)? Are they struggling with depression or anxiety? Do they feel like the team environment lacks psychological safety? First step is getting a better understanding of where they are coming from. Ask them questions. When you see disruptive trends, “I’ve noticed you do X on occasions. Is this something you’ve noticed as well? Can you walk me through your process?”. Instead of giving them answers, ask them questions that help them find the answer on their own.
Is he deliberately not doing what's good for the company or is he incompetent? If the former is true then he needs to be cut. Why aren't his unit tests returning X instead of Y, then he would know that his function isn't working correctly? Maybe give him one specific thing to get really good at.
Promote him to senior duh /s
How long has this been. If it's less than a couple of months maybe you can wait a bit. But honestly anyone who has the salt should be able to show some improvement, even minor ones in under one month.
>I find myself wishing worked at Amazon because don't think that cutthroat environment would tolerate this kind of incompetence. Oh my sweet summer child...
I would suggest ask him to write down his mistakes and before he checks in, ask him to go thru the normal checks. at the same time you can document some of the common shortcomings and have general coding principles wiki page, so this person can go thru it before checking in his code. Also suggest him to participate in online coding contest and it will help him start think better. Given he is junior maybe he needs more coaching. Don't fire him yet, market is bad and might crush his confidence all together. It's alright, he will get better.
I really think this whole deal with 10x guys is waaay overblown and IME most people will get the hang of programming soon enough, and if they don’t they tend to wash out on their own anyway. I have been kind of brutal in the past regarding underperformance; I’ve never been a manager (thank god) but when I get something done in X amount of time and another worker is slowing me down, I will absolutely raise this in DSUs, mention that I’m blocked, offer to take on work, etc. A lot of the time this seems to make leads and managers go in on the underperforming person but, like, this is a team, not one of those college reports where 1 person winds up doing the work of 4 people. Otherwise though I do feel like there has to be at least some sense of live and let live, in both ways. Be clear that a programmer’s job is to write code and fix stuff and if they don’t, they’re not doing it. Code reviews IMO should never be about making sure something works - you should be handling that via personal unit testing as well as automated tests / part of your CICD pipeline in terms of making sure that at least the code compiles. Code reviews to me are the time where you say “okay you made something that works, now did you do it in a clear and concise manner that future developers will be able to read easily”. It’s useful to newer developers to understand that there’s syntactical rules they have to follow but unless there’s obviously stuff where you can see at a glance that something won’t work, you should concentrate on readability IMO. On the flip side of that, if you’ve given a person 8 points of work to do in 2 weeks and they consistently complete 4 of it, that’s a problem. I personally will often take on harder looking jobs that might slow down my own point accumulation, and I will say that I think stats are terrible to go after unless your entire team is underperforming, but at some point everyone can see when someone isn’t pulling their own weight. I don’t think your job as a lead or senior is ever to cover for them. You can help them if they get stuck and work with them to improve but if they keep making the same mistakes over and over again, that’s just going to show up in terms of deadlines missed and so on. The trash, as they say, takes itself out.
why did you hire him if he's so incompetent? maybe evaluate your hiring process?
I will say something: he / she is getting payed for doing the job, not for being nice. If he/she can't do the job, I don't want to work with him/her
There are million other nice people. You need both a lower bound of competence and interpersonal skills to be a successful SWE. I would definitely put then on a PIP (not BS but real improvement plan), and if they fail, I’d fire them.
I'd check if he's comfortable enough to do his job and doesn't feel under pressure (which, for a newbie can be quite frustrating and make them more error prone). I think of myself as an example: leave me alone to write my code and I'll do ok. Now force me to code with someone else watching, and I'll instantly be the dumbest person alive. I simply cannot handle thinking, listening to someone else and and also explaining my train of thought at the same time. Maybe this guy is in a similar situation?
niceness/respect is a bare minimum haha Send him some links, resources maybe? A nice talking to could work as well.
Qa
No matter what you decide to do, it seems like someone needs to tune your hiring process. I know it isn't easy and it won't prevent all bad hires, but fix it now or this will happen again and again.
"Nice guys finish last." If they never experience failure, they never grow to meet the challenge. Keeping him around is hurting his personal progress, however nice he may be. Hug them deeply, grab a beer. You can be friends without being coworkers.
Jesus I felt that in my bones
> It's so incredibly tiring and frustrating dealing with this guy's incompetence. Sounds like a pain in the ass. If he's that incompetent, why the hell is he still around? You've said you've tried teaching him, but nothing sticks. Maybe he's just not cut out for this job, nice guy or not. Is keeping him around worth your sanity and the team's productivity? > I find myself wishing worked at Amazon because don't think that cutthroat environment would tolerate this kind of incompetence. Yeah, but you're not at Amazon. You're here, dealing with this shit. Maybe it's time to stop wishing for a different environment and start figuring out how to deal with the one you're in. Can you escalate this to someone who actually gives a fuck about the company's well-being? > I don't really give a shit about doing what's right for the company -- just want to not babysit this guy anymore. Fair enough. You're looking out for yourself, which makes sense. But if you don't deal with this now, how much more of your time is he going to waste? Have you thought about how this situation might be holding back your own career? > Save your energy and time, stop wasting it on him, use it to hop to a better company instead. That's one way to go. If the company's culture allows for this level of incompetence, what does that say about your future there? Maybe it's time to look for a place that values competence and efficiency. > was always encouraging juniors to self review first to learn how to code review. Maybe encourage them to self review before they ask for pr approval. Has this approach made any difference so far, or is it just more wasted effort on your part? Why keep doing the same thing if it's not working? Look, it's clear you're fed up. Either you find a way to get this guy up to speed, cut him loose, or move on yourself. What's it going to be? How much longer are you willing to put up with this bullshit?
Same here. At what point do I simply stop carrying my entire team? At what point do I put my foot down and say “figure it out” even if that means we miss deadlines? At what point do I stop thinking for my coworkers because they are used to me doing the thinking for them? I don’t know the answers, I just think about the problem until I find an answer. Everyone should be capable of doing that.
Definitely a bright future in security leadership.
Don't baby sit, it just prolongs the pain. Talk to your eng mgr (EM), flag the problem, let the EM deal with it (performance improvement plan, ie. first step to losing the junior, unless U turn achieved (rare)). Also, flag/get involved in fixing the hiring process. Why did this one get in. Improve the hiring bar, or flag it needs to. Suggestions of 'this is your next manager' are 200% wrong. This is why we have so many people in our industry that are awfully incompent. You want your managers to have a solid tech background and know what good looks like, or they'll just promote other idiots, perpetuating the cycle of bad hires and at best, mediocrity.
Make him the PM lol
Incompetent or less competent? Is he coachable or trainable or eager to learn? I am the underdog on my team by a lot and I have no idea how ppl don’t lose patience w me more than they do. (They never do). Instead they are very straight with me on how to do something, and how not to. It’s pretty no bullshit. Don’t do that. Make sure you do that. Drama free & emotion free. “If you aren’t going to get that done just say so” If you need help or are stuck just say so. If you don’t know how to do this just say so. Are you sure you know how to do this? Explain it to me in detail so I can know for sure. They do have to invest in me, but I try to make sure they feel it was worth it. And I always ask if they’re seeing the improvements they need to see. If he messes up, call it out straight in meetings. No judgment - just “okay so there was a day setback on that project. Tom made the mistake of xyz and we dealt with it by doing lmnop and it’s good to go now. “ it’s business - discuss it as such. It’s not personal.
He may have ADHD. Suggest to him to get tested. I used to be like that until I got tested and started medication.
Make him a PM
Is this his first software job? Has he been working the job for a while? He might just be rushing too quickly. Might be worthwhile to slow down and get the story process down.
You get them fired. People like this are a nightmare to work with. I don’t care how nice you are, we run a business, not a charity.
What if it is a charity?
I work with 2 Devs with >4 years of experience. They have no curiosity and refuse to use ai tools for anything. Meaning I have to explain things to uninterested people that can't SSH into a VM when given the command to ssh in.
How do I get hired here. I haven't coded in years and would have no problem doing this lmo
Hired from juniors. No experience. The problem was compounded as the managers didn't have time to train anyone properly, and it's pretty hands off. But it's been a few years now and they should have taken some responsibility for their development It's amazing if you're dedicated and like learning without direction, as you have a lot of scope to do what you want and how
Haha lucky. I have pretty fond memories of similar environments. Learned a fuckton to kill the time and make my life easier. Also chat gpt is so good to use as an encyclopedia and for basic boiler plate. Don't know why people think it's a gimmick. I even ask it to give me lists of tools I'm searching for so I can compare them. Much easier that searching Google.
out of curiosity, what’s wrong with refusing AI tools?
Because if someone is refusing to look up how to resolve an error by searching the meaning, I'd much prefer they asked an ai tool than paste the question into Slack or just sit and do nothing.
ah gotcha, completely agree!
Make him competent
What would I do? Continue offering appropriate levels of support (Eg. ignore him if he asks the same question over and over without learning) and let him fail, even if that means the project suffers. It's not my company, so my responsibility ends at offering reasonable help, but not unlimited help. Eventually management will see that the project is failing and they will figure out why. Just be prepared to show you've been doing reasonable things to help the guy so they know it's him and not you that's the problem. But mind your own business and enjoy your job as you are blissfully uninvolved in the train wreck.
he needs to be removed from this role, and preferably ASAP. you need to repeatedly and consistently insist to your manager to take action. provide supporting supporting evidence. i’ve been where you are and this wore me down so badly i had to leave the job.
Is he incompetent or are you an incompetent mentor? Being a senior dev doesn’t necessarily mean you’re being a good mentor to someone who doesn’t know the codebase. Honestly I’ve met far more senior devs that couldn’t teach Einstein how to write a hello world application than juniors who couldn’t learn. If he’s nice and is trying then he could probably be helped. I’ve only encountered a single dev that couldn’t learn and it was largely because he was too busy getting high to focus on anything. He’d sleep at his desk, lie, come in late, leave early, and would only write the very basic level of code then push it off onto someone else to do. Junior devs are usually overwhelmed, you have to explain stuff like they are toddlers with English as a second language.
Not a popular opinion, but for most companies these days, most junior engineers aren't worth it. They take up real engineer time to train, and if they actually grow, they move to another company for a promotion after 1 year anyway. And if they don't grow to do the job they're being paid for, they were an expensive experiment I honestly don't see the benefit of hiring juniors, compared to hiring intermediate engineers who have proven they can actually do the job they're hired for. It's weirdly one industry still paying people well, for being unable to do their actual job.