Sorry to hear about that experience. Those aren't senior developers. There's no room for learning when you think you know everything. Senior developers mentor, simplify, document, and admit when they don't know the answers.
Sadly this is far from my experience as well. It's likely a few toxic work environments.
Not to hijack your comment but I would like to offer a specific example I've seen of toxic behavior from senior developers. Many don't actually read the questions you ask of them or trust your knowledge. It's very similar to attitudes I see on Reddit, HackerNews, or StackOverflow:
"Hey I'm having a bit of trouble getting this to compile / run / there's this weird error I'm encountering. I read the documentation and based on that tried X, Y, and Z, but none of those solved my problem / my problem appears somewhat different." (Where each of X, Y, and Z are somewhat long explanations of what was tried).
"Did you try X?"
"Uh yes I did" (then to be polite I repeat my explanation of doing X)
"What about Y?"
You see what I mean. Especially in text, I find that some senior developers can't be bothered to actually read what someone else said. So if you're worried that you're a poor senior developer, I recommend you actually try and read what your younger colleagues say and ask of you. And especially trust that they are being honest with you. Don't assume that someone is lying or that they're wrong on the first pass - it's condescending, frustrating, and usually a waste of time. If you hired someone in the first place, you should be allowed to assume a bare minimum of competency and if for some reason that fails, you can always question them after the fact. I think it's a result of our engineering mindset to assume absolute idiocy in every case and then work our way up, but I think it's more productive (and especially better leadership) to assume that your subordinates know what they are doing.
In the context of an online forum like this, I think it's best to do the opposite: assume idiocy and work your way to competency - simply because we are all anonymous and don't know each other. The actual workplace should be treated differently though. People always perform better when you put your trust in them.
Good point, I was simply saying that in my experience it's the people with "senior" in their job title who do this most often.
> many people come into an organization questioning why or how things are done.
I think Chesterton's fence is a very important concept for new engineers to learn. But sometimes it's still valuable to understand for yourself why that fence is there in the first place rather than just take someone's word for it. The best scenario is an opportunity for a senior to guide a junior in the exact why.
I'm using this line from now on. As a senior dev with a lot of experience I find myself often being the only one questioning the tear it down mentality. Everyone wants to write greenfield code, and instead of taking the time to understand why current code looks like it is a mess people just want to start over. IMO, no one sets out to make a mess. A mess occurs are compromises are made to add new functionality and catch corner cases. I'm also fine tearing down a fence only after someone can tell my why it was put there and why it can down be torn down (and also how it can be rebuilt in some improved manner).
I think the issue could be that you're using written communication. It can be a difficult way to get help. Can you sit down and talk with these seniors?
The fastest way I can get up to speed is by speaking directly with you and getting you to walk me through what you have tried.
At my last gig, it wasn't the seniors developers (well, it was some of them, too). It was the principal developer.
As my supervisor, he told me, a senior developer, I asked too many questions.
"A senior developer shouldn't need to ask questions."
My questions usually weren't even technical questions but rather questions meant to clarify business specs so that we could make better technical decisions.
At my last performance review, when he dinged me for lacking knowledge expected of me in my role (one of the boxes in the evaluation form), I pointed out I was the one who had done most the documentation for our major applications.
His response:
"A senior developer shouldn't need documentation. The knowledge should be in your head."
What?! This guy isn't fit to be principal developer.
Sure, the knowledge should be in your head, but it should also be documented in case you get hit by a bus or go on vacation.
Does no one senior ever stop to think about business continuity? What happens when you onboard someone new? A senior developer is just supposed to drop all their work and get the new person up to speed for a month?
I find that companies with a bad documentation culture see it as a cost center ("this takes so much time") whereas companies with good documentation culture realize that even if it takes time, the benefits far outweigh the costs.
As you said, this should be part of the culture. Documentation should be seen as an artifact that is equally as important as the software deliverable itself.
Your management does not understand the value of good documentation.
Flip the industry:
"Well, airplanes are useful for transportation, but maintaining the documentation takes too much time. So we should skip writing the maintenance documentation and just let the mechanics figure it out themselves every time they need to replace a part" (assuming the plane doesn't fall apart mid-flight)
If you framed it as such, they would see that their counter-argument against documentation is silly. Now, they could argue that your software isn't life critical and people won't die if it fails, but personally I think that's beside the point. It's a business decision the aviation industry has made to document things thoroughly and it's paid off in spades for them.
Of course you have to invest time and effort into documentation, but you maintain it the same way you maintain your software or your tests.
It sounds like your management doesn't realize that although documentation has a visible cost (people's time) it also has many invisible savings: to quickly reference in emergency situations, employee illness/vacation/departure/onboarding, supporting legacy versions.
tl;dr - your management sees documentation as a cost center
So a senior developer shouldn't document, and shouldn't answer questions (since he said one shouldn't ask questions)?
What's a junior dev to do when there is no documentation and no one to ask for help/clarification?
I live this life right now. No documentation, and the senior devs have left, so you just have to figure out what the hell they're thinking as best as you can with the code left behind, sometimes stepping through everything multiple times to see how the data flows through it. Thankfully one of the architects that used to work here knew how to make readable, modular code, so our newer projects aren't too bad to modify, but our legacy systems are awful nests of spaghetti.
That seems like something a Junior Dev should have mastered during their educational period.
One of the non-embedded cases is compiling boost on a visual studio machine for wrapping python which can be its own special kind of hell. I've seen at least one very respected principal developer wholly screw this up. I can write for hours on those kinds of problems and how to solve them.
You're definitely taking the wrong impression from my post then. Do you code in C / C++?
If you've never had an issue compiling a large codebase as a new developer then I should either bow before your greatness or mock you for your inexperience because in large, complicated projects with 1000-line makefiles included from various sources, on a platform with various skews, flags and options, even the most talented developer can have issues with compilation - especially in most corporate scenarios where the exact command line you need for the internal build tool Steve wrote in 1996 is passed down through email and IM logs. OH and don't forget that some of the objects we link with are actually dummy files to be filled in by a shared library on the target that's been precompiled... OH and some of our functions are actually programmatically generated by a Perl script that runs as part of the build script. These are just some of the things I was exposed to as a junior at various companies.
Building gets messy, quick. Should it be? Probably not. Is it? Hell yes. Download boost or blender or something and try and compile for a non-standard or multiple platforms. My sibling even gives a specific open-source example (although open-source projects are typically MUCH better about getting building to be simple)
More importantly, my point is not that the junior doesn't know how to compile. Compilation is just a place where things get very messy very quickly, and a precise explanation of what was done needs to be given so that the senior can guide the junior along a proper debugging path. Your attitude is precisely the thing I'm recommending against.
> a file.
Whoever needs to only compile one file? That's not the hard part :)
You mention Enterprise development among other items. Making a shim or method for onboarding new devs is exactly a way for one to advance in Enterprise development. Therefore the Junior Dev should take this opportunity to learn the internal system and create a way to simplify its use for others. Not doing something like this is a trap that many Junior devs fall into, even when a Senior dev hangs the opportunity out in front of them.
As somebody who often does this, it’s because 8 times out of 10 it works. Magically when you try again and go meticulously through the steps with someone watching, they work even though they didn’t before. I don’t know why but it works on me too.
I’m not being condescending, I’m trying to be your rubber ducky. Because it works. Many times when you’re explaining it to me, you’ll realize the thing you thought you tried you actually didn’t.
Being your rubber ducky is more important than just telling you the answer (which I often don’t even know so I’m bringing you along to my thought process)
I've been on Stack* for a while now, and generally take people at their word when they say they've done X. The results are often surprising. For example, they've copied code from a blog which auto-formats <pre> contents, replacing hyphens with en dashes. You'd only notice if your font makes this noticeable or by running the actual code.
One reason it would be OK to ask someone to try X again is if they haven't included enough information for anyone to replicate the issue. However, the better response in these cases is usually to ask for supplementary information until it can be reproduced.
Perfect example! Often if you tell me “I tried to copy this and it didn’t work” I don’t know why. But if you show me how you copied and what exactly, things like this immediately pop up as possible clues.
I know it’s frustrating but it really does work on everyone. Half the time I show someone what I’m struggling with and I try to show them what I tried, the act of showing them reveals where I went wrong and I figure it out without them saying a word.
A lot of people don't listen to me, in a lot of different contexts in my life. I don't know whether other people experience this as much as I do or if there is something about me that informs that response in people, but it is a pattern in my life. I'm not so sure there is much to be done about it.
While I agree with you in spirit, in practice - in my experience at $BIGCORPs and $STARTUPs - this is very much standard operating procedure.
People are competitive and do foolish things because of it.