The Best Programming Advice I Ever Got (2012)

When I think about those I consider A players in the C# world - Anders Hejlsberg or Jon Skeet - I absolutely do not see them capable of that behavior.

I'll give you two reasons:

1) It's not your code, it belongs to the company.

2) If you can't accept changes to code you worked on (NOT "your code"), you're unlikely to improve.

I agree these are not absolutes. It might be that you understand the subtleties of some particular device / library / whatever much better than other people, and their changes to the code you wrote with those quirks in mind are bad because of their lack of depth. Talk to them, or better yet use meaningful names / comments in the code so that they understand why you wrote it that way.

I've seen it happen more often at a startup than at the giant company I now work for. There are some people who will act like that no matter the circumstances.

Even on a purely technical level every organization has unprovable things its members believe in. Challenging any of these openly is a surefire way to get told in office-ese to STFU noob. Quietly demonstrating that they were wrong results in at least some cognitive dissonance, with all the mental fallout that gives. Even worse, you've done this after challenging them, and everyone gets defensive. And the absolute worst, as the author experienced, is when money or ideals is at stake, and you unknowingly shift the goal posts.

I worked at a place with mostly time-limited positions as my first job, and based on what my original boss said I'm pretty sure the new boss passed over my application because of politics like these. But like the author this only strengthened my resolve to question my own and others' assumptions.

This article is at best half useful, and missing the other half is potentially quite dangerous (to organizations, to people's careers, etc.) What's missing is a discussion of power and power dynamics (and healthy vs. unhealthy versions of same, let alone how to work effectively in either or drive change). Partly this comes down to a failure on the author's part to care about power dynamics or look at their own power. In this case the author was able to just blindly drive change by charging in like a bull in a china shop and the only consequence to themselves was a very minor verbal admonition, that's an indication of their level of power and where they sit in the overall power structure of their org, not every dev. in a similar position would see the same results, however. Many people would have to navigate that problem much more cautiously to avoid becoming fired or ostracized.

(Edit: and indeed I see another comment in this thread about someone who did exactly the same thing as the article's author and it turned out very poorly for them because they lacked the power the author has/had.)

Additionally, the author completely ignores the value of "soft skills" and implies that all that's necessary to have a positive impact where you work is to blindly seek the technologically superior choice whenever possible, ignoring politics, power, and ego (yours and others) along the way. There's value to that, but there's also great potential for that sort of mindset to lead you astray, because it's often difficult to know "what's best" in every situation. In the article's example the pros and cons were fairly straightforward, but most of the time the situation is likely to be a lot more complex or a lot more subtle. And it may be easy to make the wrong value judgment (and consequently fight the wrong technical fight) based on ignorance.

On top of that, this story is very frustrating because it only concerns itself with technical problems. At the end of the day the organization was still just as dysfunctional as ever even though it grudgingly fixed a technical problem it found it couldn't ignore. The author helped fixed a defect in code but they did almost nothing to help fix a much larger and more serious defect in the organization they worked in.