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.
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.
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.
> 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.
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.
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.
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.
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.
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!
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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 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.
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.
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.
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.
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.
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.
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.
>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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
> 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.
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.
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.
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.
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
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).
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.
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.
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.
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.
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.
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.
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
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.
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.
> 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
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.
> 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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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!
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.
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 :)
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.
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.
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).
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).
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.
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.
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.
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?
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.
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.
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!
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.
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".
> 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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
...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.
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.
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.
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.
> 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.
"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.
> 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.
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.
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.
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'.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
369 comments
[ 3.9 ms ] story [ 363 ms ] thread1. 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.
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.
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.
Imagine thinking that a Zoom meeting with a few french people is the same as moving to Paris.
Disclaimer: I have an acquaintance who works there.
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.
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.
I agree this isn't a hit piece, but it is definitely lacking substance to arrive at a controversial conclusion.
I have a working theory for why this is, which also explains why tech companies hire unsustainably. But that’s a much longer post.
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
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.
what? do you think those of us in remote roles just....dont work?
Randomness frequently generates uniform subsequences that feel like they can't possibly be random.
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.
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.
Engineers are expensive, and every minute they spend fighting with equipment rather than being productive is costly.
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.
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.
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.
It can break my god damn wrist joints if I have to use it all day. Speaking from experience.
If they are making this easily fixable mistake, imagine what else they're doing poorly.
[1]: https://jnd.org/emotion_design_attractive_things_work_better...
Low morale = lower quality of work.
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'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?
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.
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.
A single monitor is not a health hazard.
For some reason people here are purposely confusing "I can't" with "I prefer not to"
Even I use a tiling terminal application, but that still leaves me needing another display for the web browser and work chat, for instance.
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.
With great difficulty, and/or by having printed reference material in a readily reachable position - think program listings, magazines, reference books, paper notes.
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.
This is true, but the learning process is much more enjoyable when you are correctly equipped.
If you're bringing in your own means of production, what is the company for?
Either that's true (sometimes it is!), and you should do it, or it's false, and the company is providing something after all.
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.
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...
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.
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.
This is not the star-studded retention policy you think it is.
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.
" Everything is “reservable equipment” of garbage monitors, windows keyboards, and 400 dpi mice."
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.
I don't like training and mentoring people. I'm pretty good at it, but I try my damnest to avoid it now.
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.
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.
Money is why a lot of young devs quit, but it’s not the only reason.
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.
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.
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?
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.
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.
What do you mean by this? They were arrogant?
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.
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.
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).
It's true that the barrier is a bit higher remote, but it's not unsurpassable.
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.
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 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.
That being said I think it can probably be improved while still remaining WFH, for instance by more actively chaperoning newbies.
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.
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
* 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.
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.
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.
Juniors aren't born knowing any of those things.
[0] https://codahale.com/work-is-work/
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.
This has been an issue at my org and we're having a hard time improving it.
Maybe a better online solution would help, a-la some magical VR space that Meta comes up with.
Remote working requires effort too.
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.
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.
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 am not saying that's good, just observing.)
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.
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.
Good luck at the new job!
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.
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.
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?
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.
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.
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.
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.
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 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.
I have a hunch that as more work shifts remote, new ways of working will evolve.
What's old will be new again.
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.
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.
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.
If you've discipline and commitment you can make anything work. :)
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 experience is that unsupervised education is worthless.
In other words, they are not at all just learning from a laptop.
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.
I suspect it works for readers, not audio consumers.
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 ;-)
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.
What.
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.
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.
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...
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.
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
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 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 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 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.
So it cuts both ways.
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 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.
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.
I've come across people that are very good at getting "help" on their work to the point that they do very little work.
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'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
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.
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 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.
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.
...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...
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.
"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.
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.
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.
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.
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.
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.
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?
If you’re engineers are constantly hitting deadlines, probably it’s greenfield development or the problem space is simple
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
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.
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.
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.
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.
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.
Probably, actually, I'll end up renting a desk out of home somewhere nearby.
The pendulum may have swung too far, on that I'll agree.
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'.
But now in theory, at least, I don't have to make that compromise.
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).
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.
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'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.
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.
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.
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.
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.
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.
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.
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 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 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 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.
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.
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.
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.
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!
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.