I've met maybe 1-2 people in my whole life who were clearly beneficial 'A' from the get go. There's also a weird 'A' that tries very hard but causes more pain than inspiration. Meaning, they're clearly smart but think that's all that's necessary to be useful. I once worked with an intern from MIT who came in and immediately submitted large PRs everyday that improved the algorithmic complexity for a bunch of functions…
As someone that's a senior at a large corp, I absolutely do not want someone making the codebase more complex with the only benefit being being that it's now barely measurably faster. Especially when there are probably better things to be spending time on (spoiler, there are). Unless you're knocking like 20% off a very impactful metric, or addressing a looming scaling probably, go find something better to do than mak…
Hey, n00b, we didn't hire you to complete tasks
71–80 of 139 posts
Re: Hey, n00b, we didn't hire you to complete tasks
#72I have received a truck load of positive feedback (but of course some negative too) in my career and I've always felt somewhat undeserving of it. It's not even imposter syndrome, I just never felt that, for example, "attention to detail" was really something I was good at, but I got that one over and over. In fact, I've often felt I am more than a bit hasty. I always edit my comments after posting them to fix something minor. Sometimes I am so hasty, that I force push the same branch like four or five times in a row before I actually have things in order.
But I think I get it now. Attention to detail is what it looks like. I probably pay attention to fewer details than average, but through experience I've honed a pretty good sense for which ones are most important. The things I tend to screw up and need to amend quickly are usually mundane things that in some cases should possibly even just be automated. But even when I do realize shortly after pushing that something is full-on not gonna work, it's not that I sat there and did a careful sweep over all of the important details; my undiagnosed executive dysfunction would never allow for that. It was rather that I double checked just a few details as a sanity check, running things through mental models. And I think having a very good sense for what details you need to scrutinize is exactly what looks like careful attention to detail. It's nothing special, just experience; kind of like when they analyze the gaze of experienced drivers vs inexperienced and can see that the experienced drivers quickly fixate on important details whereas inexperienced drivers are less focused and scan more broadly.
What does that have to do with this article at all? Well, when I read the C list I felt a little nervous. I mean I've broken production a fair few times. Have I ever failed to adequately communicate what I'm working on? Not often but certainly too many times. Generally I am also just mediocre at best at the parts of the job that aren't writing code. But, then when I read the A list, it just felt like reading a description of how I like to work. And I'm not special in that regard at all, but it's at least easier to understand what types of concrete behaviors might set us apart from less senior engineers, aside from more gray hairs and remembering using Windows 98, whereas most peer and manager feedback often feels too detached from the actual behaviors; because the feedback is what people perceive. And I am realizing it's actually rather important to understand the gap between how you feel inside about yourself and how people perceive you, if you really want to earnestly accept feedback, both negative and positive.
I fully realize there is no non-conceited way to format this comment. "Oh, woe is me. I receive too much positive feedback that I feel like I didn't really earn." But, there really is a uniquely bad feeling from getting compliments you don't feel you have earned; what do you say, "But you're wrong! I suck!"
Re: Hey, n00b, we didn't hire you to complete tasks
#73> You uncover a better design and submit a string of diffs not only implementing the task but simplifying other parts of the code too. Bonus points for doing this before you implement (make the hard change easy then make the easy change). The last part of this really stands out. A high performer understands that software is malleable. However, the way you shape it, when things change, and how much is changed at one t…
Re: Hey, n00b, we didn't hire you to complete tasks
#74Re: Hey, n00b, we didn't hire you to complete tasks
#75Earlier quoted context omitted.
As someone that's a senior at a large corp, I absolutely do not want someone making the codebase more complex with the only benefit being being that it's now barely measurably faster. Especially when there are probably better things to be spending time on (spoiler, there are). Unless you're knocking like 20% off a very impactful metric, or addressing a looming scaling probably, go find something better to do than mak…
Agreed. Hardware is almost always cheaper than engineering time, until it isn't, and that's when you should spend the time on targeted optimizations.
Re: Hey, n00b, we didn't hire you to complete tasks
#76Re: Hey, n00b, we didn't hire you to complete tasks
#77So much of this is written with an air of superiority over the noob. Indicates a bit of an ego problem. Yes, the noobs are noobs, but the goal isn't to exercise your status over them. Or even to waste that much time trying to categorize between A, B, C. The goal should be to boost everybody's productivity instead of treating them like a game.
Re: Hey, n00b, we didn't hire you to complete tasks
#78> You uncover a better design and submit a string of diffs not only implementing the task but simplifying other parts of the code too. Bonus points for doing this before you implement (make the hard change easy then make the easy change). The last part of this really stands out. A high performer understands that software is malleable. However, the way you shape it, when things change, and how much is changed at one t…
As a senior you can get into a bad habit of being scared to make changes. It happens after enough experience with enough codebases. It’s good to not just go change things for the sake of it — it’s equally as important to ask yourself if you’ve gone too far in the other direction and to always remain curious and critical of yourself.
Re: Hey, n00b, we didn't hire you to complete tasks
#79"Brutal as it seems, we’d like to expend as little effort as possible on people who aren’t going to make it. It’s your job to get in the category you want to be in and send us the signals that tell us that’s where you belong. " And this is what a complete lack of leadership looks like. "We are paying your salary now as the option premium on the engineer you are going to become. If we play this game right, we’ll have…
Re: Hey, n00b, we didn't hire you to complete tasks
#80These are primarily driven by skills of the junior. Though you should expect they have none.
What sort of comes out between the lines is the attitude of the person, and I think this matters most and should be framed directly.
You want someone curious that will peek beyond what you asked. Someone proactive that will not sit and wait for an assignment. Someone meticulous that will not self-satisfy of quick-and-dirty.
When said like this, the article content resonates as the consequences rather than objectives.