How to set junior employees up for success in remote
slite.com(quoting book)
Amanda Nock, a tech leader and devops expert who posts frequently to Twitter, offered this in response when I posted on Twitter about how to hire good people remotely, “When I hire remotely, I ask about their online friends.” Nock doesn’t need the details of anyone’s online friendships, but she needs to know that the person has developed a serious friendship online; otherwise that person probably doesn’t communicate easily and naturally online, so working with them remotely is going to be difficult.
Nock says, “I often hire remotely, and I make a point to ask about what people's online lives are like. No details. If someone, for instance, has good relationships on Twitter or they're active in a Discord server, that tells me they're good at asynchronous remote communication. I don't care if the Discord server they're active in is a furry community or whatever, the details don't matter — the skill for forming relationships and communicating in a personable way over asynchronous text is there.”
(end quote)
But I think the opposite is also true: a lot of people do not easily form friendships online, and they lack online social skills, so they are not going work well remotely. These people are more productive in a traditional office.
From what I've seen, many people struggle to truly express themselves in written form. This includes well educated people. And those who are extroverted need to talk. Remote work tends to put an emphasis on written communication, and that is only partly offset by having a lot of Zoom meetings.
What nonsense, so are we expected to ask how many friends you have IRL to gauge someone’s ability at synchronous communication?
I can communicate remotely in a business setting (and have done) for many years. I don’t make friends online because it’s a personal preference.
It’s the same as “show me your GitHub profile” but maybe after 8 hours on a computer asynchronously communicating and coding. I don’t want to code or make friends on discord.
> What nonsense, so are we expected to ask how many friends you have IRL to gauge someone’s ability at synchronous communication?
Couldn't one draw parallels with the concept of networking here? As in, certain people might get a job because of being extroverted, seizing the opportunities that present themselves, as well as seeking those out on their own volition?
All qualities that might be preferred in certain roles, almost like a sort of self-selection.
Not saying that it's something that should always be selected for, but I suspect that it might be a bit like coding tests: vaguely useful despite the fact that they're not exactly the best method.
> It’s the same as “show me your GitHub profile” but maybe after 8 hours on a computer asynchronously communicating and coding. I don’t want to code or make friends on discord.
What if they want you to be the kind of person who does? I mean, you might want to avoid companies that expect you to live and breathe code (which might coincide with being available 24/7), but one can definitely imagine that such qualities would also be factors that companies would look for.
This an interesting approach to this that I wouldn't have thought of. You can clearly see who the people who are used to existing in a text space vs not.
In my team for example, one of my coworkers just hates written communication. He started after me and had to ask a lot of questions. To do so he'd send me a hangouts link and expect me to join so he could ask his question. Most of the time they were questions that then involved him sitting and staring as I had to go look up the answer and link him to it anyway. He was ignoring channels set up to ask for help and ones that would have gotten our entire area of the company to help him.
But I think the most insidious part of people who don't communicate well in written form is that it makes other people not want to do so. I was stuck as the only other engineer with this guy for 6 months. During this time I stopped updating, then stopped writing out ticket bodies. I stopped posting helpful things to our team channel and didn't update documentation. What was the point? Who was going to read it? I've been slowly getting back in the habit now that we have people on my team who actually... use things I spend the time to write.
And I get that he's twenty years older then me, has fifteen years of experience on me, and has not been living his life in a chat client since the age of 12, but he's a fully remote worker even without the pandemic and I feel like it's one of his opportunity areas.
My current supervisor said that posting questions and helps in public chat space is valuable since there's a chance that others will see and learn from the same question.
I guess he's right, after 3 months I can easily separate those who can follow conversation on slack and don't need other briefing, and those who need other session of briefing even though there's already many conversation and documentation.
The former will be better remote worker.
> If someone, for instance, has good relationships on Twitter or they're active in a Discord server, that tells me they're good at asynchronous remote communication
What does a "good" relationship on Twitter even look like? Is the author looking at specific metrics like number of posts per day, no of replies per post?
While I overall agree that hiring remote requires a new perspective and new set of questions, but ...their social media engagement? Some of the best engineers I've ever worked with had ZERO social media presence.
I like to do a lot of communication with candidates over email and some kind of text format during the process. This is usually when communication problems present themselves.
It would never occur to me ask them personal questions about the number and nature of their online friends ... very strange and invasive.
As an aside, many recruiters like to control the conversation with the candidate and have all messages/emails go through them ... this is a great way for the recruiter to hide a candidates communication weaknesses.
and that quote is a brilliant example of cognitive bias.
"Only people who have online friends can communicate in the written form."
which can then be extrapolated to:
"I have online only friends, therefore this is the thing to look for"
Which is remote-ese for "we can't hire them because they don't look/sound/act like us and won't like the same things as us, therefore is a bad cultural fit."
Wow, this is truly awful.
If you want to test someone's asynchronous remote communication skills then communicate with them remotely and asynchronously. How much trolling they do on Reddit in their free time is completely irrelevant.
Life and friendship happen in the real world and taking away the physical side will result in something incomplete.
I suppose many don’t feel satisfied by such restricted relationships and will only bother with the real thing. I know I’m like that.
Zero connection between that and WFH ability. It’s all about communication and emotional intelligence. A great communicator will be able to apply their skills even in the stunted context of video and text chat.
As for asking about friends, if it’s not outright illegal to ask about friends, it’s certainly in poor taste. Another half-asses innovation from the SV-like mindset.
Lol if she supports using people's social media accounts in the hiring process... Does she support using arrest records with the FBI for domestic terrorism? Because Amanda Nock has one... Idk, perhaps we should all be careful who we take advice from.
That's a good take out of current issue. I'd say though having online friends is not necessary, but ability to follow forum conversation and initiating / joining one is a valuable experience in remote work.
I can expect that older managements are lacking in this aspect.
That being said, there's synchronous remote (similar timezone and same work hours) that can help to alleviate the remote work issue.
For junior engineers it's really easy to fall into the trap of trying to solve everything themselves instead of asking for help when they are remote. I say this as somebody who has spent the last five years working remote team-based gigs.
> For junior engineers it's really easy to fall into the trap of trying to solve everything themselves instead of asking for help when they are remote
Senior folks do this. All the time.
Despite having 10+ years of experience and leading engineers at AWS, my default is to "spin my wheels". Now that I understand myself a little better, anytime I find myself laser focused on a problem, but making 0% progress, then I either:
1) distance myself from the problem or 2) ask for help 3) both
Junior or not. Asking for help can be difficult
One thing I started as a team lead is telling all my Jr and Mid level engineers to reach out to me for help if they need it, and that I would always be happy to get on a call with them. I had a pretty small team so this was easily manageable. At first I wouldn't get any folks reaching out for help, but eventually they all got comfortable with calling/messaging me if they had an issue.
I think a bit part of this is how you see yourself on the team. I gave myself the personal title: "Specialist and Support Person". On any given day I really only have two tasks:
* Work on "specialist" stuff within the app, stuff that is way over the heads of any of the Jr's or Mid level devs.
* Provide Support on everything else. Since my engineers are the ones pumping out most of the code, the biggest part is making sure they are supported in every way imaginable.
There are other responsibilities obviously, but within the context of "day to day" on the team, I found aligning myself with those responsibilities really helped my team.
That trap also exists in the office, though. Even in the office, you need to give juniors active guidance. It's just that the way you give that guidance is different online and in the office.
It's a lot easier for me to observe a junior struggling, spinning their wheels, and give corrective feedback in the office. I don't know the remote equivalent of glancing at their screen and body language while I get up for a bathroom break.
Listen to what they say during the daily team meeting, and occasionally ask by chat how they're doing. It's true that it has to be a bit more explicit, and it may be a bit slower, but it's far from impossible.
That's one point of contact per day. I was able to continuously be aware of anyone struggling before. I can't continuously ping them throughout the day. Even 4 times a day seems much too high contact to not be patronizing, and that still leaves them to stew for up to two hours at a time
It's really this simple. Junior employees need to be more actively managed than senior employees. They literally do not know what they're doing, that's what makes them junior. Remote or local, they need more oversight to help them learn and become productive.
Can you give me advice on how to provide oversight in a way that's not demoralizing, infuriating, patronizing?
I found working with juniors _fun_ and rewarding in person. Remote i have hated it and don't think I've been good at it
One thing that has worked for me in the past is to do some regularly scheduled pair programming. When I'm driving I narrate my thought process and encourage questions. They get to see things and when I make a little typo and they can catch it, not only does it save me a few seconds but it makes them feel GREAT that they helped the senior dev. Making this highly interactive and the senior driving FIRST makes it still "fun" when the junior is in the driver's seat.
One of the biggest skills you're helping a junior to learn is how to break apart a big task into small, workable components. Maybe they are assigned a user story, but that user story is going to need multiple functions written, or something like that. So you might start with pseudo-coding or creating the interfaces together, talk high level about how a particular method should work, and then let them do that part by themself. "Let me know if you get stuck or done with that and then let's do a little informal code review."
Beyond that it's the normal management stuff of compliment sandwich on negative feedback, etc. The normal things you do to build and maintain rapport with coworkers.
Oh, another thing I find helpful is to make it clear up front what I'm doing and why. I don't just narrate what I'm literally doing in the programming, I narrate why we're doing this at the meta level and what the expectations are. I also make it clear that as they get more comfortable there will be less oversight.
The difference is it in the office you can just actively see that somebody is anxious and you can ask them what’s up.
True, but there have been plenty of cases where juniors languishing in an office with little guidance. And remote you can still ask them how they're doing by chat.
It's true that the barrier is a bit higher remote, but it's not unsurpassable.
In office, there's watercooler chat that can lead to debugging session. In remote there isn't.
That being said, with the former culture, it's harder to ask question online and asynchronously, since usually they prefer and wait to have in face session instead.
The equivalent in remote is a chat/thread turn into a call with a screen share. Managers and seniors encourage juniors to ask questions or just “speak” their minds. There are multiple touchpoints for that to happen, dailies, 1:1’s, spontaneous check-ins b/c people care. In a culture where remote work habits are good, these will be imparted on new-joiners, especially less experienced ones.
I think successful remote work has to take the position that asking for help 1:1 is bad, actually.
* If you go through the process of figuring it out, you gain a durable understanding of the subject matter which you can use to solve other problems.
* If either you (after your investigation) or the subject matter expert (on request) produces documentation of the subject, other people in the future can use this artifact to unblock themselves.
* If you ask in a public Slack channel, at least those who are channel-surfing or searching during the retention period might see it and learn something.
Getting an answer 1:1 is empty calories. It gives quick satisfaction in the moment, but only leads to more and more communication down the line. Communication kills productivity.
But there's gotta be a balance.
It's totally conceivable for a new/junior employee to spend hours or days solving a problem that's already been solved in your codebase, and someone with experience could fix the issue in literally 5 minutes or less.
Yes, it's good to learn things on your own. But especially in a small environment, sometimes you gotta move faster than that.
Sometimes getting an answer 1:1 is "empty calories", and you're not learning how to solve the problem.
But that might be because the problem doesn't need to be solved, and you were wasting hours or days trying to solve it.
> position that asking for help 1:1 is bad, actually.
Which is fine for some things. But also really really bad for virtually everything else. It's exceedingly hostile, especially for places where there is no written documentation, and lots of old timers who have tribal knowledge and are "far too productive" to answer messages.
I don't know what universe you're from. Communication kills productivity? The opposite is true. Getting feedback early and often is a productivity booster. Sure, sometimes it's better to ask in a public channel instead of 1:1, but to state that it is actually bad is absolutely false.
“Work is work” [0]. As an organization scales, an increasing fraction of employee time is spent on communication instead of work, leading at best to diminishing returns on headcount and sometimes to total gridlock. To the extent that an organization wants to derive marginal productivity from marginal headcount, it needs to find ways to get employees to talk to each other less.
People can't go into the process of figuring it out if they have no direction of what to figure out, what they are expected to accomplish, where the documentation is, how it's organized, who are they expected to report to, and a lot of other things.
Juniors aren't born knowing any of those things.
Yeah that makes sense to me too, you also tend to be a lot more insecure and want to prove yourself when you're a junior, so you may be a lot more self-conscious asking for help thinking that it may be perceived as incompetence. I've definitely experienced that when I started working. Being remote probably means that it's even harder to push through this insecurity and it could also mean that others may not see that you're struggling and come help help you spontaneously.
That being said I think it can probably be improved while still remaining WFH, for instance by more actively chaperoning newbies.
One problem with being a new employee, junior or not, is that it's hard to know who to ask or has worked on something similar before when you don't really even know your coworkers. The thing I miss most when WFH is overhearing relevant information. Teams dailies do not really solve that problem.
Not just junior engineers, unfortunately
Common advise is to ask for help but like how? Everyone is busy around me!
The only reason I got hired at MAGMA is because I was able to apply & work remote.
I am pretty introverted + slightly autistic (not self diagnosed). I do a lot of customer facing work too, which I would never endure when not working remotely. But working remote means I can just turn off when I'm not feeling so great. Presenting is a lot easier... Approaching people, also, a lot easier. Just send them a message on slack/teams/discord. Before that I would have had to muster the courage to talk to certain people. It's a lot easier to onboard as well, given the change in environment is much smaller.
I feel SO lucky that I just happened to apply for this job when COVID and remote work started.
I think this remote work has equalized the playing field in terms of attractiveness & height aswell, as those qualities are far less visible when interviewing remotely. Wouldn't be surprised if we see the average height of high paid workers decline due to this.
> I am pretty introverted + slightly autistic (not self diagnosed). I do a lot of customer facing work too, which I would never endure when not working remotely.
> I think this remote work has equalized the playing field in terms of attractiveness & height aswell, as those qualities are far less visible when interviewing remotely. Wouldn't be surprised if we see the average height of high paid workers decline due to this.
This is a great point and shines a light on all kinds of equitable advantages of remote that are possible in the long term.
It isn't just this, either. So many more employment possibilities opened up for me when it no longer became mandatory to relocate to work for all the biggest software companies, none of which seem to have offices near me. So instead of having to ask my wife to find a new job, uproot my family, and sell my house, I could just start a new job.
Conversely, the companies doing the hiring no longer have to restrict themselves to anyone who was able to move to San Francisco or Seattle before they turned 25 or people with no families.
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 tasks, and on HN I think there's a bias towards seeing our whole industry that way.
But some of my best jobs were not like that. They were sitting down with people in very up close conversations and working out ambiguities and tasks. And mentoring juniors and working things through with them.
All that said, I won't be going back to in person. I'll be hunting for places that know how to make remote work, even though I don't prefer it. Because remote is still better than the 1.5 hours a day I was spending driving and the toll that was taking on my health and sanity. And most of the local employers are crappy.
So it's a real mix of stuff, we're in a transition period. It's going to take a few years for this stuff to shake out.
I think anyone who can’t work well remote, on average, will not be your top performers anyway.
What I mean by that — as a manager and one of the senior engineers, I had insight across our organization to projects and employee performance.
Those who thrived being remote were those who already were the top performers. Those who were followers; who lacked discipline, failed faster and more obviously. Most software engineers produce more effort than they’re worth and skate by with meetings, “pair programming”, etc
When the lockdowns started, my team at the time were some of the top performers. I had already had a remote team and we knew how to screen for it and manage it.
Some things we employed - weekly syncs across team members, an always open video chat, daily stand ups amongst projects, fun days where we’d play games online, etc. The most effective thing we implemented was holding people accountable to their deliverables. People commit to their work and tell us when it’ll be done, if they fail we talk about it as a team. Team members quickly learn they must deliver and if they need help ask. We don’t delay timelines and I expected a clear “I think this will take days” if they need to delay, that’s fine, but they explain publicly and ask for help.
That quickly led to discipline and we’d pair senior engineers with junior engineers to improve.
It's so easy to conflate "top performers" with "people like me".
Take someone who points out flaws in a system, things that need to be addressed before they become a problem. The exact same words from two different people can be interpreted differently. For example:
- "X is a top performer who anticipates problems with their deep understanding of the system"; and
- "Y is negative and simply points out problems rather than offering solutions."
The difference? Whether or not that person is liked, which really comes down to them being like me. That's literally all it is.
Take your example of "fun" days. Personally I hate that kind of faux team bonding. I mean if it works for you and your team then great. But don't be fooled. You haven't found the formula for "top performers". You've just found people like you.
Totally agree, and it's the kind of language that rings alarm bells for me especially when coming from a person with a manager role.
"Those who were followers; who lacked discipline, failed faster and more obviously."
Classifying one's reports into "top performers" and people who "lacked discipline" or "followers" betrays a categorical mindset very eager to bucket people rather than see the contradictions and subtleties of people's individual situations and work towards helping to resolve the difficulties, which is what leadership / management should be about.
EDIT to put it another way: good parenting (which I don't always practice, BTW) doesn't say "You're a bad boy", they say "You did a bad thing." Likewise when talking to oneself, it's really shitty to say "I'm a crappy X [engineer/painter/swimmer]".. it's far better to say "I did X poorly last time." A good engineering manager should help frame things this way, and shouldn't be saying "top performers" and "followers" but, instead: "people who performed well" and "people who tended to be behind or 'follow' in the last quarter" and help the latter identify how they can do the former (note: not be, but do).
We were in a global crisis. People were at home with their young kids, spouses, dogs, whatever distractions. Empathy and flexibility were required to make this work. "Failing" at work was probably the least of concerns for many people, given everything that was going on. I personally quit my job rather than deal with the guilt of having spent time getting my son to do his school work rather than triaging bug tickets. Others could not afford to do so.
It’s not hard to implement a system which measures success.
For one, we ensure everyone commits and delivers and holds others accountable for failures. What you’re describing is not a measurement of performance, I see your point though.
I too very much disdain “team bonding”. But the point is to get to know and respect each other. By doing so you’re more likely to hold yourself accountable.
In terms of performance there’s two parts:
1. How much you commit to
2. How much you deliver on commitments
We expect 100% on #2 or explanations and plans to adjust. On #1 we expect that to change as you increase through the ranks. Junior members don’t need to commit to as much, senior more and staff should commit to a lot and help the junior.
Top performance is learning what you can accomplish and delivering, communicating when you’re having trouble, and then ensuring improvement over time in terms of committing to more.
> It’s not hard to implement a system which measures success.
So if I were looking to join your team and you said this it would be a huge red flag. Why? Because it's not easy or everyone would've done it already. The fact that you think it's easy really would be a cause for concern.
> For one, we ensure everyone commits and delivers ...
First sentence in and you've already added a qualitative factor. For a given task, is it "enough" to meet team expectations? This depends on how difficult it is perceived to be. Maybe there's some huge unknown unknowns. Maybe it's just really tedious and is real time gated for some reason. The standard retort is "we take that into account" but again this conflates subjective perception with objective truth.
Some people talk a very good game about how hard their job is and I've seen some very senior people skate because of this and the fact that for whatever reason they're liked (by management).
You expect 100% delivery on commitments. How is that not going to just reward under-promising? it also leads to things being half-assed. Bugs closed as "could not reproduce" or "working as intended". Features being just good enough to ship without the massive problems surfacing later. Hell, that's just another opportunity for more impact.
You’re correct nothings perfect, but these systems are really easy to develop. That said and as I already stated, most people are mediocre. Same goes for management. I see lots of talk and little delivery. It’s the whole reason YC invests in founders that “get something shipped” is a thing. People don’t move fast, they talk, they mess around, they don’t commit and deliver. Same for managers as engineers.
Further and to clarify, I said it’s fine if you can’t complete a task due to some unknown. Vocalize it to the team and update accordingly. It won’t be held against you if you if you collaborate to get it resolved. If that happens every time, there may be an issue, but typically people learn to investigate before committing.
Expecting people do what they commit is the only way to drive people to success. As I said, there are two factors, how much you commit to and how much you deliver on commitments. If people want to move up they have to commit to more AND deliver more over a 6-12 month period. Failure to deliver on a regular basis means you should commit to less. In either case, it’s easy to measure objective results.
Comments like these are red flags for me, because pushing back on estimates or communication is not going to go well. Your job is to produce results, if you fail, but ask for assistance that’s one thing. We can plan around that. If you fail and don’t request assistance that’s another. It’s about promoting solid engineering and development, keeping delivery timelines, etc. This worked on the remote places I’ve worked, might not be a great fit for you idk.
In terms of bugs, that’s more of an engineering culture. We always had strict and thorough PR reviews. High test coverage, formatted code with comments and two reviews from at level or more senior engineers.
I do not think that is entirely true at all - I am definitely very well liked at my job and probably most people would say I am also not like them at all.
Nobody is conflating Steph Curry with 'someone like me'.
+50
> I think anyone who can’t work well remote, on average, will not be your top performers anyway.
I don’t think that’s the case at all. One could say a similar thing in that it enables the worst employees who can drag down so-called top performers. But I don’t like any of these framings.
I personally prefer working in the office. I’m more productive, focused, and able to check in with someone or go grab them and show them an issue I’m having. I’m able to attend talks, have discussions, etc., which get me going on certain ideas. I am a person that doesn’t work well in ambiguity. I like to have a plan discussed and agreed upon. I find this is much harder remotely, for reasons both known and unknown.
Very few deep conversations happen over Slack. I miss some of the deep conversations I used to have with fellow coworkers on slower days. You are also very limited to the type of work you can do. Basically any job requiring hardware interaction requires you to be in office, either by natural constraints or policies.
But I am also like the commenter above. It will be really hard to give up remote work. The convenience of not having to commute, dress a certain way, have my own food in my own kitchen, etc. are all massive perks. At some point, I may choose to go back into the office, but I’m going to do the remote thing for a while. Especially now that gas is insane.
>I’m more productive, focused, and able to check in with someone or go grab them and show them an issue I’m having.
I think there's an important distinction here. It may be more productive for you but not necessarily for the team. You grabbing another employee may increase your productivity but subvert theirs. Anecdotally, my personal productivity goes way up when I work remote because I don't have all the "drive-by" questions that erode my focused work time. Whether or not that makes the team more or less productive may be a factor team dynamics and contributions.
At the same time, being able to maintain productivity while handling questions is a skill in of its own. I work on a team building/maintaining internal tools/infra and a large part of my job is interfacing with other teams and maintaining productivity on my own work at the same time is a big part of my responsibility.
So it cuts both ways.
I don't think that's a distinction, and it definitely isn't one way because the you here will also be interrupting the team. All this gets into team dynamics, which can't possibly be whittled down to such small interactions.
Then there's this somewhat weird obsession with people supposedly being unable to perform their job without 8 hours of uninterrupted solo time. The work day isn't supposed to just be each person working solo trying to accomplish as much as possible. Interacting with the team is being productive. Extremes in either direction are likely not productive.
I agree that team interaction can be productive. (I might even be a bit cynical in saying that most team interaction is not, but that might be a digression). I think the distinction is in how the work culture manages those interactions. My previous job wanted open-door policies; what that turned into was a poorly managed ad-hoc set of interactions. Open door interaction tended to foster unproductive venting and it can become like corralling cats to refocus that energy into solving problems. That may be fine for a supervisor; it's probably not the best use of time for front line production person.
I think I may disagree about the "somewhat weird obsession" with uninterrupted work. (I'm assuming your '8 hours' was hyperbole). The research seems pretty clear that interruptions are more detrimental to highly focused work. I don't think it's unreasonable to expect certain blocks of uninterrupted time if the type of work requires it, but that shouldn't be conflated to someone expected to simply be left alone all day.
> I think anyone who can’t work well remote, on average, will not be your top performers anyway.
This sort of overgeneralization just tells me we'll have people in 5-10 years "realize" that many of the benefits of remote work were just built on relationships and processes created in the days before. It's like the "open office" floor planning all over again, but with higher stakes.
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 experience) veterans who know the "deep magic" of how the software works, but they also tended to be the least available online during our year of WFH (with some exceptions).
In the office the culture for accessing these guys was: Ping with slack DM/skype, if they don't answer in 15 minutes walk over to their desk and bend their ear, unless they were clearly working something more important at the moment. Sometimes there would even be short lines of people outside of their cube waiting for attention.
There was an organic interrupt-driven workflow for these experts because they were in so much demand (with occasional pauses in access if they were working on something time-critical). That whole workflow collapsed under WFH, and as these veterans were used to operating on their own/managing their own time roughly half of them failed to be readily available online. This led to issues for people like myself where we needed some piece of their knowledge but just got radio silence for hours, sometimes days. So you pick up some other work to fill in the gap while you wait for a response, but that leads to inefficiencies of its own once they actually do get back to you. Once I had a cascade of about 6 stories going in parallel because I kept picking up alternate work to fill gaps, only to get to a point in THAT work where I needed some tribal knowledge, so I pinged the appropriate SME, waited several hours, picked up another task in the meantime... etc
And leadership lacks any carrots/sticks to make these guys accessible aside from asking nicely. They're largely where they want to be for their careers, value their time, and have all the truly vital knowledge so they can't really be punished lest they leave the program.
Sadly I suspect my company's organization is closer to the average than yours, so lots of other companies fall into this boat. It's not always a matter of discipline :)
I've seen this pattern recently outside of software. This kind of "tribal capture" lead to mediocrity and nepotism. The untouchable tribal leaders fostered an environment where unpleasant roles were left understaffed until 'lower people' were subtly manipulated into taking them, who then left. It created a revolving door of staff that otherwise would have made good contributions. Management in response to the turn over, shut down critical thinking about the staff and just committed to the problematic structure.
Yeah that accurately describes my workplace as well. The revolving door of "lower people" you mention is very real. I'm one of those "lower people" and I've definitely been shifted into the work no one else wants. To be fair I was fresh out of college and took the "volunteer for the work no one wants to earn respect" route, and it did earn me some respect, even a promotion and a pay bump. But after a couple of years of trying to push further it's clear there's a ceiling, and my only chance of doing any of the interesting work is waiting for the old men to retire/leave, and then I'll likely be dumped into the deep end to figure things out myself, under extreme time pressure because critical stuff's breaking and I have 25% of the knowledge necessary to fix it, which makes me the remaining program "expert" :P
I'm sticking around for personal/defensive reasons (it's stable and recession-proof, and I have a one-month old so moving would be extra stressful for the family), but I doubt I'll stick around for more than another year or two. My turn for that revolving door is coming up
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 if there is a better approach.
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.
I hear you! Thanks for sharing.
Utterly nonsense. How about children learning from home via a laptop? Doesn't work. Same for people who need to be trained in a new work environment. You want real interaction. You need to experience more than only sound and video in order to learn efficient. It's extremely wrong to think that good performers can always do these things from home. Not right.
I joined my company straight out of college and it was during covid peak, it was totally remote and guess what, last week my manager called me and told me that I've been promoted with a salary hike(within less than a year).
If you've discipline and commitment you can make anything work. :)
Agreed. I've line managed people who have grown immensely during covid. I think the key is understanding the new medium... A remote office where conversations are encouraged to happen in the open and not by DM, is a better environment for juniors to learn than an office where there's closed rooms and knowledge moves in a more hierarchical way.
Congrats, but do you ever wonder if it would've been faster/easier in person?
I just want to note that my experience is the exact opposite of this in every regard.
I suspect it depends on age and class.
My 5 year old struggled and needed a whole bunch of support.
my 8 year old was able to work on her own, but still didn't get anywhere near as good learning outcome as being in class.
Now, the reason why my kids didn't fail utterly, was because my wife wasn't working and could, just about support their learning. Until it sapped her will to live.
This is roughly analogous to junior employees. They need special attention, and providing that over remote is a challenge to scale. Not impossible, but a challenge.
You also need to factor in that Junior employees are more likely to have shit accommodation.
Yeah, we did remote kindergarten and it was basically a disaster. We were lucky that my wife could help, otherwise our kid would have learned nothing.
Your experience as a child learning from a laptop?
On that topic, no, I am referring to observing my own children learning from a laptop. I could not have been more skeptical of this approach at first. I was wrong - the approach has worked well so far.
EDIT: I definitely should have mentioned that my children are learning from a laptop WITH very close guidance from my wife who is raising them full-time and with intense dedication!
> EDIT: I definitely should have mentioned that my children are learning from a laptop WITH very close guidance from my wife who is raising them full-time and with intense dedication!
lol Pretty big caveat
>my children are learning from a laptop WITH very close guidance from my wife who is raising them full-time and with intense dedication!
In other words, they are not at all just learning from a laptop.
Sounds like your children are actually learning from your wife.
My experience is that unsupervised education is worthless.
Nope. Personally I could not disagree more.
I studied CS pre pandemic at a regular university. The whole curriculum was designed around lectures and in-person classes. But I skipped most of them due to social anxiety and laziness. Because every class had a digital script and I could practice with old exams, I did fairly well. Even better than most of those guys that visited every lecture. I guess that part of the problem is that some students tend to think, that just visiting the lecture is enough. They forget to practice the stuff on their own. Which you do automatically if you work through the script all by yourself.
After university I dropped right into my first job. Because of the pandemic it was 100% remote. Again, this worked perfectly. I could not have been any better. I even was able to take additional responsibility due to my performance "which exceeds expectations".
So calling this nonsense is nonesense ;-)
Have you considered not hiring children?
I learned largely via laptop until Grade 8 (am 25 currently). I wasn't behind when I transitioned to regular school.
I suspect it works for readers, not audio consumers.
Your management style sounds like it would rapidly kill creativity and innovation, psych safety, and codebase quality.
I hold myself to high standards and have been described as a top performer by every manager I've ever had.
I am disciplined and work extra hours as needed to ship. I am constantly thinking about the product and the engineering challenges we face outside of working hours. But sometimes things take longer than expected, sometimes complexity estimates are off, every so often I have a bad week due to personal reasons. Having to conduct a team-wide postmortem every time a ticket rolls over into the next sprint sounds exhausting and I'd start looking for a new job stat. At a minimum it's a huge amount of communication overhead when you should trust me to get my job done, especially considering my track record.
> Your management style sounds like it would rapidly kill creativity and innovation, psych safety, and codebase quality.
Couldn’t be further from the truth. I ran an applied research team for years. We had hundreds of patents, multiple publications, a growing open source project, multiple presentations a year, delivered a couple of the highest priority projects, and were consultants company wide for deep learning.
I was always fine with delays, but you had to discuss them and collaborate. Come to the team, explain, then we could prioritize accordingly (5 min). It’s not a big deal, but always required high communication. That’s difficult in a remote environment, but that’s why you have regular meetings & have to be more strict than normal about planning.
Perhaps it wouldn’t be an environment for you, that’s fair. But a project isn’t about you, it’s about a deliverable; often a team effort. If 10 min of communication a day is too much, idk then.
> People commit to their work and tell us when it’ll be done, if they fail we talk about it as a team. Team members quickly learn they must deliver and if they need help ask. We don’t delay timelines and I expected a clear “I think this will take days” if they need to delay, that’s fine, but they explain publicly and ask for help.
We have exactly the same strategy and it works very well.
> Those who were followers; who lacked discipline, failed faster and more obviously. Most software engineers produce more effort than they’re worth and skate by with meetings, “pair programming”, etc
This is so common and I am glad that remote work has been an effective extra filter. I mean, I don't mind mentoring junior devs, but also I am not a teacher and many of them seemed lacking total basics. Like they memorised algorithms but had no idea why they work or common issue was them just pasting code from Stackoverflow and then asking for help when it didn't work.
> People commit to their work and tell us when it’ll be done, if they fail we talk about it as a team
That sounds horrible. Software estimation is not a science and some say is impossible. To hold people to their estimates or else they've "failed" is toxic.
Just a personal opinion, but I hate daily standups. It's agile theatre. Nobody listens to what others are saying; they're too busy trying to make up good sounding stuff to say when it's their turn. I'm being a bit hyperbolic, but the general principle applies.
But sounds like it's working for your company so more power to you.
> an always open video chat
What.
It's a way to just be together, It's kinda just a way to share space and breakup the loneliness of covid and you can just ask questions to the team.
I've not done it as an established thing, but had standups where we pivoted to working on issues and as the issue got sorted everyone just chatted and enjoyed each other's company whilst moving onto other work. 3 hours later it's lunch and you end a mega video chat.
This most likely doesn’t mean that every person has their camera on 24/7, the setups I’ve seen have a “room” that is always open then people can enter and leave whenever.
Tools like Remotion or the virtual office apps with spatial sound and movable avatars also aim to lower the friction and make informal chats easier.
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 fat camp. It's normalization of deviance, and not a trait of high performing teams.
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 deadline 3 months in advance than a week before.
You don't get high performing teams by forcing crunch time because the deadline is the deadline. This is also why I'm grateful not to work in video games; you can't reschedule Christmas.
>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?
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
"Get better people" is not a talent strategy at scale unless you are also going to "pay them a lot more" which means that your corporate strategy also needs to include "make a ton of fucking money." Nice if you can pull it off, but the rest of the world needs to manage their companies too.
sadly, this is my experience as well...
...but it's also true that all-superstar teams rarely win vs teams composed on superstars and supporting staff [1], and thus you can't afford to hose the supporting staff.
[1] sorry I don't have a better reference - https://www.google.com/search?q=all-superstar+teams+vs+super...
Another side to this is, how possible it it actually to acquire a team of "superstars"? If you work at a big, well paying company maybe. But for anything non-FAANG, you might not have enough talent coming in that you'll be perpetually short staffed if you set the bar too high.
Pair programming is a fantastic tool. Why the snark?
I like pair programming and think I learned a ton by being the junior “driving” while the senior was “navigating.”
But I’ve also had some nightmare scenarios with people who just massively slack and do nothing. I worked with someone who wanted to “navigate” in 10/10 sessions and never said anything. They just watched me do stuff, didn’t respond to questions, didn’t work on docs, didn’t look stuff up. It was weird.
Mismatches like this made me eventually stop doing it as the team ended up separating out to pairs of superstars and pairs who did nothing. And it demoralized people.
That's why people should not be forced to pair program. (and I personally favor pairing)
Clearly this person is not throwing shade a pair programming, but lazy employees who might skate by doing lots of "pair programming" without pulling their weight.
I've come across people that are very good at getting "help" on their work to the point that they do very little work.
GP isn't talking about Pair programming in general. Pair programming is great. But quote-unquote "Pair Programming", where only one person does the work... not really. Been there done that.
Some people need more authority and external motivation generally in order to realize their potential.
I agree, and have to wonder what would happen if pre-remote some researcher tried to break it down to 'Computer Science Graduate' and 'Taught themselves on CodeAcademy'
I would bet the CS graduate is having a much easier time self-learning at home than the no-degree person who usually stops peoples work 12-15 times a day to get them to explain concepts or show them around the code, again...
Huh, I'd expect the self taught person to be more capable of teaching themselves the codebase than the CS grad, especially once you get into companies doing bog standard CRUD API + SPA webapp for a SaaS.
It's the new grads from courses that are theory heavy and practice light that expect a lecturer or tutor to guide them through the whole process in my experience.
From personal experience only:
Self taught people (Bootcamps are included here) are self taught to perform in the very specific tool-heavy world. Think Create React App + AWS. It's harder for them to independently understand bigger decisions/system design/building something from the ground up
CS grads know how to study, know when they are really stuck, and know what the good questions to ask when stuck are. They were thrown into this impossible course work and survived, they're better at studying complex systems, and to clearly define what exactly they do and dont understand
Bootcamp grads? they just need you to share a code snippet of exactly what you asked them to do in a different place in the codebase
You could explain 10 times why you chose to build the new microservices in Clojure and they still won't get it
People mistake self taught with understands complex software problems. Usually from what i've worked with, self taught is self taught to copy paste some commands into npm
Then their university/college has failed them. Learning how to think/learn/work independently should be the primary goal of tertiary education. It almost doesn't matter too much what your degree was in.
Sure, or more likely having a CS degree or not does not strongly correlate with programming skill or software development skill.
Some people are good at programming, and do a CS degree to expand their capabilities. Some people do a CS degree solely for the career options (which to be clear is not necessarily bad). Some people didn't do CS degrees for whatever reason, but have thousands of hours in codebases, and know when to look up an algorithm or data structure.
> I would bet the CS graduate is having a much easier time self-learning at home than the no-degree person who usually stops peoples work 12-15 times a day to get them to explain concepts or show them around the code, again...
I am a self taught and am pretty good at looking stuff up and figuring it out on my own, especially stuff that isn’t even in a manual. I figured this was pretty common since self taught is sort of forced to develop this skill.
> 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 tasks, and on HN I think there's a bias towards seeing our whole industry that way.
Sites like HN are popular with people who prefer to socialize online and have chosen online communities to be a part of. Remote work is a natural extension of how they’ve built their online lives, which leads a lot of people to assume remote work is just natural for everyone.
But it’s not. Like you said, there are a lot of personality types that do not do well at all when working remote. Discussing those people has become difficult in online spaces where people like remote work and resist any suggestion that it’s not good for everyone. This has done more harm than good to the cause, IMO, because a lot of companies and teams went head-first into remote assuming it’d be an easy win. Yet on a company-wide scale, it’s not. It requires work, and training, and mentoring, and more resources just to get back to baseline in many cases. Companies that have deluded themselves into thinking it would be easy are then caught off guard and disappointed, leading to sudden reversals of remote work policies or slow depreciation of remote teams.
If we want remote to continue to grow, we need to shift the narrative away from “Its just better, period” to a more nuanced acknowledgement that it’s not for everyone and that it requires training and effort to unlock and maintain the benefits.
I think the same arguments could be made if you swapped in-person for remote (nearly) throughout. There are those of us who prefer remote work and have been told that we must spend dozens to hundreds of hours a year just commuting in order to be more productive. "Finally", more companies are acknowledging our POV and optimal work style after years/decades of talking about it -- I think that's why there is so much enthusiasm around remote work these days.
The pendulum may have swung too far, on that I'll agree.
The funny thing is that I got my "start" in programming doing things remote. Open source development, and in the 90s, IRC, MUDs/MOOs, etc. I have all sorts of collaborators and friends I've actually never met in person. And we were pretty productive.
But that's not how $work went, when it went remote. All the open sores just festered and got worse. I know for a fact multiple projects delayed or faltered because of the remote move and the impact it had on productivity. And I'm sure it wasn't restricted to Google, but industry wide.
I mostly agree with you, but we should remember that the shift to remote happened abruptly due to an unprecedented, immensely disruptive pandemic. This was not a controlled experiment where we can automatically attribute any issues that emerged after the shift to inherent flaws in remote work.
That said, I think your experiences with the limitations of remote are valid and shouldn't be dismissed, although I personally am extremely committed to remote.
I'm committed to remote, too, because the alternative (local pseudo-feudal crappy employers who generally underpay) is worse. But now on my own terms and with an employer I choose rather than the half-assed way that it was attempted at Google. And without my kids at home.
Probably, actually, I'll end up renting a desk out of home somewhere nearby.
Sounds like we both survived the pandemic with young kids at home. I for one won't be getting the t-shirt.
I agree with some qualifiers. I think some of us went all out with 'its just better' due to incessant onslaught of corporate propaganda telling me spending 2 hours in traffic is akin to meditation and 'me' time. Those ridiculous statements caused a lot of people to go into messaging overdrive that, arguably, lacked nuance.
Personally, I can attest that in person has some advantages over remote ( training comes to mind ), but I agree with the gist of the article that a lot depends on the audience ( some people don't need constant hand-holding ). And that is just two facets without touching the fact that not all jobs can be remote ( although a lot could be ) and some industries are ran by, well, old people who only know of one way to do things.
Is it harder? It can be. My team was fine, but some of us were already fighting for off-site schedule pre-pandemic.
After pandemic started, I made an obvious prediction that we will see some differentiation in companies ( full remote, hybrid, in person ). Workforce already voted for what they want ( remote jobs see 3-4 times the applicants ), but it is a larger cultural shift and companies would love to keep remote as a carrot for 'top performers'.
As a senior developer, if working just in the office as was expected in the past I was distracted by things like a story about the weekend two colleagues are having in the background that sounds amusing, or the junior developer constantly spinning around on his chair to ask a question about something because "you're there". I always had time for that kind of thing but my productivity suffered and I was always frustrated by not getting enough done.
Working from home wasn't all roses either even though I got more work done. I was already doing a balance of WFH as a contractor before covid and that was working well for me, but when covid restrictions happened and I was WFH months on end, I really started to feel the lack of human contact and socialisation. That story about the weekend was something I suddenly craved to hear. My mental state would suffer because I had no life other than sleep, screen, sleep, screen, and then my productivity would start to decline as a result of declining perspective. I think I need some social contact just to stay calibrated.
Now I have a balance, a couple of days in the office, a couple of days at home, it works out well for me. I use the days in the office to catch up with the team, do any serious whiteboarding we need to do, and help out the juniors on the team with any questions they might have. I use my days at home to just crush out code with whatever music I want on in the background.
As you say I think it will shake out. I know some say that people have forgotten the value of hard work and there is a push to get people back in the office full time, but I think having people in the environment that suits their productivity the best is the way forward (edit - and to circle back to the point - taking care of mental states is important to maintaining productivity).
> I really started to feel the lack of human contact and socialisation.
Was work the only place you got this? I'm so glad I don't have these extended socializations and don't miss them the slightest. In my experience, they were all just useless banters and people trying to form hierarchies/comparisons/political interest groups.
Any company that tries to move away from full WFH are holding themselves back. Given the option of working from home, most people will choose WFH.
Maybe its different for a single person who doesnt have much human interaction outside of work. Even so I feel like those interactions don't necessarily degrade significantly via video chats. You cant smell them through the screen and that might be a good thing.
> Given the option of working from home, most people will choose WFH.
most people who think like you will choose WFH. As the post clearly describes, they found the lack of human contact during the day hard to cope with.
The key thing here is that people need choice.
I think COVID is an atypical representation of life with WFH. We also cut off a lot of other human contact as we were encourage to isolate and avoid contact. Even as an extreme introvert I found it got to me a bit at times, but I'm finding that now that I feel OK doing things again this has faded.
> but when covid restrictions happened and I was WFH months on end, I really started to feel the lack of human contact and socialisation.
I've been working remotely for nearly a decade, and something I've been saying over and over for the past 2 years is pandemic remote is not normal remote. The first half of your sentence here is doing a lot of work.
Yep, I used to be more productive WFH when I was already acclimated on a team. When I joined a new team and it turned fully remote, my productivity dropped and it took me longer to come up to speed than if I were in the office.
Honestly, I was on a team @ Google that was doing consumer hardware. It had problems before WFH started, but it got 5X worse once we got sent home. The whole situation was highly unproductive, a combination of bad politics, but also a degraded tech stack with a pile of technical debt and a build system that took forever to finish, and then because of Google's "no source code on your laptop" policies (which they stubbornly wouldn't loosen during COVID) an additional 10 minutes to copy the binary to local and then push to device, and poor debugging tool support so the round trip was agony to test and prototype. It was just awful. And managers seemed to have no idea how to make it work.
So I decided to switch teams, to something that was friendlier for remote, more cloud-based backend stuff. A team that was doing daily standups. And it was sort of better. But acculturating into a new team while remote was painful. And the work unstimulating. And the depression and tedium from being stuck at home and dealing with kids in educational and emotional crisis too much.
So I just quit. Walked away from a 10 year high paying "high status" job. And I'm not the only one, friends of mine did the same thing. I suspect much of the "great resignation" was driven by the frankly irresponsible way that employers just didn't manage remote well.
I wasn't happy with $work before remote, but remote + a job with some bad aspects was like pouring naptha on a fire.
Getting a new (remote) job now after a few months off. I think it will be better.
> no source code on your laptop
Cybersecurity policies and work from home has always been extraordinarily strange to me.
Optical character recognition exists. Big Corp, trust me, if I wanted to steal your stuff, I'd have it already.
Stop locking my laptop down, we both know that's mostly a scare tactic.
I think the main concern is theft of the laptop. They do trust you. They don't want someone to have your drive with proprietary source, even if the drive is encrypted.
Sounds like they should fix this with better laptop encryption. There’s many cheap methods to make source code on a stolen laptop useless. Using this as an excuse may mean that the org is stupid or lies to employees.
Since this is Google, I think this just means that they don’t trust employees. And that’s a bad situation.
If you can’t trust employees to not do bad things with the tools required for their jobs, then it’s going to result in unhappy and unproductive people.
It’s like not giving carpenters nail guns because someone killed someone.
> Since this is Google, I think this just means that they don’t trust employees
Since this is google, the repo is hundreds of terabytes.
Not only that, having lots of copies hanging around on laptops is a big risk, even with encryption. Considering that google's likely threat model involves state actors, not having code on laptops is a reasonable mitigation.
But I suspect the biggest issue is that most of the tooling is design to run on whatever version of linux Google runs, not OSX/Windows/ubuntu.
As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with.
State actors have security clearances for employees with equipment that allows them to contain state secrets on devices. This is a solved problem and Google not allowing any on device source code is not a security issue, it’s a control issue.
> As a developer, I don’t see a situation where I need the whole codebase, just the portion I work with.
Unless you are very special/lucky then your code will need all sorts of the repo to work.
One of the joys of working at a big tech company with a single repo is just how much shit is pulled in by your dependencies.
my code shouldn't need a custom C++ library that does BLAS 0.15% more efficiently than the opensource lib, its just moving data from one bucket to another. However, it does because of a massive chain of dependencies.
> State actors have security clearances for employees with equipment that allows them to contain state secrets on devices
What level of secret? and how many secrets? all of them? No. Security services don't generally allow people to store secrets on mobile devices, because they get lost a lot. They certainly don't allow all secrets ever stored in the DB to be carted around on >70k employee's laptops (of which at least 1 a day is stolen, most often in sleep so the disk encryption key still accessible)
Thats not to say that low-side devices don't ever contain secrets. They clearly do, but they are supposedly risk managed to limit the blast radius. ie, they need to have a good reason to have that secret, a time till destruction, and clear paper trail to see where and when that secret went.
Thats not really scalable to a repo with > 5 million files.
"Sounds like they should fix this with better laptop encryption."
I'm not aware of any security experts that share this reasoning, if the information is truly sensitive and high value.
"There’s many cheap methods to make source code on a stolen laptop useless."
Such as?
I have a security clearance and follow protocols on my device to process sensitive data. Here’s something that came back fro Google, https://www.esd.whs.mil/Portals/54/Documents/DD/iss_process/...
If my laptop is stolen and the thief doesn’t have my keys the data contained is worthless and isn’t a breach notification at all.
Where is that in that document?
The definition of “on laptop” is pretty ambiguous also
It's also almost entirely arbitrary since Google lets iOS and Android app developers work off laptop (there isn't much a choice with iOS because the toolchain won't run on a gLinux workstation anyways).
Our company handled remote fairly well. The overall team/work organization has been poor whether remote or in office. In our case, the resignations have been driven by the fact that people leaving the company can get 1.5-2x their current salary. We have had a lot of other team member move to new teams at the same company too (hopefully I'm one of them in the next couple weeks).
Good luck at the new job!
My opinion is that the issue arises because of expectations and formalities that occur in remote environments over in person.
When I'm remote, every email I type, message I send, Jira update, commit comment, etc. are etched in stone for reference in all of perpetuity, time stamped and all. There's an unspoken expectation to be informed and expert in all things in many work environnments to avoid looking "incompetent" (which is absurd, everyone is ignorant about some things). Remote work creates a hostile environment that makes this even worse. It makes people think about if they really want to email or call this person to ask about something because they worry that not being aware or not knowing about something may come off to others as being incompetent (people are aware that certain questions and statements can show your hand of expertise). So if I happened to be half paying attention during a meeting with a client or executive, if some change in an effort occurred I happened to miss or be too busy to see, or if I'm dealing with new tech I'm not quite familiar with... I have to tread lightly.
In person, you meet people, you get body language, everyone is forced to speak on demand so competency and lack thereof become very clear in conversations. Expectations relax because if the head has no idea and no one else does and everyone has to reference it, well then, I'm not doing so bad. I'm not relying on looking at their cherry picked correspondence choices. Not only that, people are then more willing to communicate with people because they become more comfortable. They build relationships and they know it's OK to show their ignorance about some specific topic and that person is going to help them out a bit, mostly off the books. Not only that, communication in general becomes less formal. If I'm at the coffee machine and see Alice there and I had some question, I can just drop it in a friendly way. My intentions are more clear from body language, am I trying to assess her or am I really just trying to get the information I need to do my part. If it's trivial it's more natural just just say hey, I don't know how to do this thing, do you? Imagine sending that in an email or scheduling a conference call.
This means for teams that have already built that level of trust are at an advantage in remote. They're comfortably sending those messages to one another. They've met the person and can gauge their personality. For juniors it's probably petrifying in some cases because they want to look more skilled and knowledgable than they are because they often don't have a general understanding of the level of expectations people have of them so they want to do better and often want to make an impression.
The issue is that office culture often has a whole lot of competitive elements and people are more hesitant to communicate, it brings everything to a crawl. If work environments weren't always pressuring their labor force, people would be more willing to admit ignorance and or make informal communications necessary to speed things along in a more formal and recorded context, at least that's my opinion.
I definitely agree - the level of formality is significantly increased, even over Slack, because of the "permanence" you referenced.
I switched teams 4 months ago (old team dissolved in a merger) into an area where I don't have any experience (Django backend -> "DevOps-y" microservices in Go and infrastructure type stuff). These are skills I want to possess and I was grateful for the opportunity. Unfortunately the outcome has not been what I had hoped. I'm trying hard to teach myself but I'm missing so much. My teammates are all significantly more senior and are extremely busy. My experience and reputation in other areas feels like it actually hurts me -- am I not actually a competent programmer, like I thought I was?
Worse is I feel worried about switching teams again. What if I don't succeed there, either? Will I need another 4-6 months to ramp up and gain knowledge? I don't want to end up a pariah, or be seen as an incompetent developer who can't be relied upon.
I'm applying to jobs at other companies now. I know I'll face many of the same challenges there as well, but I don't really know what else to do.
Driving is dangerous. It's no joke, you can get killed if you slip every time you go on a highway. Insanely dangerous. And more work than work itself, the commute is the worst part of people's days.
It was destroying my health. But in my case it was honestly partially driven by personal choice to live rural rather than live in the town where our office was. But having made that choice at the start, 10 years in it started to become untenable.
But now in theory, at least, I don't have to make that compromise.
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.
I think part of it is the 'junior' part. If you have a strong workflow and confidence with what you're doing then it's easier to be independent
I just don't find this argument convincing. The tasks does not change because its remote, rather the costs have gone up to hire junior developers while costs to increase producitivity in existing devs have dropped significantly.
Namely, github copilot, which removed a lot of "hey junior can you write a class to talk to this CRUD api" to "hey github generate snippets of boilerplate code that I can tweak to my exact needs"
Lot of companies are realizing that their existing senior developers are now armed with this amazing tool and that its leading to faster turnarounds. The door appears to be closing for entry positions that used to take in high school drop outs, code bootcamp grads or single moms.
I don't agree that copilot will hurt junior hiring; Co-pilot is just a tool that even juniors can use to make them productive even quicker.
In fact, I think it will allow juniors to contribute faster and for high-school drop outs, code bootcamp grads or single moms to get hired more easily since instead of a steep learning curve, copilot allows them to quickly produce.
I'd agree with the argument if there was no such thing as entropy and senior developers were a static resource that didn't depreciate but every company is going to need new blood just because the seniors are eventually going to retire or move to different companies for their own growth.
The big appeal of juniors is usually low salary and willingness to work long hours and so juniors will often be attractive to companies.
I wonder if it is really so much down to just personality, or if training, process changes, and better tools could largely ameliorate the differences?
I have a hunch that as more work shifts remote, new ways of working will evolve.
Working remote is a skill. It's not something you automatically know how to do, it's something you learn how to do.
It takes time and effort as an individual, and more time and effort as an organization.
If you don't put in that time and effort, you won't be good at it, like any other skill.
What a lot of people don't realize is offices are largely a by product of industrialization. Prior to that, most operations were either family ran and ran out of a home, or even when a company employed non-family members, they often paid piece work. So the employee would work from home, and then deliver their work to their employer and get paid per piece they produced.
What's old will be new again.
I do think a lot of it is driven by personality types, but I would attribute that more to personal need for close contact and socialization. I will never thrive in a remote environment- not because I can't manage focus or work asynchronously or anything, but because it makes me extremely depressed. It's impossible to keep my productivity up as my mental state degrades.
Yeah it's very rough. Even having family in the house with me, I need outside socializing.
Even when we were able to shift back to hybrid in-person, I'd drive in the 45 minutes get to the office and find basically nobody there. It was just as isolating, but totally pointless.
I know this can be a real challenge for some. Do you think it would help to have a nearby a co-op work space type setting, where you would have others around and you could come and go as desired?
Very convincing methodology.
Ask people on subreddit and LinkedIn a question. Then write another article based on 'I swear, dude'. Link it as a source for this 'article'. Write the rest of the 'article' by imagining what the world has to be like, given your poll is a source of truth.
Follows my favourite format of 'journalism', where there is some arbitrarily chosen data source, followed up by series of 'interviews' mixed into one single 'story'. I'd expect nothing less from a management and HR expert in marketing.
Hopefully we can see some ornithomancy next!
The absolute worst ones are the "here's a crowdsourced treasure trove of information from 20 million users on Reddit" and it's literally a listicle of the top-10 all time posts in a sub
This is definitely something I've observed, even with young-senior people, since COVID.
If you're set in your ways, remote work is a blessing - the office was just a hindrance to the optimal workflow. But if you're adapting your workflow, then remote work is an extra barrier.
There's a lot of reasons someone may need to adapt their workflow: maybe they're junior, maybe they're new, maybe they're just a good PM/salesperson/manager who's trying to clear the way. Remote work is a distribution shift in the difficulty of their work.
I can not relate to this. I found my first real job after university in a medium sized company (100-200 employees). This company is a truly in-office company by heart. Before covid everybody had to go to the office. Working from home was not an option. Not even for one day. The whole culture was built around the in-person work experience.
But due to covid everybody worked remote. So did I. I actually never met most of colleagues up until recently. But working remote was never an issue for me. On the contrary, my colleagues struggled with working remotely. I think thats because they are relatively old and never used messengers, mail, social media and co. to an extend as my generation (age <=25). I think that people that grew up in digital spheres are going to feel quite comfortable in a remote environment.
Let me make a bet here: You are self-taught in a lot of ways, and in your spare time also like to fool around with software development stuff.
That's why you don't need hand holding. A lot of your peers do need hand holding to get stuff done.
I'm a 43 year old developer, and I can work remotely without any issues. Partly because my development experience was always broader than my job alone.
> Partly because my development experience was always broader than my job alone.
I think for some of us (and me) it's really hard to fully understand this. When I was in 10th grade I was going to local meetups where I first found out about Elm (they had beer too, I guess no one expects kids to show up to a meeting held in an office building at 7pm). I still can't understand the mindset of someone whose dev experience only being limited to their jobs, but I think you did a really great job at summarizing it.
> I think thats because they are relatively old and never used messengers, mail, social media and co. to an extend as my generation (age <=25).
I don't know the age distribution at your company and their educational background, but a lot of people under 50 have been using such systems at least all of their adult life (esp. if they work in tech). Around 1995, internet started to become mainstream. And long before that, people were using BBS.
Smartphone are newer though but I don't think they brought much to the equation. If anything, people became less tech-savvy after the emergence of smartphones.
I think it's just how the environment is set up. If the company sets you up for success in remote work, there might be some sub-optimal things, but it will work out. (Remember, not everything is perfect in the office as well).
If the company does not accommodate for this properly, then you will fail. Experience will help you compensate for some of these shortcomings, but that will also only go so far.
Working in government, we're seeing a larger amount of folks leave within a few months of hire. I had never heard of that before COVID.
When I started here years ago and not remote except a one day a month telework option, it took weeks to get involved in a project. Everyone is laid back and wants to give time to acclimate and understand the place and the project first. My PM told me basically, "Hey I hired you for algorithm development, but just look around and see what's needed, what's interesting to you, and from there pick what you want to do."
That might sound awesome, and to me now with experience it is the reason why I stay here. However, as a new employee, it made me super neurotic to not have any sort of direct tasking. It felt like I didn't have work and wasn't being assigned any. I think if I had been remote it would have made things even worse; at the time, one of my saving thoughts was I could be there on time and be seen looking around Confluence or reading to learn about the research topic.
I would definitely be interested to hear how folks onboard freshly hired junior devs onto a project or team, how much direct tasking they give, how much time or how they allow for adapting, etc.
I work in (state) government as well, and I'm noticing the same. Our institution is definitely like what you mention - "find your own work" kind of deal. It _sounds_ good until you are basically expected to find your own billable hours in Month 1.
My wife actually works in the same institute as I do, but in a different wing - my experience vastly differs from hers. I am basically full-time on one project with consistent billable codes, and she's expected to shop around to try to find projects with open hours, so she can get her 40 hours in every week.
She comes from the private sector, so she's admittedly put off by that idea, especially not really knowing anyone and not being well-versed in academic research as a career. I couldn't imagine being put in that position as my first position out of college.
Our company's new CTO held an all-hands meeting Friday where he stated something to the effect that he agreed with Elon (Musk) and that if it were up to him we'd all be huddled in the same office..."but times have changed". What I heard was "I really don't like that we can't keep an eye on you, but since the labor market is still so tight in tech, we have to deal with remote (for now)."
When I listen to my company's upper management I get the impression they genuinely believe that everybody spends mopst of their time in meetings and discussions and then sometimes does some deep work. They seem to have forgotten that the lower ranks spend most of their time on doing actual work and that distractions and interruptions there are quite expensive and unproductive. What's often weird is that they also set up the workspace in a way that collaboration is hard because when you talk to each you might bother the people in the next row.
Labor market is tight and yet i am waiting weeks if not months for a result of my interview process. Companies just suck.
"I will, begrudgingly, acquiesce to your demands. But know this: I hold you all in contempt." Good way to generate business for resume reviewers, I guess.
Sounds like you need a new job.
I think there is something to this - as a junior you can learn a lot through osmosis just by being around seniors and more experienced people. This doesn't just apply to software or tech - I have a friend that works for a bank that says just having new members of his team be within earshot so they can hear how he talks to clients and partners on the phone is a useful learning experience for them.
However, my experience pre-Covid was that the office was where I was the least productive. My team was already spread out across many office locations, so virtual meetings over Teams were already a thing. The company I worked for at the time had shifted to an open floor plan but without an adequate amount of conference rooms, so often for these virtual meetings we would all be dialed in at our desk, despite 4-6 of us on the call sitting right next to each other. Of course this created echo so meetings were a constant game of muting/unmuting and minimizing how much you talked to avoid feedback.
Working remotely did not require a shift in tools at all, but instead has made these calls much more pleasant to attend and easier to engage in.
It’s certainly been a very long time since I was a junior, but I don’t think I would have succeeded at WFH as one.
I learned so much from the people in the cubes around me just via osmosis. Working from home the last couple years I have barely spoken to anyone without a reason to. Random chitchatting with people outside your bubble is how real growth happens, especially early on.
I don't agree with this article about "micro-tasks". You don't learn accountability and how to break down problems into small tasks if someone does it for you. What junior developers need (actually all workers) is ownership of what they are making. And I don't mean "they own part of a code base". I mean literal ownership of the company. The best way to learn how to make decisions is to own a piece of the pie and participate in decision making process. This is true for remote and not remote workers.
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 software factory looks like, and it’s a bad one.
> I suspect it’s harder for a junior to succeed anywhere today vs 2012
When I was a jr engineer I was paired with some senior people who showed me the ropes. They expected it would take some time to come up to speed and intentionally worked to help me get there. They took my college degree as "proof I could learn" and then taught me what I needed to know.
Over the last decade, I've seen less and less mentoring. Even before COVID and in office environments. The productivity expectations are just so high so often. It's hard to succeed in that environment.
IMHO it's turnover that's the problem. Companies get engineers for an average of like 24 months and it might be even less for junior employees. Taking the time to train someone up doesn't make as much sense when you're not going to get return on your investment.
I'll add to that, the motivation to mentor someone really goes away the third or fourth time you see them hit the inflection point of the usefulness curve... just to be hired by someone else because $current_employer can't find an extra few grand to keep them.
I don't like training and mentoring people. I'm pretty good at it, but I try my damnest to avoid it now.
Yep, and why becoming one of the more senior members of a team is a reason I would leave a team. I wouldn't want to deal with on boarding people endlessly while still keeping up with my own work.
You should still do it. Those people leaving and going to other companies is good for you individually as it builds your network.
Not everyone likes the mentoring and pedagogy aspects as much, and that's fine IMHO. I do like it despite turnover and "wasting" resources on some people, but I'm coming from an education/instruction background. I can see how some profiles would not be really interested in doing that.
The GP said they didn't like it but did it anyway. They stopped because the developers they mentored would leave when they got good. My point is that it's better from them individually to mentor someone and have them leave because it builds their network.
> IMHO it's turnover that's the problem.
In software I've seen this to be a huge problem. In other disciplines my observations are that it's not as bad.
The turnover issues is something that could use a lot more exploration. Nothing is going to change until it impacts those who are distant from the front line engineers. The managers of the engineers know about the problems. The executives over them are distant from the problem.
> Nothing is going to change until it impacts those who are distant from the front line engineers.
What do you mean? Because companies are leaving a lot of money on the table, unable to complete software projects, and unable to solve the problems they care about just because of it.
You mean it in some way other than monetary impact?
No other industry has salaries that rise this fast. I tripled my salary over about 5 years going from Junior -> Senior (experienced) -> Team lead. Quadrupled if you count the 6 months I did as a trainee.
> The turnover issues is something that could use a lot more exploration.
It is about pay. If you switched jobs in the past year, you got a massive raise. If you stuck around, you got peanuts, if anything.
I mean... I stuck around and got a 20% raise, fwiw.
The question is why are they leaving after 24 months? Perhaps the company is lacking a clear path for development in terms of responsibility, impact, and renumeration. Not adequately training because they are expected to leave after 24 months is a self-fulfilling prophecy.
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.
Yes, but maybe it's time for companies to ask themselves why they have such high turnover
I think it really depends.
I've seen junior devs getting promotions in several cases because they were that good. On the other hand, I've seen several less performant junior devs that are treated as completely replaceable. This was in companies where mentoring actually happened.
Chicken vs Egg? Maybe the turnover is high because juniors aren't getting the support and mentoring they need to feel like it's worth sticking around. Is there evidence turnover has increased in the last decade or so? It's always been pretty high in the IT world anyway.
That's because their raises, if they happen, are factually pay cuts (aka lower than inflation).
Over the last decade, I've seen less and less mentoring. Even before COVID and in office environments.
I agree, and for this reason, I don't like the framing of the editorialized headline, which lays blame only the Junior employee. We also have to consider this a failing among management, whether that be a direct supervisor who isn't taking an active enough role in the junior's development, or a higher manager who is giving out too much work so as to leave no one time for development.
ETA: the submitted headline has since changed.
In my accounting internships, we were just expected to show up and work. There wasn't much mentoring, and accounting classes really only cover theory. It was a bit of shock to the system.
That's unfortunate. People aren't cogs in a machine. New folks have a lot to learn. Even experienced people starting at a new company need to learn that company with its nuances. New people to an industry have SO MUCH to learn. Colleges aren't job prep.
> Over the last decade, I've seen less and less mentoring.
I've seen a lack of willingness be mentored / coached. Not directly of folks I have worked with but as a bystander. There's not one clear reason but there is an overtone of entitlement.
>I've seen a lack of willingness be mentored / coached.
What do you mean by this? They were arrogant?
Yes. Not showing up to office hours, willfully disregarding advice / tips on working with the team.
I had to do my first two internships in office (started before the vaccine rollout reached my age group, eek) and my experience was pretty similar to what you said. I was given some time in the beginning to get familiar with the codebase but not much mentorship.
Most questions I could only get an answer from was about business requirements because they were either too busy or didn't knew much more about the part I was working on.
Not sure if my situation is usual though, even for interns after COVID started.
IMO, an expensive keyboard/mouse/monitor isn't necessary for a junior to succeed. Plenty of coders learned on much worse.
That's penny wise, pound foolish thinking. A good keyboard and mouse and monitor for your developers (who directly earn you revenue) is not going to break the bank. But the lack of them will reduce productivity and morale, possibly even causing (on the margin) some talented people to leave. RSI and posture problems are no joke!
In other industries you need immense capital investment in equipment for workers to be productive; no serious software company should care about the comparative pittance that office hardware costs.
I wouldn't expect my employer to provide anything but a decent quality membrane keyboard and a middle of the range logitech mouse by default. Then people who prefer higher end hardware can ask for an upgrade.
I'm typing on a 300 euro keyboard right now but I would consider it a gross waste of money if a company decided to give them to every single employee regardless of need or preference. For instance for most people better chairs and desks would be a vastly better investment, ergonomy-wise.
> membrane keyboard
I can't type on these things to save my life. I need full keys with at least some click in order to type well. When I'm forced to use the keyboard and trackpad on my mac, I am an order of magnitude slower than I am on a cheap external keyboard and mouse.
That's why people should get a budget to pick their own gear.
the amount of times i see critical business users getting slowed down because their laptop is a piece of crap astounds me. The value of the laptop is negligible amortized over it's lifespan so give people good stuff to work with.
The fact that good equipment makes economical sense doesn't refute the argument that good equipment is not a requirement for a junior to succeed.
Your comment reminds me of all the people screeching about their good school district, as if it is somehow capable of covering for them if they choose to be a crap parent.
In both cases the stuff people are fussing over is basically a rounding error compared to the big factors.
Beyond some basic utility, e.g. being able to compile the code in under 5min, the hardware one uses is of negligible impact to their success. A developer will succeed or fail based on their training, mentorship, the nature of the tasks they are given, and all the other more social and interpersonal facets of the business they fine themselves in. A glitchy mouse won't make them or break them.
A glitchy mouse sends the message that a company is not willing to spend $35 on a mid-tier Logitech mouse for the benefit of a resource they are likely spending six figures on (not just in salary but other costs).
If they are making this easily fixable mistake, imagine what else they're doing poorly.
A company isn't going to go all out on everything all the time. That an unending task. At any given time you are going to be putting up with something that's less than ideal in the workplace. Maybe the mouses will suck. Maybe the coffee machine will be broken. Maybe the test server will be a slug. There will be something to complain about all the time if that's what you want to do. All of these can be construed as some "signal" but you're basically just reading noise.
A glitchy mouse or bad keyboard will definitely make or break a developer's productivity. I can only spend so long correctly typos before it starts to negatively impact my mental state. And since so much of my job is building mental models of things, that is a direct impact to my productivity. I experience it every time I'm forced to use the keyboard/trackpad on my mac (because I can't type effectively on membrane keyboards).
Don Norman has has found that attractive things work better[1]. While it’s not exactly the same, I think giving your employee some freedom to choose the gear they use is probably money well spent.
[1]: https://jnd.org/emotion_design_attractive_things_work_better...
I see your point. I believe that if someone is trying to do a job and their equipment is "glitchy" or some other technical issue it effects their morale.
Low morale = lower quality of work.
>A glitchy mouse won't make them or break them.
It can break my god damn wrist joints if I have to use it all day. Speaking from experience.
It's a raindrop in a hurricane though, the best keyboard, mouse, and monitor in the world aren't going to make someone productive in an unproductive environment.
But they could make someone unproductive in an otherwise productive environment.
Engineers are expensive, and every minute they spend fighting with equipment rather than being productive is costly.
Maybe not, but a bad set of tools can cause real problems. Strain injury, for one thing.
Exactly this. I got RSI from using bad keyboards and mice, and I won’t any more.
Feeling valued is necessary for a junior. They deserve the same three monitors everybody else gets.
>They deserve the same three monitors everybody else gets.
I wouldn't make a strong statement like that. As a junior, you're just excited to be there, and gain experience. If the company policy is that you don't get the top-of-the-line hardware until you reach a certain professional milestone and this policy is applied equally then it's not the end of the world.
> As a junior, you're just excited to be there, and gain experience.
For the first few months perhaps. Then a friend sends a pic of his setup and tells you that he will split a referral bonus with you if you apply. It took me 4 months to find my first dev job, once I hit the 6 month mark, jobs came to me in abundance.
You proffer that people should be fine being second-rate citizens so long as there is a policy outlining their second-ratedness?
This is not the star-studded retention policy you think it is.
It's the not-even-beginning of the world. Why work for someone so cheap? Why fight for a monitor, where at a competitor you could fight fort a raise?
But they are getting the same junk as everyone else...
" Everything is “reservable equipment” of garbage monitors, windows keyboards, and 400 dpi mice."
Wait, you guys get three monitors? I only get the one that I had to find in the closet-of-beige-machines.
I think devs would be better off having the equipment they need instead of everyone getting the same package. And yes, that includes juniors starting with a simple setup, and expand as they start to know what tools would make them more effective at the work they end up doing.
I actually find it hard to switch from my "bad" hardware, I'm so used to one single small screen and average keyboard that it's how I do all my coding, despite having enough money to buy an expensive set up. I find it distracts me from my actual job, which is thinking.
Strong same, I've been working on a 14" laptop for the past 2 years with no external monitor or keyboard. A second monitor makes me twice as productive at procrastinating.
Given I can only reasonably have a single application open (which is an IDE with full documentation/intellisense inside) it means I'm forced to focus, apart from right now obviously.
Having a lot of monitors might encourage multitasking beyond what one's attention span can handle. If you have 4 monitors, you'll be tempted to throw YouTube on one and news sites on the others. A single monitor forces you to replace your code editor with YouTube, and people are probably more hesitant to do this.
At least a second monitor tends to be super useful, especially if you ever need to refer to documentation or another file while coding.
To add, while this study isn't measuring actual productivity, people say they expect/feel like their productivity increased 40% with a second monitor:
https://www.jonpeddie.com/press-releases/jon-peddie-research...
same. i've got 3 old monitors that just keep working. could I get a new widescreen to replace all three? Yeah. will I? Probably not.
> IMO, an expensive keyboard/mouse/monitor isn't necessary for a junior to succeed. Plenty of coders learned on much worse.
This is true, but the learning process is much more enjoyable when you are correctly equipped.
100% disagree. I will NOT be productive at a desk if you put me in front of a single monitor, period. That has been the case since I first tried a dual screen in a professional setting and realised the benefits.
A related note is that I loathe garbage keyboards. If you make me type on some garbage rubber-dome with unbalanced and scratchy keys, I will not be happy.
I have been using a single 28" 4K screen for a while and I've never felt like I needed more pixels since. At 100% scaling there's a ton of space. No need to go through the minimize, maximize, switch, switch back usage pattern.
I've never understood why people are willing to put up with garbage gear either. I'm not talking about the computer itself, but the things you touch.
You sit at this machine and use it for 8h+ a day. Why shouldn't you be in contact with things that feel good to you?
Nice screen (or two if that is your preference), decent keyboard, mouse that feels good. I think it is important.
Mechanics don't use dollar store ratchets, do they?
I mean, a 28" is basically two medium-sized screens' worth of space side by side. But yes, quality on things you use every day matters a lot.
I 100% agree. IF you spend 8h+ a day at your workstation or computer use the best equipment you can afford to get.
>I will NOT be productive at a desk if you put me in front of a single monitor, period.
Give me a break. Software development has been going on for decades now on all kinds of hardware (how did all those Software developers survive all these years??).
You can be productive and get your work done on a single monitor, you just prefer dual monitors.
It's something where once you try it you can't go back.
If my company only gave me dirty river water, sure water is good and technically I'll probably survive if it's free of parasites, but once you have high quality filtered water you don't want to go back to drinking from streams.
>If my company only gave me dirty river water, sure water is good and technically I'll probably survive if it's free of parasites
A single monitor is not a health hazard.
For some reason people here are purposely confusing "I can't" with "I prefer not to"
It's not a health hazard, but it is a bottleneck in a very real sense if you want to keep more than one thing open (whether for reading, writing, running commands, or a combination thereof). It's not just a matter of preference.
I use a tiled window manager + emacs buffers, my 15.6" screen almost always has 2 applications open and 4 when I feel the need. Never had a problem running commands or reading documentation all at the same time.
OK, it's great that this works for you. Some people can't readily adjust to tiling window management, and barely anyone will switch to emacs (for reasons that would take a couple of paragraphs to summarise adequately).
Even I use a tiling terminal application, but that still leaves me needing another display for the web browser and work chat, for instance.
> Some people can't readily adjust to tiling window management, and barely anyone will switch to emacs
Then those are preferences, not need. I agree a second monitor should be provided if asked, but in no way is it a requirement. I'm not alone in my preferences either. I learned to code in Turbo C where the line length was _puny_ compared to even this comment box here. I was probably more productive back then.
> how did all those Software developers survive all these years??
With great difficulty, and/or by having printed reference material in a readily reachable position - think program listings, magazines, reference books, paper notes.
To me, the office mouse feels even more crippling than the crappy keyboard. I usually navigate through code by ctrl clicking on a symbol and then using mouse button 5 to jump back to where I was before, but my office mouse does not have side buttons.
On a related note, if you have never had a mouse with buttons on the side, I can greatly recommend trying it. Especially if you navigate through IDEs with your mouse and not the keyboard, i.e. you have one hand on the mouse and one on the keyboard and not both hands on the keyboard.
No one should be given garbage equipment to do this job. Doesn't anyone remember ergonomics?
I brought in my favorite keyboard before to the office .. They didn't appreciate the noise but MY productivity was top that day.
When I was working in an office I made sure to buy a mechanical keyboard with soft-ish switches (Cherry Brown, IIRC). People still commented on my fancy clicky keyboard, but no one complained (to my knowledge) about the noise.
Let me guess, kinesis?
hhkb pro2! It's not too bad, but you really appreciate the value of lubricating your switches when you're conscious about the sound!
If it's really that much of a problem, most companies will let you bring your own. Everyone at my last place did that with no issue.
It's been the norm for decades that companies provide workers with the tools they need to do their job. And good companies provide good tools.
If you're bringing in your own means of production, what is the company for?
My mouse and keyboard together are less than $75. A Visual Studio Pro license is ~$1600. I think I'm still coming out ahead.
>It's been the norm for decades that companies provide workers with the tools they need to do their job
I don't think that's true. Trades usually have their own equipment. At least for the small stuff on the order of keyboards and mice.
If your laptop is the means of production, just quit your job and work for yourself, you'll make loads more money.
Either that's true (sometimes it is!), and you should do it, or it's false, and the company is providing something after all.
Unless it's Evil Corp, where the USB ports are epoxy'd, and/or software protects against anything "non-standard" being plugged in :-/
In my team, our WFH guy wanted a particular keyboard, mouse, and docking station. I found him a big plastic bin to keep that stuff in when he's off site. Not as good as reserving a cube for him (which we don't have) but better than the crappy gear syndrome.
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
yeah, i would have preferred to be remote as a junior.
i think its just about being an environment where you're comfortable to ask questions - and some candidates also, maybe through insecurity are also unwilling to seek guidance.
Spot on
Overall great advice, however if it only works under the following conditions then it's not really usable advice:
>New hires need to join a stable squad, where senior team members can take time to onboard and support them
>Limit the number of junior employees to a certain % of your workforce: sounds harsh, but in a remote team, especially a startup, resources are limited. Don't stretch managers too thin.
These points makes this advice not-actionable because by and large, these two items are usually out of the control of their managers.
Yes, ideally a team would be well formed and competent prior to even posting a job requirement, but we know that's just not the way the world works.
"Don't hire unless you have everything in order" is great in theory but I've seen only a handful of teams in my near 20 years of experience that can claim to be in such a state.
This argument has really become "what will a workplace do to accommodate/help people one way or the other".
For instance, I personally prefer going to the office at least sometimes. My job satisfaction went down considerably staying at home for nearly 2 years. The fact my job had travel pre-COVID also likely had something to do with that. I enjoyed being around people, getting out of the house, etc.
I'm also a huge gamer, and am constantly on Discord or some type of in-game chat. So it's not like I didn't have people to talk to or wasn't getting any interaction.
My company is currently "Hybrid", so most who are near an office go 2-3 days a week. We're also pretty nationally and internationally distributed, so we're going to the office to be on a bunch of phone calls. The people I see at the office are my direct manager and a few cross functional co-workers. It's nice to be able to talk to them in person.
Now recently on a company town hall, the question came up, and our President said basically "We're going with the times/job market, but at the same time if I got everyone involved in Problem X in a room together it would get solved in days not weeks".
From experience, he's not wrong, but that sent me down another line of thinking:
- Are we willing to fly these people around to be in that room?
- If no, we should make it easier to do that.
- What resources do we provide to make at-home lives easier (monitors, webcams, better headset/speakerphone).
- What learning and/or help do we give to make people "better" at WFH or Office?
The last unique thing I'll say about me, I live 10 minutes or less from my office. That's a HUGE privilege, and one that has probably kept me here longer simply because I don't get stressed out over commute changes from weather, etc. I can't imagine what it would be like if I lived 45 minutes or an hour or more from work.
> "We're going with the times/job market, but at the same time if I got everyone involved in Problem X in a room together it would get solved in days not weeks".
I know you probably know this, but I hope your company leadership isn't falling victim to bias here, because a singular take like this implies that they think it's always better to get folks into a room... what if there is a person that, regardless of room, that your company never would've been able to hire in the first place, because you didn't support remote work?
Even if I accept a hypothetical ding to their effectiveness, I'd rather have a stellar hire working at 90% impact in a remote environment, vs not being able to hire that person at all... and of course, maybe that stellar hire actually creates 110% impact while remote, and 90% in-person, who knows?
Of course the obvious assumption is, that there are fewer stellar hires who are actively turned off by remote work, vs those that would be turned off/rejected by mandating RTO or banning remote work. That's a bet I'm willing to take, "going with the times."
> We're going with the times/job market, but at the same time if I got everyone involved in Problem X in a room together it would get solved in days not weeks
Have you tried getting those people in a virtual room together?
We did a lot of getting people in a room together at my work. We changed into virtual rooms during the pandemic and they showed themselves superior in almost every way. People have decent IO devices on virtual room, as an opposition to a random laptop on the real meeting; there is no software misconfiguration stopping the work; we can do the meetings on a shorter notice (no need to travel or even book rooms); people get less tired and zoom-out less, because they are in a familiar comfortable environment, instead of shoved into an improper room without sufficient ventilation.
There is a large downside in that only one conversation line is possible for each room. That is a serious tooling drawback, but AFAIK every tool has it.
I don’t necessarily think that working remote is the end all be all for jobs that can do it. But the benefits of remote is just too good to give up. No commute, cheaper cost of living, less stress, etc. Don’t get me wrong there are cons, but the freedom is just too hard to give up. Even if you are struggling at it work wise.
I am able to work remote and live in a state that allowed me to buy a house. If my company wanted me to go into the office I would be fine with that but I would need to be compensated in such a way as to offset the huge jump in cost of living that would cause me. I calculated it and it would take a net increase in my salary of about 30-40K to get me to come back.
I fear that WFH is becoming one of those hot topics divided down cultural lines: workers who enjoy a life without commuting, bosses and older employees who are suspicious of it.
I'm happy to work from home and it's a big benefit to me, but I won't deny it sometimes has its drawbacks. I just think the balance lies more in favour of remote work than colocation.
Hopefully there's a way to express that, yes, junior employees might benefit from some face to face support, but in such a way that doesn't imply everyone else must be chained to a desk forty hours a week.
I had the unfortunate experience of working at a cubicle farm in Atlanta, and what really got me were the chairs. Crappy monitors, crappy equipment, par for the course, but the chairs hurt. Chairs that have been sitting around for a decade, and management could not care less. Gotta sit in a chair for four hours at a time, got back pain, too bad. That’s the only job in my life I’ve ever just walked out on. It was absolutely awful.
Every company I've worked at will quickly bring you a special ergonomic keyboard/mouse, chair, standing desk, monitor stands, etc once you start complaining about carpal tunnel or back pain.
I've been saying this for over 2 years now, and especially seen this in action with teams in my own company which are a good mix of junior and senior folks.
- Junior folks on average spend longer being stuck before reaching out. We organized a few physical offsites where the whole team got together in-person and that helped reduce the friction quite a bit because folks interacted with each other outside of just "We need to get X done" which naturally happens because we never really got to know folks outside of "planned" onboarding/weekly/standup etc. Zoom calls.
- I learnt A LOT of Dev setup looking over shoulders of devs much better than me, be it interesting keyboard shortcuts, learning how to use tmux for split screen, ssh tricks, vim/emacs setups etc. which in the long term made me a better dev. A lot of this is not "mandatory" to know but every dev builds his/her own style of working by absorbing from those around them.
- Lot more friendships/mentorships/team-spirit were created in in-person settings than in remote where everyone feels a lot more "replaceable". Sure, some folks probably prefer it this way, but I'm certain I'm not the only person who wants to look at work as "just something I do to make money" but also a place where I build meaningful relationships and work with smart folks to build something great together while also having fun (which have also helped me when switching between companies and having folks I know already there).
Personally, as someone with enough experience building software, I'm at a place where working remote is the "best case scenario" for me because it gives me complete control of my time, but I absolutely see the tradeoff on the other hand for the folks on the other end.
I agreed with the claim before I read the article, but as I read the article, it convinced me of the opposite, as the article's arguments are really not that good.
That table of differences between in office and remote, for example, is ridiculously simplistic; much of the items listed on the right side are also important in the office. And not all of them are necessarily an issue remote (like timezones).
I didn't read the article, but the title alone is obvious.
I am in favor of flexibility in the work place. Some people work better remotely, others work better in an office. We should let people do what's best for them.
I like working remotely, but I can't imagine being fully remote with my first professional job out of college. The foundational knowledge transfer that happens in person is invaluable. Not only that, but I find even now, as a more senior engineer with many responsibilities, at times it is hard to feel motivated when I'm fully remote. That would only be amplified as a junior engineers when you aren't a stakeholder in any projects. How can you feel inspired to want to build great things if everything is so disconnected and impersonal?
I suspect this is much better at companies that are permanently remote - they hopefully have the infrastructure in place to properly ramp up and train junior engineers. But for companies that have transitioned to remote recently, the old way of onboarding a junior employee won't work any more.
Supporting jr engineers comes with some specific needs IMO, regardless of remote or onsite :
1. Senior engineer time is the main constraint, in the sense, more experienced engineers need to be available to mentor them and break down tasks, concepts etc 2. clarity of purpose / problem being solved (related to #1) 3. feeling safe, and ready to ask questions - have some kind of 'office hours' on a daily basis
In an office environment , there are opportunities for hallway chats, in addition to physical meetings (where there is increased incentive/pressure for the jr. engineer to bring up questions).
The remote jr. engineer also feels left alone, since seniors are busy. Seniors usually have tenure, so know the background, and are empowered with lots of info.. they can plough ahead, the breakdown of tasks is relatively tractable.. but not for Jrs.
An Org needs to create a daily 'win' potential for them to take them forward .. instead it becomes for each his/her his own (shell).
I’ve been permanently remote for almost a decade. I will never go back to working in an office. Despite all this, I actually prefer working in an office because it creates team camaraderie you don’t get remotely, but commuting is so horrid that it’s not worth it. Commuting, more than anything else, makes me a hardliner for remote work.
I think you can absolutely onboard people and develop juniors remotely, but you have to be intentional about it. So many companies I’ve been at in my career did onboarding or OJT by giving out tasks and letting the employee organically learn from those around them. This process fails horribly with remote work, especially for juniors. But if you intentionally onboard people, focus on remote first, have a reading list, assign an onboarding buddy, and are up front about expectations and timelines, it’s completely workable and I’ve been at companies successfully doing this for years before WFH was commonplace.
The worst mistake I think you can make with people is believing in an objective reality.
Take onboarding a team member. You see a bunch of different approaches to this. Some people like to simply throw someone in the deep end. Sink or Swim. This is an easy trap to fall into because it requires less effort. It becomes incredibly easy to write people off with no investment. This is often couched in language of like "top performers will thrive".
Another approach is more hands-on. Small tasks to begin with. Tasks with a theme built to acumulate knowledge and experience so someone can ultimately take ownership of something. This requires more effort but (IME) works way more than the "sink or swim" approach.
The problem with remote work is that it becomes easier to fall into the "sink or swim" trap. Remote employees more easily become abandonware.
You can write this off and say it's a failing of remote work but really it's a failure in leadership.
Yeah, this tracks.
The casual interaction you get in a traditional office can be formative. Mentoring is easier. You can absorb norms better, and integrate better, especially as a brand new worker.
We are a 100% remote team, and we've been very aware of this in hiring - which is to say, we haven't hired any "baby devs" at all.
This idea feels intuitively true but it would be useful to see some actual measurement, especially because "fail" is a strong word. The article neither defines it nor does it provide results that would demonstrate it. In short the article is much more speculative opinion than demonstrable outcomes.
This isn't just nitpicking. If the intuition here is true then it's important to understand the extent of the problem in more quantifiable detail. The general up skill table doesn't do that, and their simple survey shows a pretty even split, so nothing conclusive there.
As a suggestion, the article lists benchmark developments where new hires progress from up skill to simple changes to regular work. This seems like a good starting places to measure how long it takes new hires, remote vs. onsite, to progress through that process.
This is just fairly obvious and I've probably posted something about it before in HN. It's the same reason in-person school works much better than remote, students and junior employees need fast feedback while still giving them the room to work independently.
Real world example, I gave a junior engineer a bug that should take a day to research and 3 lines of code to fix. If I'm sitting a few desks away and I hear them furiously banging away at the keyboard, I might come by and ask how it's going.
Today in the remote world I have 2 options, needlessly badger the junior engineer or wait for a big PR that I'm going to have to reject or ask for significant rework, both of which are going to make that person feel a lot worse than if I had just walked by, asked to grab a coffee and talked about it.
You could also preface with "I think this should take a few lines of code to fix - I'll let you look into it but if you're feeling stuck by 3pm, feel free to Slack me with what you got so far and we can pair"
Question for anyone who's had to onboard/train Jr's in a 100% remote environment, what's worked for you? How do you maximize their chances of success? What are some common pain points?
This has been an issue at my org and we're having a hard time improving it.
When I started, my direct manager took me on a walk. We visited about 20 different desks and had introductions and impromptu chats with various developers and product managers, putting the names to faces and expertises. Not all on the same team either, some were just people he knew well from various projects. This was a huge jumpstart for an introvert like me. In an online-only Slack environment there is the private team channel, and the big scary common channel where you are afraid to ask questions unless you tried to solve the problem by yourself first.
Maybe a better online solution would help, a-la some magical VR space that Meta comes up with.
Or documentation. Just a list of slack channels and what they are used for is a big help.
Remote working requires effort too.
Be clear on what is expected. Have weekly deliverables and weekly team meetings. Don't micromanage them or have them meet each day. Get them off to a good start (give them all the gear and info they need to do the job) and be very explicit in what is expected. Give them a few weeks to get acclimated, then hold them accountable.
Whether they are remote or in the office, they can be successful. If they are getting their deliverables in on time and do things the way they are asked to do them (follow these simple rules)... that's all that matters.
And when I say follow the rules, I mean that I don't care if they use vim, emacs, nano, Wordpad, Windows, MacOS, Linux, etc. But I do care about how they submit a merge request and whether or not they PGP sign their commits.
For me it was a lot of pairing/mobbing on tasks leveraging the tools available. e.g having the driving person sharing their screen and using tools like Jetbrains Code With Me or VSCode LiveShare for the coding aspects.
Biggest pain point was the flexibility that was required with lockdowns meant sometimes the senior members were occupied with parenting responsibilities but we tried to ensure that the junior member had someone to pair with most of the time.
I don't know if they're more likely to fail in a company that understands how to work remotely. Although the article does seem to suggest this. My guess is that this is more a product of companies recently going remote and not understanding how to do it right.
I've been working mostly remotely for the last decade, both as a junior and now as a senior and this hasn't been my experience at all. In fact, I'd argue the opposite is perhaps true.
I tend to define a junior dev as a dev who needs a decent amount of handholding where as senior devs are expected to be self-sufficient after a brief onboarding period.
If you're a senior dev and you're not self-sufficient then remote can be really hard because you have to constantly pester other devs for help over Slack and Teams, where as in the office asking someone for advise can be done less formally. What I've found is that it's really obvious when a senior dev isn't quite as senior as they probably should be when working remotely.
Junior devs on the other hand should be expected to need support and there's no reason they shouldn't be able to get that support if they're working for a company that has a good remote working culture. Ideally every junior should have a senior dev mentor assigned to them and they should have Slack channels in place where they can request help. Code needs to be reviewed by senior devs and ideally you should be working with them to solutionise before they even begin to write their first line of code.
Still, I think most junior devs would probably benefit from some office experience early in their career. I'm not sure your first dev job should be remote, but I don't think junior devs should feel they're any more likely to fail working remotely as they would in the office. As a junior dev you can probably improve your chances by asking what support you'll be given as a junior dev during the interview process. You should also feel confident to ask for help. At the end of the day if you're not given the support you need as a junior dev, that's not your failure, but your employers.
What companies want to avoid is to admit that commuting is work. These are hours dedicated to my employer but I am not compensated for them, and even worse they are not accounted in the total work hours of my day. My 9-5 job is really a 7 - 7 job.
I've speculated for a while that remote-first will reverse the traditional ageism of the industry, giving older developers a distinct advantage and making it harder for younger developers to get their footing.
(I am not saying that's good, just observing.)
I'll restrict myself to the software/IT sector as that is where my expertise is most prominent.
Oboarding and successfully integrating juniors is fully dependent on having real seniors (not juniors that you sell as seniors) in the company and budgeting them substantial time (>25% minimum per trainee supervised) to support this process. This further assumes that you had a decent selective hiring process, as no training/onboarding will compensate for the senior's productive time for complete misses.
Isn't this an editorialised headline? The actual headline is "Micromanagement vs. micro-tasks: how to set junior employees up for success in remote"
Surprising no one who has been paying attention.
I don't think being junior is the issue here.
Many people start their dev career with OSS and that was remote before it was cool.
They have a asynchronous remote first culture from the ground up.
This can't be said for the average company. Those have mostly no processes and getting up to speed at the water cooler mentality. No shit that people with little experience fail there.
Are seniors who are hired remotely in a company productive almost immediately from day 1 with no orientation?
Good article, bad HN title. Of COURSE any new employee, especially someone with less experience, will flounder if not given proper support. The prescriptive advice here is also key. Give small bite size tasks, check in often!
How is it a good article when the data is garbage?
Judging by the comments here, most of the comments posted here are not even by those that are 'senior' themselves or are self declared 'senior' and are certainly on someone else's payroll.
Perhaps companies are doing remote wrong? Has this been the experience of companies that are historically all-remote (Basecamp, Gitlab, etc.)?
Work at a company that's not going to PIP you doesn't regularly PIP people. Opt out of the rat race and work at a smaller company.
I knew a company that would make junior employees keep a permanent zoom window open with their manager. Sounded terrible for both sides.
Its worse than this. Companies going fully remote are less likely to even engage with the idea of having juniors because of this gap.
The trick here is to have a senior person pester them constantly for voice calls and screen sharing sessions (both ways).
The insights could be valuable if they were introduced as an opinion rather than facts validated by a quick poll online
Very hard to mentor these days when average turnover is 24 months. I don't know the solution.
I work remote now and love it, but I can't imagine doing this straight out of college.
So more discrimination in favor of seasoned employees to come
today is the first time i've seen 'remote' used like this in a sentence
Site is down - did we kill it?
While I can understand some of the arguments made about juniors getting some extra benefit from having everything close to hand, the sheer pace of the hit pieces against remote the last month or so is hilarious and very telling.
Slite is a SaaS company providing tooling for remote work and is a fully remote company itself, all of that since well before the pandemic. So I think calling the article a "hit piece against remote" is unwarranted in this case.
Disclaimer: I have an acquaintance who works there.
Founder of Slite here, your reply is spot on, we try to be as honest on the pros and cons of remote when we think internally of the future of this market, and when we share our research or insights outside.
It's not all pink, and our mission is very much to remove the roadblocks, so we need to acknowledge the issues that prevent remote from being seen as a no brainer by some teams today.
Hey there, just wanted to say as a remote junior dev who has been at it for about 10 months now, that I appreciate the article a lot. These 10 months have been the most difficult of my life, professionally speaking. I was assigned a mentor, but there were no training exercises, or "easy bug fixes / small wording changes to make, so they can focus on learning the workflows" quite the opposite actually, and no processes explained or documented anywhere.
I'm a bit older and I couldn't imagine going through this as a fresh grad out of college. I would have loved to have had my hand held in my first days as a dev. I was constantly demoralized by not having the domain knowledge (and not having any comprehensive documentation to learn it), being assigned complicated stories (that even the mid/senior devs had trouble with), and by not having anyone just regularly check in with me and make sure I was doing ok. I would like to continue working remote indefinitely, but man it was really tough starting out as a dev remotely. I say all this to say I do think it's possible to successfully onboard a new dev remotely, but there has to be a plan and resources available to do it and I think your article is a good template.
Absolutely, we onboarded multiple junior folks over the year, but always put special care there, it needs a very different approach to any new remote teammate.
Out of curiosity do you foresee Slite hiring more junior devs in the near future? Sounds like an awesome place to work that's more aligned with my goals than my current place of employment.
I’m a fellow remote juniorish dev (I just passed one year of working in the industry since graduating college). I relate to everything you wrote here.
It's rough out here! I'm still very grateful to be in this career and things are (slowly) getting better. If I ever end up in a senior position I will insist on better onboarding practices for junior devs if poor ones exist.
Their evidence that leads to a bold font subsection of "Why junior employees are more likely to fail in remote" is a linkedin and reddit poll with <200 respondents.
I agree this isn't a hit piece, but it is definitely lacking substance to arrive at a controversial conclusion.
It's very obvious too... of course junior employees don't do as well as veterans when you take out the entire physical support system. Like.. duh? What you need to solve this is merely competent managers/mentoring culture.
You say "duh" but this is pretty controversial and there's a big push for remote work right now. I'm "pro remote" - my company is full remote, for example. I also think I'd have a much worse career if my first job hadn't been in an office, especially such a cool office with great coworkers to chat with. Being in an office was incredibly motivating and exciting as a junior developer.
Being in an office also made it clear how much I worked. I was there on most weekends and people noticed.
I'm not saying that that's more important than the benefits of remote, but people absolutely do act like it's a black and white scenario.
Conversely, I despise my first in-office experience and it completely turned me off ever going into an office ever again. It was incredibly demotivating to go there when I didn't actually need to - and the idea of 'watercooler creativity' is something I found to be a lie in an office environment. I've developed a real hatred for in-office work as a result of seeing how unnecessary it was when I went remote for two years and was just as productive.
Of course, I'm sure many people have had similar experiences to both of us. I'm only saying that there's a lot of grey area here.
> What you need to solve this is merely competent managers/mentoring culture.
I see this claim thrown around frequently as if finding great managers or building a great management culture is an easy thing to do. A great manager in engineering needs to be good at engineering and good at management. It's hard enough to hire for one or the other, let alone both.
Absolutely. And giving managerial duties to your best developers is a double-edged sword that needs to be wielded carefully.
Can you provide some links on how to support junior employees while totally remote? I've struggled mightily with it and a lot of the most pro-remote teams I'm familiar with most don't hire juniors
Maybe I should make a blog post... but here are my suggestions:
1. It is now vitally important to have a clear, mutually agreed upon 30/60/90 program the junior is aware of. These need to be measurable, achievable goals, with specific seniors to reach out to to accomplish. The seniors should also be aware and consenting to play as mentor.
2. Senior engineers should proactively pair program, review, or otherwise attend to the junior as much as the junior is comfortable with. (If the junior's discomfort with mentorship gets in the way of their growth, we need to manage the junior. This shouldn't be mistaken for a junior that doesn't need the mentorship and would understandably find this intense attention to be smothering.)
3. The entire team needs to be aware of onboarding the junior. Expect velocity to slow noticeably for a little bit, until the junior is able to do minor bugfixes and tool building, then slow again when the junior takes meatier projects like features.
It takes more than competent managers and a traditional mentoring culture. Everybody has to be as receptive to new employees in remote as they are to new employees on site. That is remarkably difficult to do when, at best, you see the new employees during meetings. When people do make a point of reaching out to remote employees, it also tends to be more artificial than organic.
It's very obvious that people do better getting introduced to new environments and cultures when they're physically present.
Imagine thinking that a Zoom meeting with a few french people is the same as moving to Paris.
My experience is that any comment on this site that includes the words merely, trivially, obviously, or simply is best ignored, including mine.
A few people have commented on the hit pieces in the UK media. The Telegraph have had an anti WFH article every day for the last month. Definetly feels coordinated!
It's just a popular topic that people have lots of different views about and are eager to discuss all the time.
Randomness frequently generates uniform subsequences that feel like they can't possibly be random.
if majority of the people above you exist to ensure a butt in the seats policy. then yeah you ain't wrong. remote work is just about workers doing their jobs remotely. it signifies worker empowerment - right now the workers are in control. and the corps hate that.
PR firms and middle managers are working over-time to ensure that we go back to the previous model where we all commuted in daily. But the labor market is dictating things atm.
Junior workers will always struggle at a place that doesn't support Juniors to find their own way. some people picture juniors as half seniors. forgetting those roles are completely different in their own way. It's the same reason mid level developers are so much in demand
I think it's an extreme stretch to suggest that remote work is some sort of worker empowerment. It's literally just different. The idea that it somehow invalidates the job of middle managers is a little absurd. If anything it makes them more important and valued in an environment where communication is more sparse and man management more difficult.
More likely articles like these are just a response to the immense swell of pro-remote sentiment that's been growing over the last few years.
This article was published by a remote-only org whose product is tooling for remote teams. It's not some anti-remote hit piece.
Yep, they are trying to manage remote workers the same way they used to 'manage' in person workers. Clearly they are not the same. We really need to shake this "if you can't see them, they're not working" and "Collaboration is best done in person" mindset.
Maybe there are “hit pieces” because there actually are downsides to working remote? For the average HN user it’s probably great, but there are plenty of reasons why it could suck. Personality type, job type, living conditions, internet options, etc.
Now go back 10 years and imagine trying to raise money for a startup that was entirely remote. Or being an employee that refuses to work under forced-commute conditions. The tech industry and VCs have always been extremely anti-remote, and still are.
I have a working theory for why this is, which also explains why tech companies hire unsustainably. But that’s a much longer post.
My guess is now that BlackRock and other funds already bought out all the empty office buildings at a bargain, they'd really like the demand to come back so they can sell them off for twice the price.
Perhaps because people are starting to draw their own conclusions after working remotely for 24 months?
Good. I'm tired of having the presumed wonders of WFH shoved down my throat. It's great if you don't want to work and instead slack off at home but I don't believe this productivity increase myth a single bit.
> It's great if you don't want to work and instead slack off at home
what? do you think those of us in remote roles just....dont work?
"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.
Please don't swerve into off topic flamewar like this. I didn't read it closely, but the GP reads to me like normal internet conversation. That doesn't mean the comment is right, but there's plenty of room for an exchange of views here.
Instances like this are where the following guideline comes in handy – if you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html, we'd appreciate it:
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
The strongest plausible interpretation is obviously that the GP was making their own point about remote work based on their own experiences and not proclaiming personal superiority over you.
We detached this subthread from https://news.ycombinator.com/item?id=31894409.
> It's like you didn't even read my post, just looked for the hook to drop in and proclaim your superiority.
Seemed to me it was just a counter-point to your post. If you don't have anything productive to add, that's fine, but resorting to personal attacks doesn't really make your argument/viewpoint look better.
From my own personal experience, I'd mirror what the previous poster said. Most of the top performers in a remote setting (at least with software engineering) are usually also a top performer in an office setting. Does that mean there are not outliers? No.
But they did read your post, as shown by their provided reasoning.
Your follow-up seems to have disregarded their entire response, resorting to ad hominems rather than providing any justification of why you disagree. From my perspective, your response is an example of the exact opposite of what was written, that being "bountiful blind arrogance".
For what it's worth, I largely agreed with their assessment that a top performer in a remote setting is highly-likely to be a top-performer in-office as well.
The set containing top-performing engineers that are effective in-office is a subset of top-performing engineers that are effective remotely. While there are certainly exceptions to this, the article seems to support this assessment when it enumerates the list of things that new-hires would need to learn for both in-office and remote scenarios:
> As you can see, junior remote employees are doing almost 2x the upskilling they're doing in the office. It's not their fault they are struggling to get up to speed as quickly.
I pointed out what I’ve seen. It’s not a personal attack to say “generally people who do poorly in a remote setting lack discipline” I then provided several methods we used to increase discipline (we developed over years of trial and error).
I think it’s arrogant to dismiss others experiences, particularly someone who’s managed / lived this experience for a decade (and helped setup multiple remote offices and teams). I never claimed superiority, I did point out a skill that’s often lacking in those with poor remote performance.
Remote work can affect a variety of people in different ways so a blanket statement that classifies people who struggle with remote setup as under-performers anyway comes across as too judgmental and lacking in nuance.
There are a variety of possible reasons why a person can thrive more in an office environment compared to a remote environment (and vice versa) such as maybe they have a poor remote environment due to a lack of funds. Some people might have comfy homes and a good support system at home while others may have cramped apartments and a poor home environment.
Also, the blanket statement can also be used inversely such as "generally people who do poorly in an office setting lack discipline" when maybe the person doesn't just do well in an open office or lives far away from the office with a difficult commute.
I think it's simpler to state the some people thrive in an office environment and other people thrive in remote environment for a variety of factors such as their personality and personal environment rather than to condemn those who don't thrive in either set-ups as "lacking discipline".
HN holds that mythical lone^W solo^W remote hacker in high regard.
Kinda ironic given most people I know who fit this description dislike the site.
You say that
>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 tasks
and they say that in general those people are already the top performers.
When you think about it, that shouldn't be surprising. People who know how to succeed in one environment also know how to adapt and succeed in another. That's to be expected.
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.
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 will lend itself well to both in-person and remote work, but I suspect the effect is even more prominent in asynchronous work where there's less oversight and less opportunities for someone to spell things out.
Relating to the article, junior employees are often at a disadvantage regarding taking initiative because they simply lack the tacit organizational knowledge to run with a task. They may not know who to contact or the full context of problem areas. This makes them more reliant on mentorship, which can be more difficult in remote work.
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.
I think the fact that OP and others are taking it as a personal attack is at least a sign that we should also be mindful in how we write things.
The bountiful blind arrogance I have come to expect from threads like this on HN.
I didn't read it that way at all. The commenter was simply relating their observation of how remote works well for some co-workers, but not for others -- as they see it.
That's all. It seems you're reading way too much into that observation.
Junior employees working remotely needs some guidance.
SEO Spam. Junk article based on a reddit poll and conversations with colleagues.
"junior remote employees are doing almost 2x the upskilling they're doing in the office" based on what?
Not a counterpoint, but something to keep in mind: if a junior employee requests to work remotely, please don't force them to come in-person anyways. People need varying levels and types of mentorship. Signed, a junior employee :)