Live data from Hacker News

Hey, n00b, we didn't hire you to complete tasks

newsletter.kentbeck.com

61–70 of 139 posts

Re: Hey, n00b, we didn't hire you to complete tasks

#61

For a B level: > * You did not cause other people unreasonable amounts of work.* I would be careful with this one. As the examples listed after, such as an on-call incident or extra review of code isn’t necessarily on the n00b. Maybe I’m biased being only 4 years into my career but engagement on stuff you did wrong or even points on what you can do better are extremely valuable. From my standpoint, screwing up isn’t…

The article sounds like a company with toxic blame culture. If critical aerospace can be no-blame, software can too. Sure, try not to be useless, but if the company doesn’t have guardrails that’s not on them. If an intern deletes something: why did they have access in the first place? Why wasn’t there a backup?

This sort of process over responsibility culture is one way to drive incidents to zero, but it's also a way to wrap yourself in so much process and bureaucracy that you move at the speed of aerospace.

Of course, many companies are far away from the pareto frontier, but there are often tradeoffs for safety and people have to use judgement about when to go slow and when they can go fast.

Re: Hey, n00b, we didn't hire you to complete tasks

#62

Earlier quoted context omitted.

Not to sound soulless but why would you want to invest on the C’s? Unless we have no options I don’t see why so that. I’ve had to deal with people like that and it’s a tar pit.

One thing is that the A's are watching how you treat the C's. They might not have a good gauge of the culture from their own experience because they take care of themselves.

Yes, but the takeaway is the opposite if what you're implying. Working with C's is draining for everyone and a drag on morale.

Re: Hey, n00b, we didn't hire you to complete tasks

#63

For a B level: > * You did not cause other people unreasonable amounts of work.* I would be careful with this one. As the examples listed after, such as an on-call incident or extra review of code isn’t necessarily on the n00b. Maybe I’m biased being only 4 years into my career but engagement on stuff you did wrong or even points on what you can do better are extremely valuable. From my standpoint, screwing up isn’t…

A lot of this article reads like an egotistical toxic senior dev. I agree with your take. I tend to agree that "not generating unreasonable work" is not a good signal. If I do 0 work I can fall in the "not generating unreasonable work" category - thats not a good signal. Also the "Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them." sug…

Yeah, I know Kent is a very respected developer with a long and celebrated career. But I did not like the attitude of this article at all.

I’m a principal engineer. I have an obligation to less experienced engineers I work with to help develop them as engineers and help ensure they go on to have great careers. No part of that involves shaming them, assigning letters of talent to them, or browbeating them.

I feel like I’d have heard about it by now if Kent was a raging asshole, and I haven’t heard that. So I’m guessing he had some idea in mind when he wrote this that just isn’t coming across correctly. But… I would definitely take this article down and spend some time re-working it if I were the author.

Re: Hey, n00b, we didn't hire you to complete tasks

#64
post #34

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…

That person doesn’t sound like an A at all in my opinion.

Re: Hey, n00b, we didn't hire you to complete tasks

#65
This kind of process oriented thinking eventually hits a scaling limit. Look at Meta as they struggle to scale their way out of basic problems that builder oriented labs had little trouble with. Zuckerberg bet on open weights but his company doesn't own GLM-5.2.

>If I am trying to sway others, I would say that an org that has only known inefficiency is ill prepared for the inevitable competition and/or belt tightening, but really, it is the more personal pain of seeing a 5% GPU utilization number in production. I am offended by it. — John Carmack’s resignation letter from Meta (December 16, 2022)

It's definitely possible to have a builder culture in a large company, but you need to insulate them from the rest of the org and have protective management. Nobody who happens upon a breakthrough is expecting it, all startups expect a breakthrough (their owners are crazy). Don't create a pattern of "stealing" tech from your employees; "tax" them instead. If this is correct then I'd expect to see breakthroughs out of valve in the next decade or 2.

Re: Hey, n00b, we didn't hire you to complete tasks

#68
post #59

This makes complete sense in an environment where people transition from noob to senior engineer within the same company. It makes less sense in an era when tenure is better measured in months than years. It makes even less sense in an era of LLMs. One area where it might be relevant is the military. People are more likely to stay for longer (unvalidated assumption) and the same personnel jacket follows them if they…

> It makes even less sense in an era of LLMs. I would argue that out makes even more sense in the era of LLMs. LLM shaped tasks are tasks that we would hand out to junior engineers. Now, I can implement one of these tasks in 1hr instead of waiting for a junior engineer to finish this in 1-3 days. This means the equation for investing in junior engineers has shifted towards disfavoring investment.

This is my own personal experience as a senior engineer.

I hired my first ever intern for myself this past week for a personal. Rather than expecting someone who is experienced to knock out tasks or whatever & try to justify the expense, Intern and I just check in once a day about whatever feels like most important, and each do our thing. We chat as needed. I told Intern we’ll work on whatever, just making sure that they will have something tangible and targeted to show at the end of the summer. No ticket tracking or Slack or anything. Just texting, video chats, and the occasional email. I pay someone to listen to me rant long enough to get to the point, giving me focus that’s hard to find on my own, intern works on targeted things for a day at a time, and we’re just plodding along. It’s great and I find the process to be extremely refreshing.

When I’m trying to brainstorm with Claude Code or pick-an-AI-tool, I find the process frustrating and draining. The results I get from trying to do everything myself with a robo-junior are mediocre and uninspiring.

I didn’t even interview intern. I just reached out directly on LinkedIn and offered a summer internship. I figured anyone with a half decent profile will be smart enough to follow along and offer ideas of their own. Basically my thought was if I offer ever and expect nothing, I’ll take all the pressure off, and just let them work. Ask me again in a months if this was a good idea or not.

I think working with newbs is fantastic, and I plan to do a lot more of it.

Re: Hey, n00b, we didn't hire you to complete tasks

#69
post #34

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…

I've seen rewrites at startups that were slower and less stable than what we had before and everyone cheered it on like clapping seals. This stuff is rife no matter the size of the company.

At least at large orgs there's hopefully someone able to measure it. The smaller you go it's silos all the way down.

Re: Hey, n00b, we didn't hire you to complete tasks

#70
post #51

Earlier quoted context omitted.

Related, but the best quality to have in a startup is knowing when and what corners to cut instead of going on these side quests.

I used to think this but you only know which were the right corners to cut after the fact. And most things are not obviously right or obviously wrong, instead it’s a slow zombie death by a thousand fuzzy signals. And the management tier of the startup will too easily color the signal by the flavor they want to see. My latest take on this matter is to separate speed as in fast from quick. Quick is the thing you want a…

[deleted]
Post reply on HN