Accordingly, during the pandemic I think it was mostly the less experienced engineers suffering from low productivity and lack of confidence (which feed into each other).
Even pair-programming with my fellow juniors was both more productive and more educational than a rubber duck[1].
I had the opportunity to sit down to dinner with some very junior devs at a family gathering, recently, and to hear of their isolation due to remote-work broke my heart. They simply have no idea what they're missing.
I know mentorship is important and spend quite a bit of time on it everywhere I work, including with pairing. But the costs to many senior people’s productivity are very real and can’t be stated lightly. Remote work has been a godsend, previously I would do my best work behind a closed office door, in the back of a company bus, or after hours at home and it’s like having unlimited access to that zone.
Even now I find it incredibly off-putting to have somebody looking over my shoulder when I'm trying to work, to the point that I basically just can't. People have asked to watch me do something, and my response is that you can either watch me, or I can do it, but not both. It's like Heisenberg Uncertainty for work output.
> trying to verbally communicate something that would be better done in writing/code
> somebody looking over my shoulder
At the risk of sounding flippant, none of these activities comprise pair programming. What's better written should be, and the simplest way might be "can I just show you?" or, from a particularly well-atuned pair, "would you mind showing me?"
"Waiting for someone else to type," in my experience, is either a good opportunity to finish a bit of thinking that'd I'd put off moments prior, or else premeditate on our next move. Sometimes, however, the typing is, as you alluded to, an attempt to communicate something, in which case watching them type is roughly equivalent to listening to a person in conversation, and therefore an opportunity to learn, catch bugs, etc. In other words, when I am pair-programming I am never waiting qua idling.
And, lastly, I completely agree that "somebody looking over my shoulder" is an unnerving condition to code under. As purely ergonomic concern, "over one's shoulder" is not a healthy position from which to operate a computer. ;)
But, seriously, it's not pair programming if you're not on equal footing (seating?), with equal access to mouse, keyboard, and monitor. Don't stand for someone standing behind you!
I am sorry for the unpleasant experiences you've had. As a practitioner, I would not have subjected you to them. I am, frankly, vicariously irritated with whomever did.
Also the way I tend to code is never linear in a way that anybody else could follow. I write something, edit it, throw it away, put it back, rename it, hack out something I _know_ is buggy so I can see how it looks, and basically "thrash" my way to a solution that I like. That makes it essentially impossible for anybody to follow in real time, and having them try to point out errors would be counterproductive. In the later stages someone could help polish it, but even then I think it'd mostly be a waste of time.
That's before we even get to things like dealing with interruptions, or answering other questions quickly. Ideally interruptions don't happen, but in practice they do, and I don't want to be wasting someone else's time.
There's a lot I liked about XP, but I still think that (for some people) it's just a great way to make two devs produce the output of one intern.
It's certainly not.
Sounds like my dream job.
Junior engineers need help as the same rate they did before. They still need to ask for help. Remote work lets it:
- happen asynchronously & synchronously
- creates visibility of asking for help
- reduces this weird shame around it
- allows us to correct bad answers
- allows people to learn from others with the same questions
- self manages by capacity because the people with time are the ones that can answer questions
- produces an awesome collection of analytics: how many & what questions are being asked by who, Who is answering questions and about what?
What kinds of things did you think about to transition to where you are? How did that transition happen?
You can and should still have those 10 second conversations. We've got Slack huddles, screen sharing, VSCode Live Share for more complex pairing... the tools are really good now.
That said, I tend to agree, a remote culture that doesn't respect the need for teaching and mentoring is going to be bad at it.
I had more problems with junior developers who think they're senior developers (some experience, high-confidence) bc they don't ask for help when they should.
Then I give them a ticket and say "if you get stuck, let me know"
For the first little while, I am super responsive with them and answer everything immediately and eagerly.
After a while, I start to wait about 5-10 minutes before I respond to questions. Usually they figure out the answers before I even get back to them in these cases, and then I get to praise them for it.
I stumbled on it by chance when I failed to make it to a client meeting with one junior dev I was leading. He was counting on my presence to support him, we had already discussed it before. But I got caught up last minute and he decided to go alone. And I know it was hard for him, but everything went fine. And from then on he was a lot more confident in his day to day.
Weeks, even. It took me a while to come to terms with the fact that this is the majority of my value to an org now. Not so much in my IC abilities, but in the ability to save endless amounts of time for lesser experienced folks.
So interactions with the project team is fully remote.
I am sure even pre-covid many MNCs might have a similar structure with members spread across different location. Though coming to office, but project work happens remotely. Also have juniors joining the team.
It might be difficult for juniors to get started. But not impossible to handle.
The problem with “difficult but not impossible” is that it requires special personality types to handle it.
Some people can do it, but now you have a secondary problem in that you need to find a way to filter those people in the hiring pipeline. You also have a risk of hiring people who can’t handle it and having to cut them and re-hire.
This is why most “difficult but not impossible” conditions are reserved for special exceptions but aren’t useful for general policies.
I agree, and I don't see a problem with it.
> [...], but aren’t useful for general policies.
offices are just optimizing for the loudest and more social people, this is a consequence of managers tending to be like that, I don't think that approach is useful for general policies neither.
but wait, that means changing cultural and such, that's not easy is the response I often get to this, to which I say preemptively:
That I would agree with, because the US business cultural is surprisingly stiff to changing things that would have favorable impact to workers, but that is IMO a different and separate discussion to the fact that this is a readily solvable problem.
"Give guidance before" is about as good a "just don't make mistakes."
"Hey, I need you to take a look at #154, don't worry about the issues Jeff is mentioning, we just need you to fix the error in the form and write a test. If you run into any frontend issues, work with Mike, I already let him know you might be coming to him.
This is basic manager, Sr. Developer stuff.
I've been in an environment like this, and it really burned me out.
People broke docs faster than I could fix them, and it was an accepted part of the development process.
My conclusion was that fixing the docs was simply a waste of time. My resulting despair for the software and the company surely destroyed my productivity. (I'm not saying this is a valid excuse; just an explanation.)
What did you do instead? It’s certainly frustrating to have people breaking docs that you fixed. But what else is there. You just figured it out on your own and left the docs broken?
I concluded that it was a fatal and unfixable flaw in that community / product / company. This sapped my motivation, and I'm sure resulting burnout was a factor in eventually being laid off.
One thing that sucks about being a senior dev is you're subject to Cassandra [0] syndrome. In a tight labor market, that gets painful.
I would have loved to have been working in an environment where I could work with the system maintainers to fix their docs collaboratively but alas it was more of an "I'm busy go away" type environment.
I think this type of dysfunction was fairly common during lockdown WFH.
In office, remote, whichever - I've been ignored. It took a while to learn to ask questions.
People will help, but "the squeaky wheel gets the grease", and all. There's movement [or an attempt] implied with this.
The locality doesn't matter, effective communication can exist in either.
It's possible to foster a remote environment where Juniors do ask questions - I've worked in several. As such, I'm skeptical of this 'Think of the Juniors' concern. It's manageable.
It's also worth pointing out, Junior and Senior aren't diametrically opposed. It's relative and nebulous depending on context.
I'm a Senior Architect, but know very little about the specifics of our network devices - for example. I'm Junior to our 'Network Engineering' team, making an Ouroboros of Seniority
Recognizing where strengths are helps greatly. Productive environments have their Seniors evangelizing this awareness
The top comment is saying how to manage it. TFA isn’t saying no remote work, it’s saying less frequent communication. That doesn’t work in all cases. Struggling for hours without getting much done or understanding more isn’t effective for productivity or learning by definition. These cases can often be prevented with quick questions. “Send me an email, I check it every Monday and Thursday” doesn’t support that.
This can be prevented without (net) more involvement... with better use of those existing sessions, perhaps splitting them.
The definitions on that aren't clear - the comments around seem to expect the worst, absent employers abound.
I expect a fairly guided mission, with reports on findings. Questions both ways, Socratic or not.
But on the other hand, I think that value comes from more than the persistence alone: it depends a lot on what you hope to get out of it. And I also say this from experience. Banging my head to “make it work” has almost always been an enormous waste of time and effort, but to “learn how/why it works [or not]” has been the exact opposite.
Learning to do things properly by banging your head against the wall is great. But only if you feel like you have the leeway to figure out how to do things properly. Without that leeway, you need the space to ask for help.
Don't necessarily blame the developer - there's a _lot_ of pressure from the PHB that doesn't understand the difference between HTML and Linux to "get it done right now" and they think (for no reason) that nagging somebody else to do it for you is the most efficient way to do that.
Yes. This "get it done as fast as humanly possible whether or not you actually understand what you're doing" is the most detrimental attitude toward beginning software developers I can think of. "Going down a rabbit hole" is a dismissive way of saying "actually figure out what the computer is doing" which is what actually makes you valuable to the team. If you just wanted somebody who can type in what they're told to type in, you're wasting a lot of money hiring computer science graduates.
Sure, reinventing the wheel every time is a valuable experience, but it's not efficient to relearn how to do things every time.
This is like letting toddlers struggle to learn how to tie shoes themselves, sure they will eventually figure it out, but it's better to just teach people have to do the basics, and let people bang their heads against hard problems.
Junior engineers aren't toddlers. Hopefully they're a lot more competent. Nobody hires toddlers to do work.
Here's my analogy: if you want to learn how to ride a bike, you've got to take off the training wheels, and sometimes that means falling over.
Not every problem is going to take junior engineers days to solve for themselves. I was stating an upper bound of how much rope to give them, not an average.
Besides, what happens when the senior engineer leaves the company? Sometimes "institutional knowledge" walks out of the institution.
It sounds like you are trying to address issues during mentoring that should have been addressed during the hiring process. In my experience, all the juniors I've worked with come in with the idea that they can solve every single issue themselves, and part of my job is to show them how wasteful that is, that a simple question can save the whole team days if not weeks worth of time.
If someone walked through the door who is not enthusiastic about solving technical issues themselves...your hiring process needs work.
Agree, though sometimes the hours of head banging will benefit greatly to the skills of said junior.
That aside, everyone should be encouraged to ask to company's developer forum (slack channel). That way, if the senior that's responsible to train the junior is busy, other less busy senior can help.
You can solve this, and many organizations have. It does mean re-thinking expectations around onboarding and the role of mentorship in the company though
Some of them are very independently-motivated and self-contained, but inexperience means they are still prone to rabbit holes. Others really will sit on their hands until explicitly told what to do, which doesn't mean they're bad or lazy, just that they require tight feedback loops.
In both cases, it seems like quicker feedback cycles do more good than harm.
Building an environment where junior engineers learn how to find things out on their own and when they need to ask questions is a company culture thing and has very little to do with remote vs in-office.
This is why I more or less never go and "do my own research" before asking questions for hobby projects. I've gotten stuck in too many research rabbit holes and (hopefully) have learned my lesson. Ask first, then get mired in irrelevant details if the response to my bizarrely unique question is crickets.
Also this is trivially solved through checking on the person twice a day and doing call reviews, thus making it at most a few hours.
Actually, this is a regular part of successful remote team building.
Meanwhile making the junior approach unannounced is counterproductive. I for one would rather have my interruptions at least scheduled if they can't be avoided.
People still ping me frequently for a "quick chat" which is rarely quick, tho.
Also not reaching out when getting totally stuck is a bad thing, but again unrelated?
There was more friction to asking quick questions, compared to being in office. This may not be the case any longer at all companies, as it's possible that some of them solved this with new communication practices.
> There is a higher hurdle to setting up a zoom call than there was to waking up to a colleague who was at their desk
Also just not getting that, hitting the call button (or a real phone call) was always quicker and easier than walking two floors down to another room just to find the person not at its desk. Where is the hurdle?
Really, just not getting it ;) What's to be solved? I see it may be a problem or hurdle for some, but for others the bigger hurdle is the opposite way. Don't extrapolate, generalize and state it like fact, because that is imo not true for everybody and may be the other way round.
Sometimes people are just frustrated and spinning their wheels, or doing work that turns out to be pointless because they failed to understand something which would have been clarified by a short conversation.
If someone hasn't pushed something in a week or two, that's a good time for their mentor to initiate a conversation and see where they're at and when they think they will push something.
Anything else is micromanagement by a company that has hired someone without giving them any amount of runway to actually work and learn the space they're in. You can also tell on company hardware and on company accounts if the junior's browsing history represents getting better or just resting on their haunches because they want someone else to do the thinking. Let's not pretend the micromanagement cultures where "fear of rabbit holes" exists are not already doing this.
Are you saying the mentor should actually go and check the browsing history of one their engineers to verify whether they've actually done "correct work" or what are you trying to say exactly? This sounds to me like micromanagement of the highest order.
Instead of properly adapting the onboarding and mentoring to the remote setting let's romanticize the good old ways that imho sucked.
Let's cherrypick and pretend everything is fine. We went from offices to cubicles to open space and nobody stopped to think if it was a good idea. Wr transformed the office from a place where work actually is done to a placr where we "socialize". Work? Do that on your own time.
But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically the only way to replicate the in person experience.
The best mentoring results for me as the mentee and for me as a mentor have been when we're sitting next to each other. The mentor can visually tell when the mentee is stuck, and mentee can tell when the mentor isn't focusing on anything important and is more willing to ask for help.
No matter how many times you tell junior engineers to ping you at the first sign of trouble, they're not going to do it. They're going to toil for way longer than needed, unless you're sitting right next to each other.
And very importantly, I'm saying 30-60 minute remote check-ins are an absolutely insane idea that should never be implemented.
I don't know any kind of remote system that provides for anything even close to the power of in-person mentoring.
How about letting them figure it out and provide opportunities to chat and ask questions from time to time. Everyone wants superdevelopers but everyone expects that you're going to put a complete noob in a room with a senior developer, they're gonna rub hand and in 2-4 days you're going to have another senior developer. That's not how it works.
I have to say as a counter point though that I've had a lot more trouble with coworkers coming to my physical desk for questions that they could have Googled than with Junior getting stuck for extended period of time remotely. It's all a matter of culture and relationships.
Oh come on... I get arguing that there are ways to make remote training good enough. Maybe even similar. Maybe even a net-positive when you look at the entire picture (including the productivity and happiness of your senior staff). But saying remote is better for training specifically? No way. That makes no logical sense.
In person: Usually have to face the person or the screen, can't see both. I have to write down commands and pass them, or type them myself. There is a delay finding others if we need to talk to them. More chance to transpose commands incorrectly by the user. Harder to record the session without losing parts.
So at minimum, in person would be the same. So I can't possibly see how in person could be worse.
In person is worse. I've done both. It's noisier, you're crammed into a cube taking notes, etc. If you're going to use remote tools, what's the benefit of in person?
Got it, I see you're in the "make up stuff about the other person" phase of the discussion. No point in continuing here.
It's clear which juniors are motivated and will make the most of the mentorship and which ones are not. Some are just there for the check and you cannot compromise your senior and higher talent on people who don't want to learn and grow and just want the prestige and check of a high-tech job. It's the same situation with someone who is drowning not listening to orders and taking down their rescuer with them too.
If a junior needs someone to sit next to them because they toil for way longer than needed on clear simple requirements and goals, this may not be the field for them. I never needed anyone right next to me that couldn't have been a direct message or a brief remote call to clarify something specific, clear, and to the point. You're describing a reality where the people who don't do are just trying to take as much time for themselves as possible to hide the fact that they don't want to think.
They won't do that every single time. At some point they'll realize that asking for help isn't an issue.
Part of learning to be a sw developer is learning how to go about your work. Learning when to ask for help. If someone is doing this for you, you'll never going to learn.
Part of being a senior engineer is to use the mentorship skills you developed along the way and make judgements about how much struggle is right. Every new person should have a more senior partner with whom they can ask the dumb questions and not be made to feel dumb.
There are whole college degree programs designed to teach this, in fact.
We've used day long zoom windows or slack huddles. Keep muted until you want to say something. Slack is the same thing, just send a message.
Yeah, there might be some impacts to junior engineers. But if it improves the efficiency of your more expensive senior devs, isn't it worth it?
And just because your team has a problem with onboarding and mentoring junior devs in a remote environment doesn't mean A) Everyone has the same problem, B) you can't fix that problem yourself. Self improvement is the name of the game here anyway
People have been complaining about this development since forever. I'm not sure who that 'nobody' in your sentence is?
Mark Zuckerberg might be a true believer in open plan offices (judging by his public comments). But your average Fortune 500 company might only be into it for the savings in office space expenditure to be had from cramming people tighter. And some companies, like SAP (at least when I did an internship with them ages ago), still have offices (shared amongst eg 4 people) instead of going open plan.
It’s great you value work life balance, but junior engineers suffered a lot (to different degrees), and you being on edge that remote work might be taken away from you is nothing compared to what I went through and haven’t recovered from.
We’re allowed to love our work and the people we do it with, that’s my ideal, just a because you hate it doesn’t mean everyone should
Don't misunderstand me, I'm not romanticising the marriage of one's social life to one's workplace, nor overlooking the ways this "we are more than a company, we're family" rhetoric benefits employers at the expense of their employees' outside lives and broader well-rounded and fulfilment. But I think asking people to separate them in an extreme way is just as untenable.
But... the pandemic also broke me. Bad. I wasn't at all prepared for life trapped inside where my only interaction with human beings I knew was via video. There were like four months in early 2021 where I only had about four interactions with flesh and blood humans whose name I knew (like, not some entirely random person)... one of them was the guy who lived in a nearby park whom I normally avoid as it is so difficult to end conversations. I gained a ton of weight and at one point--end of 2020--I had given myself some kind of weird anemia (I think from lack of B12 in my stupid closed-in diet).
Like: I am someone for whom his entire life normalized remote work and who thrived in such an environment and yet the pandemic was so hard I still haven't really recovered... thinking about it makes me cry. (And like, yes: I could have better managed my lifestyle or better handled the loneliness. Whatever. That is also true for you, and I at least am not judging you for that.) It is one thing to not work in an office--you can work from anywhere! and there are a ton of people who you can get to spend time with--and it is entirely another thing to work explicitly from a small room in your home day in and day out for a year without human contact.
I thereby want to posit that maybe--just maybe--the issue isn't working remotely but being forced to stay at home and at times even fear going to the supermarket. There were periods during this thing when people were even afraid to meet up outside, and so human contact for white collar professionals outside of relationships was pretty much just verboten. The world was in a shitty place, and you shouldn't judge working remote based on the experiences you had during a pandemic without even trying to control for the existence of a pandemic as part of your analysis.
You’re right, I do still think there is value working in person, but remote work by itself isn’t what caused this, even if it’s still what happened.
Hindsight has made all this more clear, but imo loneliness is a silent killer around the world today, and covid threw jet fuel on the fire.
Working remotely I found myself constantly wasting time trying to figure things out on my own because I don't know if people are even online/active (spread out across the globe, another issue common with remote), if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes)
If you want juniors to learn anything in a reasonable amount of time you have to give a bit of a shit and invest more time solely towards that especially in remote environments, seems that people just expect juniors to take the lead and force their way in though which isn't my style at all and if there isn't a common agreement and people are all just doing their thing it can come off as presumptuous to be bugging people left and right for the first months. Yes part of the problem is company culture not properly adapting to the environment, but I also haven't seen any change in the way we deal with communication since the Corona and of course seniors don't care because they got their job security.
To be clear, labelled as an 'IC' I have zero interest in training you. You will job hop at the first opportunity, and never lift a finger to help me in the future.
Here is a workflow I made all people I mentor go through: 1) what is the problem? 2) why is this a problem? 3) what are you actually seeing? 4) what have you tried to solve it? What are the results?
Nobody knows everything. Everyone makes mistakes. The team should help those people but they need to ask.
Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job.
Because we try to think as a team, we do better and have less interpersonal clashes. I still complain about things each dev does, that's natural, but our team does pretty well together.
That's easier to do when you're more or less on "equal footing", but if you're a junior, it can take months to years to develop knowledge that seniors don't (depending on several factors). That's the problem, it takes much longer to reach a point where you have knowledge that is equivalent to that of seniors if the culture doesn't lend itself to frequent and high-quality communication and you have to learn about internal tools, processes, code bases and such largely solo. If you share a physical space with seniors you'll at least have some common downtime like a coffee or water break to "bother" them and it can save minutes to hours of tedium each time.
So either you end up being "that guy always asking stupid questions in the chat and interrupting my work" or you spend a lot of time spinning your wheels pointlessly for months/years on end. The first approach leads to unhelpful and delayed responses and the latter makes you so inefficient that you favor lower quality work so that you can actually deliver something.
There is no growth, no team cohesion in an environment where you’re berated for asking seemingly stupid or dumb questions. But I think people become numb and indoctrinated to it because “well, I had to endure this when I was learning” is such a demoralizing and abusive stance and nobody wants to change.
Things work so much better when everyone has a chance to pitch in, even if some ideas are dumb, just having the option is miles ahead of whatever bullshit people can justify from the “old way”.
Part of the process to change I’ve found is just leading by example. I’ll intentionally ask stupid questions that I know raise the ire of my similarly-leveled coworkers just to make the point to the more junior people that “hey, this staff-level guy is asking this, I might be able to too”. Junior people will gradually start to get the picture and ignore the rantings and ravings and toxicity of the debbie-downwers and the sticks-in-the-mud.
* Documentation that is up to date and answers not just technical details but the "why" behind the architecture. Something that shows you where to focus and where the frontier is.
* Defined, limited scope (at first). Scoping yourself to the entire codebase is a good way to become an expert in nothing. You need a foothold where you can gain expertise and give yourself a jumping off point to adjacent areas.
The latter is easier to accomplish than convincing everyone to write pages of docs that don't exist.
> if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes)
Sounds like the company lacks good culture, process and guidelines on expected patterns of communication and behavior. There should be an onboarding buddy when things are implemented well.
Its not your fault, at all. Its the company. Its not inherent to remote work though