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.
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.
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.
This sort of overgeneralization just tells me we'll have people in 5-10 years "realize" that many of the benefits of remote work were just built on relationships and processes created in the days before. It's like the "open office" floor planning all over again, but with higher stakes.
In 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.
If you've discipline and commitment you can make anything work. :)
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.
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
In other words, they are not at all just learning from a laptop.
My experience is that unsupervised education is worthless.
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 ;-)
I suspect it works for readers, not audio consumers.
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.
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.
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.
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
...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...
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.
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.
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 pendulum may have swung too far, on that I'll agree.
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.
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'.
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.
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.
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.
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.
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.
Good luck at the new job!
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.
But now in theory, at least, I don't have to make that compromise.
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.
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.
I have a hunch that as more work shifts remote, new ways of working will evolve.
It takes time and effort as an individual, and more time and effort as an organization.
If you don't put in that time and effort, you won't be good at it, like any other skill.
What's old will be new again.
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.
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.