Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to set junior employees up for success in remote

slite.com

Post reply on HN
Print view View original

311–320 of 370 posts

Re: How to set junior employees up for success in remote

#311

Post by greatpostman »

bumby wrote: post #284
greatpostman wrote: post #281

Earlier quoted context omitted.

This sounds terrible and I would leave this team fast. I work in a high performing FAANG team. Deadlines get pushed all the time

Does one ever question why deadlines constantly get pushed? At best, it means those high performers are bad at setting initial deadlines. Or is it that meeting deadlines isn't considered a performance metric? Now if deadlines are important, maybe it's just relative performance that you're speaking to. So if everyone misses deadlines you can still be high-performing, but it's like saying you're the skinniest kid at fa…

The software is way too complex to gauge how long something will take. It’s also extremely risky to make a mistake in production. Projects slated for three months can take two years.

If you’re engineers are constantly hitting deadlines, probably it’s greenfield development or the problem space is simple

Re: How to set junior employees up for success in remote

#312

Post by UnpossibleJim »

cmrdporcupine wrote: post #106

"I think anyone who can’t work well remote, on average, will not be your top performers anyway." Ah, there it is, the bountiful blind arrogance I have come to expect from threads like this on HN. It's like you didn't even read my post, just looked for the hook to drop in and proclaim your superiority.

While said in an arrogant manner, I'll agree, I think the sentiment of, "Top performers tend to be self starters, no matter where you put them", tends to hold true. All rules have exceptions... sure, but by metrics of task completion which is what work should be about, instead of butts in seats (unless I missed something), That's what I want from my team. I admit my team is small and I can meet with them over Slack and chat more than most other, larger teams but I think maybe that's the answer to remote.

1. Defined goals

2. Available help over Slack and chat (which we have group and private channels)

3. Weekly or bi-weekly standups to get more of a sense of where everyone stands and have a lay of the land and understand your team.

4. The lead needs to do the leg work with the managers to let them know their team is doing the work and get the recognition they deserve.

It is harder in someways, but easier in a lot of ways and WAY more efficient where it counts in many ways. It is a shift and requires effort.

Re: How to set junior employees up for success in remote

#313

Post by scottLobster »

bornfreddy wrote: post #285
scottLobster wrote: post #173

Earlier quoted context omitted.

In defense of remote work underperformers in general, I work for a company with a lot of tribal knowledge. It shouldn't be that way, but that's how the company operates and our pleas for time/money to write adequate internal documentation fall on deaf ears (doesn't help that it's legacy software so there's not many people capable of writing said documentation). Result is there are a few wise old (as in 15-20+ years e…

Interesting. This aligns with my past experience as well. If I may ask, are you / is the company working on rectifying this, and if so, how? What we did was that we made our internal docs and agreed that whenever we were blocked by something, once we learned it, we would document it. It was a mixed success though because we never had time to work on the docs properly, and the veterans didn't touch it, so I'm curious…

Yeah we're trying to do the same, document things organically as we learn them on an internal Confluence. It helps, but we're piecing together fragments of knowledge without context, so information density is low outside of specific tasks. It's enough to solve the same problem again, but not enough to gain much holistic knowledge of the software. And same as your situation most of the veterans don't bother with it (they already have the knowledge and are extremely busy).

Doesn't help that some of the engine code dates back to the late 80s, was originally written on a mainframe for a compiler where variable names had character limits, so even if you know the surrounding conceptual terminology it's functionally indecipherable unless you have a lot of experience with it. It's hard to tell what it's doing or why, or even if it's relevant to the problem you're trying to debug.

What we really need is something like a dedicated sprint where we stop the presses outside of critical maintenance and just write documentation, free up the veterans to write down their knowledge. But that would require the company to actually invest in what is otherwise seen (wrongfully IMO) as a cost-center. :P

And honestly if we had that kind of money there's other software redundancies/inefficiencies that need to be resolved first, that would lower the documentation requirements in the first place.

Re: How to set junior employees up for success in remote

#314

Post by fartcannon »

geraldwhen wrote: post #272
DoingIsLearning wrote: post #158

Earlier quoted context omitted.

It's mostly because it is taboo to give a pay rise above 15% to retain someone (unless promoting) but most companies are willing to spend more than that difference on new hires to match the market rate. I am sure there is some sort of game psychology explanation on HR's behaviour and equally, from an employee perspective, the cost/inertia of following through with a job change will probably weight in HR's favor.

My company has paid double digit raises regularly. I’ve still seen people leave for internal transfers because they think the grass is greener. Money is why a lot of young devs quit, but it’s not the only reason.

You shouldn't dox yourself by answering this, but I sure wish you could tell us which company is giving double digit raises every year... I'm over here languishing at less than 2% at best, having to leave every year or so just to get the necessary bump.

Re: How to set junior employees up for success in remote

#315

Post by cactus2093 »

cmrdporcupine wrote: post #46

This is not a surprise to me. I think it also applies to some people who are senior and new on a project or team. Or people with a more synchronous working style. I think remote has been toxic to productivity in all sorts of companies and for all sorts of people. I think there's in general a "personality type" that does really well with remote in a certain kind of job and thrives with fairly asynchronous disconnected…

One thing I haven't seen mentioned in this discussion recently is that on every single engineering team I've worked on in-person pre-pandemic, synchronous interruptions were a significant frustration. Remember how we all used to bemoan open concept offices? Every team developed some version of a rule around not coming up and tapping people on the shoulder, like setting an expectation to reach out over chat first or a headphone rule not to interrupt someone if their headphones were on.

It's weird that this experience, which I know was very widespread in tech, is completely missing these days in discussions of remote vs in-office. People urging a return a to office are even explicitly bringing up the ability to come up and tap someone on the shoulder as a selling point of being in-office, ignoring the fact that most people have always hated this.

As far as sitting down and working together collaboratively, I have found in the past 2 years that video calls work perfectly well for this. We've made an explicit effort to reduce the number of recurring, scheduled meetings but also to encourage more ad-hoc, collaborative meetings to work on things together synchronously.

I think being an extrovert and missing the social aspect of working together in an office, is a perfectly legitimate reason to want to go back to an in-office job. In an ideal world I think every remote team should have an in-person off-site event for a couple of days every few months for purely social and team-building reasons. But I'm very skeptical about claims that you can't collaborate to get work done as well remotely because my own experience has been so different.

Re: How to set junior employees up for success in remote

#316

Post by ospzfmbbzr »

travisgriggs wrote: post #241
ospzfmbbzr wrote: post #197

Earlier quoted context omitted.

Not personal unless you take it that way -- instead take it as a challenge and show him he was wrong about you. Programming well is difficult and takes time and effort to get good at, but it's worth it. Being junior and learning while remote is not ideal at all. I work very well remotely but only because everything is second nature to me now after so many years. If that makes me a 'top performer' then it's only becau…

> Programming well is difficult and takes time and effort to get good at, but it's worth it. I agree very much with parts 1 and 2 of your assertion. At 51, with a decent brag list of successes, I think I’ve even achieved some measure of it. The part I’m not sure about is the “worth it.” I used to think that, I’ve become less sure of late. What makes it worth to you? I’m honestly curious. I used to have various things…

Yeah I'm a bit jaded too. Would I get into this business today? Probably not.

Mostly because of the potential employers, who they hire and why, and how success is 'measured' these days. I've been contract only for 17 years and I'll never go back to employment. I guess I'm lucky to have the option, but if I didn't I'd find another non-employment way to earn a living.

As you say the problem is that individual contributor quality isn't valued as it should be -- it's not prioritized above say compliance with 'all the current things.'

Engineering culture is mostly absent everywhere nowadays and in it's place a culture of entitlement and groupthink -- the hallmarks of failing institutions.

Re: How to set junior employees up for success in remote

#317

Post by bumby »

xxpor wrote: post #308
bumby wrote: post #284

Earlier quoted context omitted.

Does one ever question why deadlines constantly get pushed? At best, it means those high performers are bad at setting initial deadlines. Or is it that meeting deadlines isn't considered a performance metric? Now if deadlines are important, maybe it's just relative performance that you're speaking to. So if everyone misses deadlines you can still be high-performing, but it's like saying you're the skinniest kid at fa…

Because setting precise deadlines is nearly impossible without a massive investment up front, that companies aren't willing to make. Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines. There's also a big difference between being a month late and a year late. It's also a lot easier to explain you're going to miss a dead…

>Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines.

Ironically, the civil engineering projects are one of the best examples of missed budgets and schedules. Almost every civil project at large scale becomes rife with change orders because coordinating different domains is complex, even if those domains have "precise" blueprints. Those blueprints always change, which is why the industry has "design" documents and "as-built" documents.

So what do you think it is? Why do they have an inability to coordinate large complex pieces of a project? Optimism bias? Can we really call someone a high-performer when they display those shortcomings? Or do we just normalize them so they aren't considered a problem?

Re: How to set junior employees up for success in remote

#318

Post by bumby »

greatpostman wrote: post #311
bumby wrote: post #284

Earlier quoted context omitted.

Does one ever question why deadlines constantly get pushed? At best, it means those high performers are bad at setting initial deadlines. Or is it that meeting deadlines isn't considered a performance metric? Now if deadlines are important, maybe it's just relative performance that you're speaking to. So if everyone misses deadlines you can still be high-performing, but it's like saying you're the skinniest kid at fa…

The software is way too complex to gauge how long something will take. It’s also extremely risky to make a mistake in production. Projects slated for three months can take two years. If you’re engineers are constantly hitting deadlines, probably it’s greenfield development or the problem space is simple

I agree. But if we don't manage it well at scale, that underscores that we don't really understand the complexity of the problem. Can you call someone a "top performer" when they don't understand the complexity of the problem?

We can write complex code with minimal errors[1].

"the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors."

But I worry when we facilely normalize sub-optimal behavior because we've normalized it. Especially as FAANG and adjacent companies work on safety-critical software and when that attitude pervades other domains.

[1] https://www.fastcompany.com/28121/they-write-right-stuff

Re: How to set junior employees up for success in remote

#319

Post by waylandsmithers »

geraldwhen wrote: post #5

Before remote, the office was already increasingly hostile. Open floor plans, some groups having shared seating, and offices for roughly no one. Now, it’s worse. Everything is “reservable equipment” of garbage monitors, windows keyboards, and 400 dpi mice. I suspect it’s harder for a junior to succeed anywhere today vs 2012. The office is not built to foster development or innovation. It’s an exec’s idea of what a so…

Brings back memories of a pre pandemic office where half the people were on the road at any given time so there were no assigned seats, but no reservation system either because it was never close to full. Some seats were better than others of course with regards to proximity to windows, bathroom, foot traffic, etc. which caused some conflict. Two people constantly fought over one desk with The Big Monitor... "Hey I always sit here" "Yeah but there are no assigned seats" "So what I have to sit somewhere else because I had a dentist appointment this morning?" and on and on

Re: How to set junior employees up for success in remote

#320

Post by bumby »

tuckerman wrote: post #293
bumby wrote: post #237

Earlier quoted context omitted.

From the HN Guidelines: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." I don't think a personal attack is most generous interpretation of their post. I would add some nuance. I've increasingly come to the conclusion that initiative is one of the best qualities in an employee. It's natural to see how having initiative wil…

If someone writes a post about struggling remotely and someone immediately follows it up with some general observation about how most people who struggle remotely weren’t going to be that great anyway it’s pretty easy for the OP to connect the dots.

It's not "can you connect the dots" but "should you connect the dots."

I can frame just about any comment as an attack in one way or another, but it's not a great idea. For one, it goes against HN guidelines but, more importantly, it just doesn't seem like a very healthy mindset.

Post reply on HN