Why is communication so overlooked by Senior Devs?
Posted by PressureHumble3604@reddit | ExperiencedDevs | View on Reddit | 82 comments
It’s been a constant of my career, every place I go, usually big and respectable companies, I find widespread lack of communication.
Funnily enough it happens both for remote and in office positions regardless of the fact that they claim that working remotely or in office both affect communication.
Most common examples I have:
- Inadequate onboarding: this costs weeks or months of below optimal performance for every new engineer while it has mostly a fixed cost. This for me is a communication problem, it means that the team doesn’t care about knowledge sharing.
- Culture of “find it out by yourself”: while I admit that this is a valid way to learn and keep some skills fresh, it’s not cost effective. If offering 5 minutes of help can save 50 it’s a no brainer. Even if you are worried about context switching, the help can be scheduled accordingly.
- Having to fight to be in the loop: I can’t waste energies trying to make sure I am on the loop with stuff that was discussed in private and at the same time I can’t be expected to know immediately about it existence if no one has told me about it.
- People not listening: depends on the person but I have found several devs that like to talk and no to listen and it’s frustrating.
- Bikeshedding: happen all the times and is a symptom of not discussing priorities enough
- Having messy communication channels: people can’t expect to follow a spaghetti mess of slack channels, they should be reviewed and streamlined every now and then.
Why so many devs don’t get it?
It’s so odd at the same time you have people being super strict and diligent about code but not communication.
I think it’s a cultural problem.
The hilarious thing is that the use of AIs proves that it’s not a human skill issue but that even synthetic intelligence performs better with good communication.
mackstann@reddit
I think this might be more of a symptom. Most companies are mediocre and don't necessarily treat their employees very well. People don't love their work. Work culture tends to be bureaucratic which predictably leads to silos and protecting oneself.
I've worked at a couple companies where things work well and employees are happy, and communication hasn't seemed to be an issue there.
Healthy-Dress-7492@reddit
I don’t begrudge anyone for being demotivated or disgruntled anymore - I don’t blame the victim - and I’ve learned they are always the victim. Companies are quick to forget how they’ve fucked people over in the past, they’ll see it as a performance or attitude problem that appeared out of nowhere for no reason. Maybe the rounds of layoffs had an impact? Maybe forced RTO had an impact? Maybe biting people out had an impact? Nope….
Leopatto@reddit
Christ you sound like my English Lit teacher when we had to read a book about some shit, she'd say "oh the author expressed his feelings by saying the couch is blue to demonstrate his sadness". Bitch no he just liked the colour.
90% of software developers are not good at talking. End of. There is no theoretical physics behind it. And that's ok.
BusinessWatercrees58@reddit
Good developers are thoughtful and deliberate about every line of code they write. Any code that doesn't serve a purpose is removed. Nothing is added "just because".
Good authors are the same. Your English lit teacher was right.
karmiccloud@reddit
You know that imagery and symbolism are like, real actual literary techniques, right? Like, that art exists and not everything exists at face value?
mackstann@reddit
Several other commenters already went into that sort of explanation. I offered an additional perspective. They don't have to be in competition with each other.
Far_Gift6173@reddit
See, the issue is this:
A company is just a hollow, soulless legal contruct. It's the people that breathe life into it. In my opinion, if a senior thinks he isn't treated well enough, he should simply switch employer. If he is worth his money, he will find something adequate
I've seen the symptons OP is talking about. Lack of engagement of coworkers and their unwillingness to tutor juniors and onboard experienced people. Most of the time that's simply their personality and their unwillingness to make en effort to find suitable tasks for juniors and guide them.
That-Surprise@reddit
...on top of the 500 other things that management want me to do right now
Nobody rewards you for onboarding people or sharing knowledge or improving processes and communications
gyroda@reddit
I'll add: it also depends massively on your onboarding experiences. I've gotten burned out on onboarding people who can't tell their arses from their elbows.
I recently had someone ask me to help him on something. "It's not working" he says. He shares his screen. He runs the code. I ask if he's tried debugging it. He says no. He has been working on this project for the last six months. I hang up and scream.
Far_Gift6173@reddit
Well, you need to "show" it
If you wanna be management, you need to talk with people and appear as if you can lead people. It's hard to juggle this when your workload doesn't really permit it, but I was also a young trainee at one point and I was also left alone to my devices. It was frustrating and inefficient and I made it a point to not let that happen to tohers if I can avoid it.
It also kinda trickles down if you manage to teach it properly
That-Surprise@reddit
I don't want to be management.
I can and do give management an idea of what good looks like in terms of process, quality etc. I can and do warn them about risks.
The old adage is you can pick two from fast, cheap and good and they want it fast and cheap.
FeistiestMeat@reddit
Yeah, this is it. I was thinking about coming in here and blaming autism, since that’s definitely a big part of it for me. But since I started at my current company I’ve realized I’m communicating with my team a lot even though we’re all definitely on the spectrum. I enjoy the work and I enjoy the leadership and I enjoy the people around me. That’s really it.
brainhack3r@reddit
For me, it's because I'm autistic and I burn out when talking to people, so I don't like to communicate.
I used to prefer just staying heads down and working on one thing.
Famous-Test-4795@reddit
No one is explicitly rewarded for caring about those things. It’s not like people won’t appreciate those qualities in you but it’s likely your manager may not give a damn.
goodbarrell@reddit
Vvvv
thodgson@reddit
100%
My current company does not reward communication. They reward completing user stories and and bugs.
When I suggested that when onboarding new devs, they should be assigned a "buddy" it was met with dead silence. I was then assigned to be the buddy for all new devs. Yeah, I was overloaded for the rest of eternity.
recursive_arg@reddit
This is the problem. Seniors do the bulk of the work where rubber actually meets road. If they take time away to hand hold a junior that is a big impact on burn downs. Senior time is best used for scoped questions. For general onboarding and orienting new devs there should be onboarding docs to field most of the basic stuff.
juusorneim@reddit
Why should onboarding be documentation-only? The best and most productive working experience I ever had was extremely collaborative and interactive. We had 2-3 weeks of on-site onboarding sessions, the team was eager to explain things in calls, regular training sessions every quarter for new platform developments going on in the company, et cetera.
recursive_arg@reddit
It sounds like this was company wide onboarding for a batch of new people. This is separate from team/project onboarding since there are usually people whose main job it is to do the onboarding monthly/quarterly/hiring frequency. And if it was team onboarding I can’t imagine hitting targets if yall are devoting 2-3 weeks per quarter of senior time to onboarding per team.
juusorneim@reddit
One part was the generic onboard for new engineers, second part was the helpful culture that "permeated throughout", into the teams. I never had the feeling that seniors were too busy to answer questions or teach about whatever part of the product or technicalities they were working on.
recursive_arg@reddit
Yes, you should absolutely come with scoped questions. I never said seniors can’t help out, but I did say you should be able to have an idea of what you need help with.
I have zero problem helping juniors. But if I’m approached by someone who needs help solving X and I ask what they’ve tried, if they’ve tried nothing I am immediately annoyed. Problem solving is literally the job. At least try to grow a little, growth doesn’t happen if everything is spoon fed.
OP said they can’t stand taking 50 minutes on a problem when it could be solved in 5 minutes by a senior, imo an hour is the perfect amount of time to chew on something before asking for help. You wanna know why the senior can do it in 5 minutes? It’s because they’ve already spent the 50.
Anphamthanh@reddit
incentive structure is the whole story here. the onboarding you described, the docs, the design decisions written down before code gets written, none of it shows up in a perf review in any legible way. shipping features does. so people optimize for what gets measured.
the devs who communicate well are usually ones who've been burned by the absence of it. they shipped something that got reverted because nobody wrote down a key constraint. or they spent a week on the wrong thing because requirements drifted in a slack thread nobody tagged them in. after that experience, writing things down feels less like overhead and more like self-preservation.
the companies where I've seen this work aren't the ones running communication training. they're the ones where "I had to reverse this" or "two teams built the same thing" actually shows up as a cost someone owns.
Anphamthanh@reddit
incentive structure is the whole story here. the onboarding you described, the docs, the design decisions written down before code gets written, none of it shows up in a perf review in any legible way. shipping features does. so people optimize for what gets measured.
the devs who communicate well are usually ones who've been burned by the absence of it. they shipped something that got reverted because nobody wrote down a key constraint. or they spent a week on the wrong thing because requirements drifted in a slack thread nobody tagged them in. after that experience, writing things down feels less like overhead and more like self-preservation.
the companies where I've seen this work aren't the ones running communication training. they're the ones where "I had to reverse this" or "two teams built the same thing" actually shows up as a cost someone owns.
Sheldor5@reddit
"find it out by yourself" ... but I like to find it out by myself ... that's the whole point of my seniority
Famous-Test-4795@reddit
I mean, that's fine as long as management has realistic expectations about it...how often these days do people join companies and are expected to reverse engineer tribal knowledge using ChatGPT or something similar on your first day, such that you can independently identify and fix all of the business's problems? Does it really feel good to have those kinds of expectations?
That-Surprise@reddit
I'm going to be annoyed if I have gone to the trouble of writing up a solution to something that can be quickly found with a search on confluence and you are badgering me for the same information
juusorneim@reddit
Why though? The value is that now you can paste a link instead of explaining it again.
That-Surprise@reddit
https://letmegooglethat.com/
Because I'm busy and I shouldn't have to waste my time teaching people how to use a basic search tool.
If it's esoteric and/or the kind of thing you'd think to search for doesn't bring up the relevant document then that's maybe on me for choosing a poor title etc - so yes I would then simply offer the link and maybe I'd look at making it more discoverable.
But if I've written a clear step by step guide titled "how to run bobbins service" and I get asked "how do you run bobbins service" then I know I'm dealing with a lazy waster that wants spoon feeding everything and I don't want them around me.
tonjohn@reddit
When the whole pipeline is built on top of grinding leetcode the human skills that are most important get lost along the way
Famous-Test-4795@reddit
You can be a principal engineer and not have any real people skills.
13--12@reddit
Autism
Famous-Test-4795@reddit
Alright, but we live in a society and plenty of autistic people exist that don't have the luxury of not being forced to guess other people's social cues or learn how to work with people.
hiddenhare@reddit
Specifically: really well-masked autism, which decompensates whenever an engineer is promoted into management.
I've never had a colleague who wants to drone on about trains for an hour, but I've had plenty of managers who are blatantly avoiding the social side of their job. Notice that most of the problems in OP's list are both technical and cultural; this is what it looks like when your company's technical leadership has gone AWOL.
Deranged40@reddit
fyi, promoting an engineer to management is part of a phenomenon called The Peter Principle. Which finds that people tend to "rise to their level of incompetence". And this is exactly how that happens.
The best manager for a team of engineers isn't necessarily someone who would be a competent engineer on that team. And the best/most productive engineer on a team isn't guaranteed to be a competent manager.
This is because management and engineering aren't actually all that similar.
CorrectPeanut5@reddit
Most of us in IT are on the spectrum.
BUT, there's two things at place I've notice in my life as a corporate contractor. 1) Companies have moved towards computer based training for a lot of stuff. You're no longer seeing people send to a couple weeks of Dale Carnegie type training to work on soft skills. 2) Younger employees resist those kinds of classes and training.
SimilarDisaster2617@reddit
You mean seniors dont communicate due to autism, or that the op is autist? I agree with both anyway
B-Con@reddit
Literally.
I'd wager good money at least half my coworkers are on the spectrum. This type of job is a magnet for it.
And I'm one of them.
MichelangeloJordan@reddit
lol facts
quantum-fitness@reddit
Ding ding ding
PressureHumble3604@reddit (OP)
Didn’t want to mention it but honestly in many roles it affects the performance negatively
jtonl@reddit
Guilty as charged.
jesseschalken@reddit
Half the things "communicated" are either outdated or made up. Half the plans made wont work. The more people that know about a thing, the more people can object for nonsense reasons.
"Find it out by yourself" at least means what you find out by experiment or by reading code will actually be true.
Perfect-Campaign9551@reddit
I feel the same. So many devs at my work seem afraid to speak or something
Forsaken-Promise-269@reddit
I think developer culture is also part of the problem, there’s the famous Office Space Joke https://youtu.be/hNuu9CpdjIo?si=0I-AETKtFO4PuJn4
But also Engineers are focused inwardly on solving problems not outwardly on bringing people of different backgrounds together
Sometimes you get a person who can do both- usually those types go very far up the company ladder
So most sr devs do usually have adequate communication skills at least enough to keep the team running otherwise it’s unlikely they would have been promoted in the first place
Unfortunately a lot of developers also have real difficulties with social skills, empathy and empathetic communication, ie really bad communication skills In fact many are just not interested in communicating and a lot of difficult personalities
I mean just look at the charming :) personalities of some of our most famous dev types
Linus T: https://youtu.be/JZ017D_JOPY?si=p-TRhf08iW9VggmM
Elon: https://youtube.com/shorts/9zzSiPmzX-4?si=pX12h--PxQiB8BNx
Zuckerberg: https://youtu.be/enW60MkPVBg?si=MJ9EOV6gUjKgKGpP
Ok btw I still love devs they are usually honest, over the corporate BS too
But it does help to cultivate your skills there!
olzk@reddit
in addition to other mentioned here, general lack of skill and willingness to hone it. BTW, I observed several times in my engineering career that some devs lacking communication and/or programming skills compensating with strictness about code.
ZukowskiHardware@reddit
I had a communication only class in college and I use it every day.
_hephaestus@reddit
Onboarding always gets deprioritized because it happens infrequently, is a constant time phenomenon rather than a multiplier, and the environment is shifting all the time.
Most of these are from incentives. Honestly I feel like it might be worth considering what you’re actually asking here, what goes into making a reviewed/streamlined comms channel? You have to get a bunch of busy people to come to a consensus that changes their way of working. Is it worth doing? Probably, but does it have to be me putting in the effort, will I actually be rewarded for it? These are EM style concerns.
rhd_live@reddit
Something I get downvoted for is pointing out that clean code, pristine architecture, and the meticulous toil for refactoring something isn't the most important thing for the business. The most important thing for the business is, well, hitting the objectives of the business. Things become much easier when you see things from the perspective of the company, and serve the company's interests. If you're narrow-minded about the little existing system you maintain and incrementally build on, are super pernicious about how those lines of code are arranged, and spend an enormous amount of time on a specific app or service that's now an afterthought amidst changing business priorities, you're gonna frustrate yourself and harbor lots of resentment, anger, and other negative emotions. Run downhill toward your goals, not uphill.
That-Surprise@reddit
I now work for a company where they can't meet their objectives, can't scale and are losing business because of a poor reputation for accuracy that is entirely rooted in choosing sloppiness and speed over doing things in a sustainable and scalable way.
FWIW my motivations are typically more aligned with what's good for the company over a long period of time. The twats running the company want to orchestrate a pump and dump scheme where they get to fuck off into the sunset with sacks of cash whilst leaving a dumpster fire behind for the next sucker to inherit.
rhd_live@reddit
Yeah sounds like it’d be best to job search if the company’s going down the toilet
Medium_Chemist_4032@reddit
> Inadequate onboarding
It can be done in a great way. I had a pleasure to start out, when a process driven Knowledge Transfer was the norm (or perhaps only the place I landed) and I have been dreaming about, when it will come back again. It's been a pleasure to go thoroughly through knowledge items, having an external dedicated KT transfer expert, that made sure the process is taken. If this sounds bad to you, I highly recommend going through it at least once and forming own opinion.
The KT solves, or vastly improves:
experts that always forget about something very important, or trivial to them, but not to anybody outside of their lair
experts severely underestimating KT total hours. 3x is the norm.
newjoiner has the expert and another person that can always go to to verify some of the claims
documentation that is "always out of date" gets a thorough review exactly, when it's needed... or created if missing
I don't know why this was torn out of software engineering completely (around the agile revolution). YOLOing knowledge is only backfiring non-stop as I keep seeing it.
> Culture of “find it out by yourself"
Ah yes, the helper vs. lone thinker conflict. It goes way deeper than software engineering. Some workers just completely avoid using any external help (mainly due to specific type of upbringing) and reflexively expect others to be able to do the same.
While the person that is accustomed to being helped feels completely lost with that pairing. It's quite common and frankly fixes are available in psychology classes. I wouldn't fix it though, just worked around, by for example asking to provide materials and studying them with the help of an LLM for example.
> Having to fight to be in the loop
That's interesting. Previous two points are kind of typical for most SWE jobs, but this one is odd. Ok, the classical answer to that is a "pate" (or forgot how that function is typically named): TL dedicates a single person just to make sure you, as a newjoiner, are always up to date. This function has a really bad name, but the benefits are real. It removes the responsibility from you directly, about being up to date.
> People not listening
I'll be honest. It's you. I have seen this for so long, so I can comfortably skip the ceremony and give, what is most often the reason. You are too silent, uncertain, nice, careful. Both socially, but more specifically, in the tone of your voice. I'm not joking and I'm not mocking, but try out simple exercises from vocal trainers - there's a ton of them on YouTube. It goes more deep, than a simple "silent, vs. loud", but for example throat speaking is considered a weak signal, while diaphram speaking steals attention immedietaly. It's biology, we are wired like that. Very little people are actually even aware this is happening, so you might get a bad advice.
liyayaya@reddit
It is an incentive issue.
If developers are measured on delivered features / story points / LoC (can't believe we are back to this in 2026) / whatever stupid metric management comes up with, then that is what they will optimize for.
little_breeze@reddit
This may be a bit on the cynical side, but in my experience (at 8+ years at big/small companies), it comes from a desire to maintain job security. I've seen so many senior engineers purposely leave out key pieces of info when onboarding new members, or write convoluted balls of spaghetti code, just so it's harder for others to contribute to "their domain". It's probably an incentive/culture problem at big tech: "why would I help you, when I could be doing something to advance MY career?"
The more effective (smaller) orgs I've been in have all been in smaller teams/startups, where everyone is incentivized to help each other to improve the business. They also have some light systems/processes in place, like:
- don't DM people "hey do you have a few minutes?". just write out the damn question for less surprises and stress. I'm a big fan of Oxide's RFD system
- serious discussions should be in documentation / forum-style, not in slack / DMs where they're easily lost
jmking@reddit
This is a red flag against you, dude.
You don't get people to listen to you because of your title or position. You get people to listen to you by building trust and demonstrating competency. You aren't handed this - you have to earn it.
AnnoyedVelociraptor@reddit
Because constantly getting answers from people doesn't help you actually understand the codebase.
kevinossia@reddit
We’re not all like that. But the reality is most software developers are pretty bad and that includes the non-technical skills.
cuntsalt@reddit
well if I was good at communication and not computers, I'd probably be in a different line of work. expecting devs to handle the full stack of technical responsibilities (that is no longer front-end and back-end, but also ci/cd, infrastructure, performance, accessibility, etc. etc. etc.) plus all this other shit is beyond unreasonable. i'm optimizing for what is least painful and quickest for me to do in order to stop working at 5 PM on the dot and go do the things I actually care about.
Teh_Original@reddit
Let me provide an example set of questions from a company I know: Is there a task for that? Leadership needs to prioritize. How many story points is that work? Where do you log your work?
Sometimes this stuff doesn't happen because the company incentivizes it to not happen.
corny_horse@reddit
First of all, I don't think it's overlooked at all. A very common opinion is that soft skills are more important than "hard" skills for engineering roles. It's not an opinion I agree with, but it is a common opinion.
Secondly, a lot of the things you mention aren't communication, in my opinion. Things like inadequate onboarding, bikeshedding, excessive tribal knowledge, etc. are all organizational problems that have a communicatino element to them, but are really more about incentives. Are engineers incentivized to create quality onboarding documents? I've never worked anywhere that this was a high priority; neither before Covid nor after, neither in person nor remote. The only places that seem to have anything resembling this are giant megacorps that have people whose job is to ensure that engineering onboarding processes are streamlined, and even then, I've heard mixed reviews (having never worked for one myself).
That-Surprise@reddit
I work in a financial transaction business with lots of poorly documented processes, much of it is not documented at all and understanding something like a choice of payment rails involves multiple services with nested if statements scattered all over the shop. If there was any documentation it will be out of date and wrong.
Manager: Yes, we do have a documentation problem, can you put that in JIRA as a to-do?
Me: What, document everything in the system, every batch process, every decision flow, all of it? Won't that take months to do accurately?
Manager: Yes, do the needful.
There is now a JIRA ticket on the backlog labelled "document entire company", it it had story points it would be a million and yes I am interviewing for new jobs.
PeteMichaud@reddit
It's a cultural and process issue. Communicating to a bunch of people about a complex topic isn't going to happen without deliberate effort, and management mostly doesn't do it, recognize it, or reward it.
JadedTangerine1010@reddit
reminds me of my last job's onboarding mess
blablahblah@reddit
I am evaluated on my performance every year and I am subject to the whims of those involved in that process.
I would love to spend more time training new engineers and helping them ramp up on things but that would be detrimental to my performance evaluation compared to spending more time writing unnecessarily long design docs or scheduling pointless meetings to bikeshed with management.
Outside-Storage-1523@reddit
Because it is not rewarded. I rarely got communications from upstream and I appreciate when it did happen. But I'm getting used to things in upstream broke suddenly.
Regal_Kiwi@reddit
People with high IQ, bad judgment and not well read. It's never-ending waves eroding my soul.
MonochromeDinosaur@reddit
You know the ones who comes in and survive everything you listed and advocate for themselves and organize the masses en up being the Leads/Staff/Managers/etc.
Have you ever tried to wrangle a bunch of autists shit is not easy 😂
d0rf47@reddit
This is something I noticed at my new job. First time in big tech arena and was floored. My on-boarding had a 6 month plan. The guy who hired me and was on boarding me was promoted 3 months later and left to a new team. Never spoke again. And during the 3 months he was there, we probably spoke a total of 6 times for maybe 30 mins. It has been honestly infuriating.
We work on a full erp tool built on a custom framework with literally 0 documentation outside a few style guidelines which linters deal with anyway.
All product and business knowledge is held by people who seem to keep being shuffled around making it take very long times to get answers about how code logic should work, or how features should behave.
It makes for a extremely stressful environment especially now with ai when it's all about more productivity and output. It's hard to really learn useful new skills when you spend your whole time trying to also learn the business side of things cause pm and tl are always too busy in meetings to respond
thodgson@reddit
That absolutely sucks.
I work in a dissimilar yet similar environment: Joined a company where everyone is a contractor, people are shuffled around by re-orgs all the time and turnover is high. The people with deep domain knowledge are "too busy" to help and document nothing.
I'm the exception to the rule. I've been in the same role and department for 5 years and I am making major headway: documenting everything, onboarding new Devs and trying to keep things sane...but, the writing is on the wall and we will be split up at the end of the year into other departments. Oh well.
d0rf47@reddit
Seems to be rather common based on what I see online. Hard to say if that's reflective of the real world though.
But the whole I'm too busy to document or explain is something I've seen before too and it's infuriating
sootfawn@reddit
This performance cycle I onboarded 3 engineers. Did not come up in my review. What did come up was the projects I led and the code I shipped.
Show me the incentive and I'll show you the outcome.
Esseratecades@reddit
There are a number of bad faith reasons but I'm going to focus on a good faith one.
Communication slows seniors down. The vast majority of meetings are either a waste of time, or to catch people up on something that some senior already knows. When you've got management and sales breathing down your neck about some BS headline, giving an important ticket to a mid or junior engineer as a learning experience which you then have to coach them through is burning time you don't have.
Now don't get me wrong. Sometimes seniors don't know as much as they think they do. Or they've kept their heads down so long they haven't noticed the world changed around them. Additionally, if nobody is teaching the juniors, then you eventually run out of seniors.
BurberryToothbrush@reddit
I totally feel this. I think my communication, interpersonal skills, and overall dependability are my best assets and the reason why my coworkers have all enjoyed working with me. But that’s not easy to flex or signal through my resume or even some interviews, so that trait hasn’t really been working in my favor the way I think it should during my most recent job search.
Zulban@reddit
Don't assume the goals of others are the same as your goals.
Maybe not writing docs, not having to teach, and bickering are all things they want to do. Then they get paid and go home.
roger_ducky@reddit
With people, bad onboarding documentation is a hidden cost that disappears as people gain the full context of a project.
If people aren’t added frequently, documentation drift happens and it’s useless for the next person. (Most places make the new person update the documentation.)
With AI , since they have to quickly reacquire context each task, it finally highlights how bad most of that documentation actually is.
Far_Archer_4234@reddit
Only 2 of those bullets actually come from senior devs. Most are organizational issues.
ugh_my_@reddit
It’s not that important
Chezzymann@reddit
Lots of companies seem to be more concerned about inverting binary trees and dynamic programming than the more practical skills you'll need on the job day to day
schmidtssss@reddit
Conversely well run organizations see these issues at far lower rate
gwenbeth@reddit
The problem is that management doesn't think communication is important and doesn't allow for the time it takes. I have been at new jobs where my manager told me to ask the ppl in group for help, but none of them were ever told that spending time to help me come up to speed was something they needed to spend their time on. So I was left trying to get time from people who already had all of their time working on their own tasks. (This was at a large well known company where EVERYTHING was a custom internal system that existed nowhere else)
recursive_arg@reddit
Regarding onboarding… are you reading the onboarding docs? I don’t think I’ve ever came onto a team that didn’t have some sort be setup instruction docs. Most of this sounds like help isn’t being offered freely, which is fair when you think about it. TBH it is kindve on you to ask when you actually need help. It isn’t my job to hold your hand all day, if it was they would pair us.
I can usually answer questions but honestly one of the biggest aspects of being a senior is getting stretched. You are usually flexing across multiple projects like a staff level but unlike staff you are expected to do a lot of the actual coding as well. It’s very possible a senior might drop a plate by taking that 15 minutes it takes to explain something fully to you. So usually scheduling time or asking during open forum meetings are best.
Windyvale@reddit
Companies want the best technically skilled engineers they can find for the dollar. People like that tend to be…focused.
honestduane@reddit
The problem is that the people who focus on communication skills are often the same people who don't know about technology and are just imposters who are faking it who need to be put on a PIP.