Hope I'm not late with this one.

Them: Root, you take too long to get tickets out. You only have a few simple ones. You really need to rebuild your reputation.

Also them: Hey, could you revisit this ticket? Could you help ____ with this other ticket? Hey Root, how do you do this? Root, someone had a suggestion on one of your tickets; could you implement that by EoD? Hey Root, i didn't read your ticket notes; how do you test it? Hey, could you revisit this ticket for the fourth time and remove some whitespace? Hey Root, someone has non-blocking code review comments you need to address before we can release the ticket. Hey Root, we want to expand that ticket scope by 5-6 times; still labeled a trivial feature though.

Also them: Super easy ticket for you. Make sure you talk with teams A, B, C, D, E and get their input on the ticket, talk with ____ and ____ and ____ about it, find a solution that makes them all happy and solves the problem too, then be sure to demo it with everyone afterward. Super easy; shouldn't take you more than a couple days. Oh, and half of them are on vacation.

Also them: Hey, that high-priority ticket you finished months ago that we ignored? Yeah, you need to rewrite it by tomorrow. Also, you need to demo it with our guy in India, who's also on vacation. Yes, tomorrow is the last day. (The next day:) You rewrote it, but weren't able to schedule the demo? Now you've missed the release! It's even later! This reflects very poorly on you.

Also them: Perfect is the enemy of good; be more like the seniors who release partially-broken code quickly.

Also them: Here's an non-trivial extreme edgecase you might not have covered. Oh, it would have taken too much time and that's why you didn't do it? Jeez, how can you release such incomplete code?

Also them: Yeah, that ticket sat in code review for five months because we didn't know it was high-priority, despite you telling us. It's still kinda your fault, though.

Also them: You need to analyze traffic data to find patterns and figure out why this problem is happening. I know you pushed the fix for it 8 months ago, and I said it was really solid, but the code is too complex so I won't release it. Yeah I know it's just a debounce with status polling and retrying. Too complex for me to understand. Figure out what the problem is, see if another company has this same problem, and how they fixed it.

-------------

Yep. I'm so terrible for not getting these tickets out, like wow. Worst dev ever. Much shame.

LF work, PST.

I have a junior who really drives me up a wall. He's been a junior for a couple of years now (since he started as an intern here).

He always looks for the quickest, cheapest, easiest solution he can possibly think of to all his tickets. Most of it pretty much just involves copy/pasting code that has similar functionality from elsewhere in the application, tweaking some variable names and calling it a day. And I mean, I'm not knocking copy/paste solutions at all, because that's a perfectly valid way of learning certain things, provided that one actually analyzes the code they are cloning, and actually modifies it in a way that solves the problem, and can potentially extend the ability to reuse the original code. This is rarely the case with this guy.

I've tried to gently encourage this person to take their time with things, and really put some thought into design with his solutions instead of rushing to finish; because ultimately all the time he spends on reworks could have been spent on doing it right the first time. Problem is, this guy is very stubborn, and gets very defensive when any sort of insinuation is made that he needs to improve on something. My advice to actually spend time analyzing how an interface was used, or how an extension method can be further extended before trying to brute-force your way through the problem seems to fall on deaf ears.

I always like to include my juniors on my pull requests; even though I pretty much have all final say in what gets merged, I like to encourage not only all devs be given thoughtful, constructive criticism, regardless of "rank" but also give them the opportunity to see how others write code and learn by asking questions, and analyzing why I approached the problem the way I did. It seems like this dev consistently uses this opportunity to get in as many public digs as he can on my work by going for the low-hanging fruit: "whitespace", "add comments, this code isn't self-documenting", and "an if/else here is more readable and consistent with this file than a ternary statement". Like dude, c'mon. Can you at least analyze the logic and see if it's sound? or perhaps offer a better way of doing something, or ask if the way I did something really makes sense?

Mid-Year reviews are due this week; I'm really struggling to find any way to document any sort of progress he's made. Once in a great while, he does surprise me and prove that he's capable of figuring out how something works and manage to use the mechanisms properly to solve a problem. At the very least he's productive (in terms of always working on assigned work). And because of this, he's likely safe from losing his job because the company considers him cheap labor. He is very underpaid, but also very under-qualified.

He's my most problematic junior; worst part is, he only has a job because of me: I wanted to give the benefit of the doubt when my boss asked me if we should extend an offer, as I thought it was only fair to give the opportunity to grow and prove himself like I was given. But I'm also starting to toe the line of being a good mentor by giving opportunities to learn, and falling behind on work because I could have just done it myself in a fraction of the time.

I hate managing people. I miss the days of code + spotify for 10 hours a day then going home.