Mindsets to Avoid as a Senior Software Developer

Oh but there are things we can do. We can add comments that link to resources, we can write long prose (both inline in comments and in out-of-band documents such as RFCs and documentation) explaining why we're using something that nobody else in the team understands vs the alternatives, and we can level people up via informal sessions like lunch-and-learns, info sharing sessions, etc.

It's true that many juniors aren't capable of following concepts above a certain level of difficulty, but it's also not rare for people to really flourish if given a gentle push.

There's definitely a paretto balance when it comes to knowledge sharing. Don't be that person that writes zero docs and hogs all the knowledge when you could spend 20% effort to level up 80% of people to the point where they can start helping each other.

There is a difference between code that is complex because it needs to be (ex: matrix mathematics) and code that is complex because you wanted it to be (ex: microservices and kafka and obscure functional languages for what could have been a Rails CRUD webapp).

Teaching them will.

It is an opportunity to go through the code and concepts at least.

Having most of your team not be able to understand the code they support sounds dangerous

I think the OP is just saying that juniors should be allowed to participate in the reviews of senior engineer code (not that a junior review alone is sufficient for merging a PR).

I think this is a great way for juniors to get exposure to the complex topics they might not yet understand, but should learn more about.

What if you took a hour or a day to help educate an eager junior developer about what you did in that PR?

I, personally, don't know matrices. I can damn well learn them if it becomes relevant to me.

If we were on the same team, and I said "what's this stuff?" and you said "nothing I can do will make you understand this" I'd be pissed, and that attitude would _permanently sour_ the relationship.

I imagine there was a point in time that _you_ did not understand matrices. I've no doubt that matrices can be tricky, difficult to understand, etc.

So, lets work together on sharing that knowledge! Once you've helped me learn it (pointing me to resources, pairing with me on an example problem solving session involving matrices) I will be able to maintain the code, understand it, and apply the pattern to novel problems.

But not just that, because I am a compulsive documenter of what I've learned, as you teach me, you help me teach _everyone who comes behind me_

TL;DR the attitude of "if jr/med devs don't already understand matrices, nothing I do will make them understand them." is _extremely_ self-limiting, locking you out of tons of potential value, and causing your entire team to be worse off.

It's not your fault, per se. I know this attitude is common in the industry. It just really pisses me off, because so many teams are deeply damaged by it.

(I know, I know. Maybe you'd love to slow down and teach early-career devs, but the feature death-slog required by management precludes you taking that time... in that case this isn't directly your fault, etc.)

And not to what some one did mumble years ago when I was taking over the map part of a map reduce product built in PL1/G and say after 3 days "haven't you learnt it all yet"

Code review might be good for a subset of code, like retrofitting bugfixes to release branches or babysitting a team of beginners.

BUT: I just joined a team with domain experts who do not have a software engineering background. As I go through the code, there's lots of copy & paste, incorrect error handling, inconsistent (and confusing) variable names...

These developers really can benefit from coaching in a review. The team then benefits because the code is easier to read, robust, and maintainable.

(The codebase is impressive for people who have minimal software background. I've seen much worse from people who should know better.)

That’s a real problem. Almost nobody has the time to really understand the code they are reading and how it fits in.

I suppose I technically did have "veto power" as my approval was required in order to merge the PR, but nobody ever thought of it in such adversarial terms. We'd comment with questions or things that were unclear, occasionally asking "why are we doing it this way instead of that way?" and more often than not the solution was simply adding/updating comments to make things more clear.

For our team at least, it was a casual and collaborative effort where everyone learned from each other. I wouldn't hesitate to give inexperienced devs veto power over my PRs again unless it was for a time-sensitive hot-fix.

This is a strange concern to try to address with code-review. I don't think most folks actually expect to catch a lot of bugs by staring at diffs. Testing is the right tool for that job.

> I'm way more interested in that than I am whether variable names use camel case or snake case or whatever.

Style concerns definitely shouldn't be the primary focus of a code review. Ensuring some stylistic consistency through the code base is a benefit they can provide, but certainly not the the most major.

> In fact if your tests are complete

How do you know if the tests are complete on someone's work before they merge it? Don't you need to get in there, and well, review their code to see what tests they wrote? Evaluation of test coverage by a peer is one of the more important parts of a good code review. What other process would you use to ensure incoming patches have the test coverage you want them to have?

> we can always refactor the code later if we need to.

Isn't it better to catch code structure issues when they are fresh in everyone's mind rather than taking on technical debt and addressing it down the road when it will require more effort? We've all written code in somewhat silly ways. My experience is that when a peer calls that out before I merge it, it's way easier to fix up-front than a year down the road when I'm in there trying to fix some bug and am wondering if I should just refactor the mess while I'm at it.

Also reviewers shouldn't squabble about syntax or formatting, that what we got computers for to do for us using auto formatting tools. Though it does help if a team converges on a similar style for which reviews are great as you quickly learn each others style and cross contaminate them with your own.

PR's become more of a gate to see if you understand the problem and test for the solution opposed to HOW you went about it. Maybe I've had bad experiences but focusing on HOW is really prone to toxicity. I try to avoid that in PRs at all cost and foster a culture of collaboration, shared understanding of the PROBLEM and Respect for the Constraints. I've left places because of extremely toxic PR culture, so I'm probably pretty jaded :p (The culture was so bad I dreaded asking for reviews.)

How did you prove that your solution works and respects the constraints?? How do you protect yourself and others from future changes? Everything else is an implementation detail.

Which from a management perspective can be explained as the following: In non tech you buy software and development time, and projects almost always fail to deliver on time or within budget regardless of which company you go with. At the same time, the biggest note on your budget is the upfront cost. Even if you end up spending more by going with these junior exploitative companies in the long run, it’s still easier to justify picking them when you’re talking up the latter, because they charge 3-40% less an hour.

On top of that there are different kinds of productivity. There’s the senior developer who does things right, but non-tech clients don’t give a shit about that, they just want something that works most of the time. Which again is more expensive in the long run, but nobody in management is around for long enough to realise, and or, learn from past experiences based on real data. No, in management you learn with how much praise your project gets, and it doesn’t really have to be sound technically to get that.

When you sell software to non-tech companies, they’re used to failures. We have 1 supplier out of more than 1200, who hasn’t screwed up majorly at one point or the other.

In a world where that’s a fact, and people have just sort of learned to live with shitty software and IT that doesn’t always works. The key selling point for any major product is cost, and upfront cost weighs so much more than cost-down-the-line. Especially in management where managers won’t be around 4-8 years later when the contract is up for renewal.