[eosrei]

> I worked in an all-senior team once. Nobody admitted not understanding something. Everyone wrote overly-complex code just to 1-up each other

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.

[spaceseaman]

> 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.

[klenwell]

Ha. I can relate.

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."

[kogepathic]

> "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.

[Amokrane]

Completely agree. On a side note, the one answer that I always get from management when I suggest that we should write more documentation is: "Well, writing documentation could be useful but maintaining it is hard. So I don't think it's a good idea".

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.

[kogepathic]

> "Well, writing documentation could be useful but maintaining it is hard. So I don't think it's a good idea"

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

[eosrei]

Explaining Bus Factor can be helpful in getting their attention. "Sure, documentation is a cost center. You know what's a bigger cost center? Not having it."

https://en.wikipedia.org/wiki/Bus_factor

[dba7dba]

> "A senior developer shouldn't need documentation. The knowledge should be in your head."

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?

[cableshaft]

Why, look at the senior developer's brilliant, perfectly intuitive code, and know everything about the system instantly, of course!

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.

[tcbawo]

That's not an age or experience thing. People can be jerks at any age or level. Good engineers do not equate illiteracy of the codebase (unfamiliarity) with ineptitude. Good engineers educate without contempt. On the flip side, many people come into an organization questioning why or how things are done. Often, the current product is a ball of inperfection and compromises. Spend 2x more time reading the code than asking questions. Understand why a fence was put there before you tear it down.

[spaceseaman]

> People can be jerks at any age or level.

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.

[matwood]

> Understand why a fence was put there before you tear it down.

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).

[Swizec]

> Did you try X?" > "Uh yes I did" (then to be polite I repeat my explanation of doing X)

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)

[l0b0]

It's still frustrating to be at the receiving end of this. It's infuriating when this is the response after spending hours or days researching, then trying and retrying various things, being meticulous in recording every step involved.

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.

[Swizec]

> The results are often surprising. For example, they've copied code from a blog which auto-formats <pre> contents

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.

[eosrei]

That is not a senior developer, developer or even technology specific issue. You can experience immature egotistical indifference in any job. "Senior" developers who act like that are "senior" in title only.

[xupybd]

>Many don't actually read the questions you ask of them or trust your knowledge

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?

[badosu]

Also, not implying this is the case but often I see junior developers saying they've done X but have to double check if they overlooked something or mangled with something from Y and Z after repeated attemps.

[collyw]

I have had a junior dev claim that someone must have changed their code overnight. I decided that there were a couple more possibilities before going down that route of inquiry.

[xupybd]

Yeah I often try to double check things like that before asking for help. Other wise there are too often silly things wrong like config settings not pointing to the db I think they are. But still end up with egg on my face far to often.

[sheepmullet]

Why do you think it is a trust/respect issue?

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.

[meheleventyone]

Then it's a communication issue, the hypothetical senior isn't explaining why they are trying the same thing again. Which is missing an opportunity to teach something and improve the working relationship.

[IncRnd]

Maybe I read your post wrong, but your post seems to complain that Senior Developers don't believe some Junior hires have minimum competency if they are unable to compile a file.

That seems like something a Junior Dev should have mastered during their educational period.

[rxhernandez]

Then you're not senior enough to know enough of the unique problems that come from trying to compile things, especially for embedded devices.

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.

[spaceseaman]

> complain that Senior Developers don't believe some Junior hires have minimum competency if they are unable to compile a file.

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 :)

[IncRnd]

You misunderstand. It is not that I have never had issues with compilation or linkage, but that a Junior Dev should be able to learn how to perform the compilation, learning the vagaries of the architecture and build system.

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.

[spaceseaman]

I get what you mean, but I was more referring to build issues that are strange or unusual. Something that even a senior dev would raise an eyebrow at.

[IncRnd]

That makes sense.

[valuearb]

Wow, I’m considered a Senior Developer (only 30 years experience), and I’d say one if the biggest problems I deal with is getting code to compile. Large code base, “clever” code constructs left by long gone devs, and a language, that while usually great to work with, sometimes gives inscrutable compile error messages (Swift)

[IncRnd]

Exactly :)

[whipoodle]

Yes, I work with people who do this sort of thing to me a lot. They are younger than me, though.

[spaceseaman]

As other posters have said I recommend talking to them in person if possible. It's worked for me to just get in front of them because they're a lot less likely to think you're lying, and you can more quickly shut down the paths you've already went down if you do know your stuff about that method (and if you don't, it'll be clear to them and they can alleviate the issue).

[whipoodle]

Sure, probably good advice. I work remotely though, and more importantly I no longer feel I need to prove anything about what I know or what I'm capable of. I've pulled off a lot of shit. But I also don't have an attitude about it or think that makes me special, I just know what I can do.

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.

[icelancer]

> Those aren't senior developers

While I agree with you in spirit, in practice - in my experience at $BIGCORPs and $STARTUPs - this is very much standard operating procedure.

[yahna]

They also lose all ego and eventually become beings of pure energy.

People are competitive and do foolish things because of it.