[plaguepilled]

Interestingly, I feel like this sort of attitude is a real issue at the precise moment the author describes it as a boon.

When you are early to mid career, it is crucial to look for ways to amplify the good you can do in your workplace and solidify your brand as an individual. To do this, you should be looking, ironically, to elevate others. Doing so is the only way to build a reputation that people are going to actively WANT to talk about (e.g. "oh, having trouble? You should call in Jim, he helped me with a related thing"). This is invaluable.

Perhaps I am speaking through a lens, but had I taken the authors advice and taken a more combative role at such a juncture, I believe I would have far fewer opportunities now.

[noobker]

This transition from junior to senior includes another important skillset: balancing social dynamics against engineering realities.

The key is illustrated in the book club parable: The elitism is directed outside of the group and becomes only a means of alleviating the fear of judgement for misjudging the paper. The grad student's approach clearly communicates the socially agreed upon reality: the whole paper is crap. This stance and boundary provides a clear decision space to the learning junior members: "if you think you see a mistake, those here will be happy to hear it; no sacred cows".

Bringing this practice into a situation where the target is a member of the group's work changes the dynamics such that you have to mind your Ps and Qs again -- and so, dampens learning.

[dgb23]

My mantra related to that is "be mean to the code and nice with to programmer".

In order to learn and make things better you _have to_ be critical. But the way things are communicated is very important so everyone is on board.

"We could do better here" - no matter who exactly was responsible in the past.

"This made sense at the time but with what we learned..." - remind each other that improvement and learning is part of the whole deal.

"I like the simple and expressive core idea of this, but if we expand this further..." - elevate and develop the good stuff that's already there.

I make jokes about my mistakes, bring them up early and often. Everything is a bit lighter and easier with a bit of humor and without the fear of making mistakes.

And vice versa it is just as detrimental to be afraid to bring mistakes and inadequacies up and criticize them. It's much more fun and productive if things are continuously improving.

[edgyquant]

This works great until you get an engineer who pushes back constantly claiming it’s a time trade off or that this code is correct and you just don’t understand it. Sometimes humor doesn’t cut it.

[plaguepilled]

I have worked with a few such "strong personalities" and while I agree they can be slow on receiving criticism, I disagree that one should therefore resign to more forceful communication.

There are many alternative avenues in a professional setting when presented with an opportunity to argue, even if you're being blocked by a superior.

The crucial thing to remember is you cannot ensure your "social workaround" will work, but you can always ensure you act professionally. Whether that impacts the sprint is a matter of circumstance, but mild, cheery professionalism always improves the workplace culture.

[Retric]

Yea, some people can be unbelievably toxic.

[dkarl]

I think early to mid is too soon to be focused on others' work. Early to mid, you should be focused on the quality of your own work, because you're still developing your taste and judgment, and you need the direct and vivid feedback you get from immersing yourself in the consequences of the decisions you make. A huge trap in software development is to get disconnected from feedback and be a slave to rumor, ideology, and religious "best practices." The air is full of bullshit (in no small part because everyone is trying to "solidify their brand as an individual" and "amplify the good they do" before they actually learn the job) and the best way to learn how to sort through it is by grounding yourself in the consequences of making this decisions versus that one, choosing this approach versus that one.

If you start "amplifying" too early, you won't be amplifying selectively, and your coworkers would be just as well off sorting through search results themselves.

(Of course it's a progressive transition, and you're never too inexperienced to advise a coworker not to force-push master or submit a PR with failing tests.)

[dwhitney]

You can elevate others while pushing your ideals - once you truly understand something, you can teach it.