Hacker News Reader

One thing I found that helps in some cases, that I wish was said (and actually practiced) when I was a junior developer, is, “my main job is to help you get comfortable with everything and help you be successful. Everything else about my job is basically just filler for whenever you don’t need my direct attention. Never ever feel like you’re inconveniencing me because helping you is my job.”

> Everything else about my job is basically just filler for whenever you don’t need my direct attention

That might be taking it a bit too far?

It’s not, if your job is to onboard a new engineer. Those first few months make all the difference. If the “other parts” of your job prevent you from maximally optimizing the productivity of your new coworker, the compounding negative returns on that onboarding engineers time is incredibly expensive.

Unlike almost anything else you could be working on, turning someone from nonproductive to productive, or more productive, has compounding effects that can quickly help or hinder the longer term objectives

As someone with people who report to me, my #1 job is to make sure they’re effective, happy, productive. Empowering them generates more productivity than me quietly doing stuff myself.

If you have people who report to you and your main job is enabling them, you’re a manager not an engineer. Which is fine, but also it’s an important distinction to make.

My #1 job takes maybe 30% of my time. Be careful with semantics fixation.

> Don’t get caught up in semantics

What does that mean?

Labelling someone “engineer” or “manager” is not really useful. So why go out on a perilous precipice of doing so, especially when one lacks almost all the details necessary to make an informed assessment?

My previous contract ended abruptly but then a month later they needed me again because their current onshore offshore team was very large and growing by the day but incapable of non-trivial engineering tasks, all the way up to the engineering managers. They were essentially the hire paid copy/pasters. I said I'd return under the condition that I will golf all day. They hired me back on, I made the thing they needed, then they dumped me again abruptly for another onshore offshore engineer.

So sometimes a headcount can be an engineer, a manager, or both, and still be an embarrassment to git commits everywhere.

I entirely disagree both with this point and with it’s apparent subtext that being an engineer is better and being a manager is worse. I take it that you are one who takes great pride in “being an engineer”. That’s a separate topic (for instance, one can be an engineer in a management job).

We have the abstraction of job titles or categories to help us reason about what a job is. We do this for a variety of reasons, but in this case the reason to do it is to help people understand whether this advice might apply to them. Ultimately, a job is whatever it’s primary goal is, and you said yours is to empower junior staff who report to you. That makes you very different from many (most?) senior/staff engineers I have met, who are primarily metric’d on their engineering work. Since your primary job is a management function and you write a lot of code, that makes you a manager with some (or many, pick whatever modifier seems appropriate to you) engineering responsibilities.

Bringing it home, if a reader is an engineer (or IC if you prefer to avoid the fraught term) and not a manager, this advice doesn’t apply to them very strongly. Yes they should care about junior colleagues, and they should absolutely make time for deliberate peering and mentoring, but they should focus on doing engineering (which can include docs writing etc) primarily.

I think its pretty useful distinction. I know everywhere is different, but everywhere i have worked the roles have been very distinct. Engineers, especially senior ones, mentor people of course, with that being a significant part of their job, but that is really different from having someone report to you.

Sure, but is constant "direct attention" the best way to empower engineers? I would argue that systemic improvements (e.g. onboarding process, good documentation, team communication or company culture) are more impactful since they scale better and address the root of the problem. Of course, you need both, but saying that everything other than hand-holding is "just filler" shows a lack of understanding of good leadership.

I have people that report to me. This is true a lot of the time. The other thing I do is getting people to use the thing my team built - or figuring out what they want my team to build.

Agree. At the end of the day, someone is paying for the jr and sr person. Is that what they want? If so, then it is fine I suppose. They do need to state this clearly however.

You can also just create a slack channel just for questions (eg #eng-onboarding), where the sole purpose of the channel is those questions. Lowers the barrier a lot. Even better, you'll see even senior folk pop in to ask questions about parts of the stack or codebase they aren't familiar with.

Ugh this sounds like specific reddit spaced and I dont think it did end well.

TBH you land in a situation where you have 40 channels in the company you have to follow and it drains so much energy just to be in the loop.

Super hard to focus on anything if you know you can get pinged somewhere and you have to check or reply in timely manner.

Add to that emails and PRs and you spend 2/3 of your work day just enabling other ppl or answering questions.

Soo tiresome.

Agreed. This is yet another source of distraction for actually getting things done, and turns into side discussions of tangential topics far more often than a useful source of information. Beats wasting everyone's time asking questions in a standup, but should at least be understood to be very asynchronous with no need for timely replies lest it become an attention hog. Might favor just setting aside time for devs to add to a wiki document about their area of the system than just being always available for individual questions.

Agreed. This is yet another source of distraction for actually getting things done

Yes and no. Yes, some individuals might suffer in the short term from the friction. No, the lack of that friction is not good for the team.

The context (i.e., article) is collaboration. That's not about individual GTD, it's about the health and long term well being of the team.

Granted, there are non-team situations but if size and or scale are involved that's less likely. A non-dysfunctional team has overhead. Skip that and while you may not have a dysfunctional team, you'll have a suboptimal one. Either way, that creates friction. The messy shitty kind.

Sounds like you have some major Slack trauma, sorry to hear. There are many ways to use Slack and to have a channel for people to get their questions answered without having people "spend 2/3 of your work day just enabling other ppl" (for instance, setting expectations on response time, having people volunteer to spend their time helping onboard other folks, etc). Like any process, it doesn't work unless thoughtfully implemented.

Budget your time in more specific buckets. I let all email and non-direct slack dings wait until I am in between tasks, such as when I get back from a beer lunch. In my previous job, I stopped checking email all together because it was mostly all these dumpster fire notifications for others to put out or ignore until it blew up entire parts of the sector.

We've got that channel, and many, many other "help" type of channels, like "help-who-do-i-talk-to" as well as "help" for many different teams, subjects, etc. They work pretty well, but, there's just a lot of communication, and I think the new grads and very young engineers get overwhelmed.

Ultimately, communication between thousands of people is just hard, and technology solutions aren't going to solve all problems perfectly. And again, I want to stress that in general, Slack has been a pretty nice tool. We still just need to do other practices to make sure nothings flying under the radar.

> One solution I've found as a more senior engineer is to force a working session with a junior regularly. Like, we're not there to do anything specific, just work on something together. This ends up becoming a much more comfortable space for them to open up with all their questions

We have had really incredible returns from what we call “hack sessions” which are like you said, essentially hosted by at least one senior engineer. We find something in the moment to discuss, or someone shares their screen and we debug together. If no one has anything, I personally start quizzing people on deep technical details and it usually only takes a single question before the topic naturally evolves toward optimum teaching. By now people look forward to them as a place to bring their friction, so lack of topics is rare.

> It isn't just that they don't want to "look dumb", but they genuinely don't want to bother a senior engineer. So, paradoxically, the low-effort nature of Slack has actually created barriers to communication in this case.

This doesn't sound new at all. It adequately describes my experience as a junior long ago, back when you had to walk into the senior's private office and interrupt what they were doing.

Yes.. there are definitely online-people, and offline-people, or text-async-comm people vs personal-comm-people: for one the one way of communication is more convenient, for others the other, and for some there is barely a difference.

But this is imo fully orthogonal to Juniors not daring to ask questions, and depends on personality, the environment, the mentors, and maybe also the online- or offline-affinity vs the most prevalent tools, but as far as I observed that is the least impacting it...

We have voluntarily gone back to the office one day a week now, because we find collaboration easier when tech gets out the way and you can just talk to someone directly.

Surprisingly, the team has all loved it and we are discussing adding an extra day.

What about remote teams ?

I'm in that boat actually. It really just comes down to the people, like always. The teammates that meet together show respect for the remote folk, so it works. But I've definitely been at places that didn't really have that sensitivity for others, and it sucked.

My previous gig has an onshore offshore team that I interfaced with. Then they would interface with the offshore team. And the offshore team had its own very offshore team (not sure which shores we're on). I felt lucky that most of the onshore offshore team didn't like me much which meant all I needed to do was create the features that they tried and failed to do. It was a symbiotic pile.

I think a big part of this is we need a new work culture. Slack makes it easy to communicate but we don’t have good patterns in the work place broadly speaking for remote work. So everything is a Zoom meeting, or a virtual chat dump to a channel. We need to embrace more async communication and proper scheduling on team by team basis that works to get open air dialog as needed. These alone help remove barriers.

We also need to document everything more so than before, and by orders of magnitude. We just don’t have this as common workplace protocols yet

> One solution I've found as a more senior engineer is to force a working session with a junior regularly. Like, we're not there to do anything specific, just work on something together. This ends up becoming a much more comfortable space for them to open up with all their questions.

Just wanted to say thanks for doing that. I think it's a great thing to set aside time for, for all parties of senior, mid, and junior.

> Phones have just taken us to a point where tech is just always with us, thus, we've hit some kind of "maximum distract-ability" point.

Nail on the head, although the VR folks are trying to maximize it more.

> Like, we're not there to do anything specific, just work on something together.

I keep lobbying for "office hours" like this at every single one of our retrospectives and it gets zero traction. My juniors have mentioned how hungry they are to learn more about the craft and they love it when I drag them into conference rooms for impromptu brainstorming/lecturing, but even then I get no votes for implementing office hours. I'm eternally puzzled.

This is what I do, semi regular working sessions where I mostly watch/do my own work

>So, paradoxically, the low-effort nature of Slack has actually created barriers to communication in this case. (I have no idea how common this is, but I suspect, at very big companies, there are similar dynamics.)

I always think of this quote[0] from the great Byrne Hobart[1]:

>Slack is a bit like Adderall. Ask someone about it the week after they start using it, and they can’t praise it enough. Talk to them six months later, they’re back to baseline but now they have an addiction. And talk to them years after the fact, and they’re just regretful.

[0]: https://byrnehobart.medium.com/works-war-on-slack-97ef94264d...

[1]: https://twitter.com/ByrneHobart

That is not how Adderall works. Get some exercise and take some magnesium with it.