Hacker News Reader

Comment by harrisonjackson | Hacker News Reader

For me, it depends on who is creeping. A junior engineer, I'd probably pull them up and start explaining what is going on. A fellow senior engineer I'd probably take a welcome break and ask them to grab a coffee - the only reason they'd be lurking lol. If it is a PM or someone else it might put me on edge - likely because they wouldn't have the context to understand what I was working on and if they didn't say anything I'd just be wondering what they wanted...

View on HN

So in all three cases, your focus is gone and what you were doing has stopped.

Helping a junior and maintaining relationships with your fellow seniors is a part of the job too.

But surely there's ways of doing that without making people lose their focus.

Actually, is there?

Yes, you pick the moment (much) better than wandering over to peek over their shoulder when 'something interesting is going on'. IMO that's exactly when you don't, ask them about it later.

To borrow from that cringeworthy scene in The Social Network: He's wired in!

Such as assigning times for focused vs collaborative work.

Yes, a vibrant meme room in a "management expects you to respond to business issues in this room" channel on <slack|teams|etc>

also, imo explaining something complex to someone junior often leads to answers to other questions. For some reason, talking through code out loud helps the problem solving process.

Eh, not really. Not all engineers work in high-pressure environments where focus is essential. Some senior engineers really enjoy teaching others. Some of the best mentors I've learned from were the ones who were happy to spend an entire Friday afternoon showing me how they would solve an interesting problem.

The first one, less so. Explaining what you are doing to someone (as long as they get the basics) can be a great way to cement your understanding of what you are currently doing.

Which is _okay_ as long as it doesn't happen too often. I work remotely now, but most offices have conference rooms or quiet spaces or respected headphones on policies for when you need headsdown time. If there's no way to signal that you are busy, then that's probably a separate issue than the 3 cases here.

The only time I (a PM) would do this is when you are working on validation messages / error messages / user facing text.

Error message phrasing is really very important, but it’s probably better to have that refined in code review or to have some explicit step for it.

Error message phrasing should not be in code. It should be in localization files, even for the default language, and not require a developer to modify.

Depends on the requirements. I've had many internal-only applications only require one language: English. At that point you can hard code many things, which skips the loading other files, checking different languages, etc.

I'd still rather the exact wording isn't in code, personally:

    get_msg('fail_add_address')

vs.

    'I\'m sorry, we\'ve been unable to add the address %s at this time,' \
    ' please try again later.'

(... but that's an ideal I have without ever having worked with it, so what do I know, and ymmv, etc.)

It really depends on who‘s the target group. I hate localization in Developer Tools etc, because googling it is harder and a lot of times English is just easier to understand. It’s different for a shopping site.

And what is this localization file called? We do not have a system where non dev can commit any change in our product.

We do have a constants file which has all the messages but a PM does not access to code/commit and has to go via a Dev.

How would you know this without entering their personal space?

Reply on news.ycombinator.com