Sometimes a person's dedication and care expresses itself to others as ego. Sometimes it is just ego.

I think we've all implemented some clever trick in our code that we started to feel proud of. It's hard not to do. Even if you just contribute to a small piece of the project, you still might have those instances of pride. We're all human, and it's fine to take a little motivation from your accomplishment. But hold on loosely. Be critical of your baby and be willing to throw it out if it isn't the best approach.

I used to really like driver/embedded programming because it seemed like there was a 'best approach' or idiomatic solution for most problems that eliminated ego. It felt more like electrical engineering. I often felt programmers working on higher level software treated their work like a personal art project and that turned me off from it.

The problem with "ego" as a concept IMO is that it carries negative connotations with most people and isn't exactly well-defined - some people might see it as always a bad thing (I think you might fall into this camp given that your phrasing "dedication and care expresses itself to others as ego" rather than saying it merely is ego). Personally I think that that is ego, but that ego is not necessarily a bad thing.

There is nothing wrong with taking pride in your work, nor in recognizing that you might actually be more knowledgable/skilled/correct in some particular matter than someone else and communicating that to them - as long as that sense of knowledge/skill/correctness is not misplaced, not expressed cruelly, and the actual reasoning is explained. To me, that is "good ego". But if someone thinks they always know better than someone else in all cases or isn't even willing to open discourse/explain why that's "bad ego".

I guess to me, the sentiment expressed in this article is one that I feel strays too far into the realm of toxic positivity or crabs-in-a-bucket where merely being opinionated or passionate about your work is a bad thing because sometimes other people get their feelings hurt when you explain why their approach won't work well. I just don't think being egoless is necessarily good. I certainly wouldn't sit there smiling while something I worked on for years got destroyed by other people, because it'd be impolite or egotistical to point out that they're destroying something. But of course, there is a difference between something actually getting ruined, and having a meltdown because someone started naming variable in snake_case instead of camelCase.

I would argue that in fact you do need a critical mass of ego throughout the ranks of engineers in a large organization. An engineering culture where engineers don't care inevitably leads to abdicating responsibility for overall system health and even data/workflow correctness as PMs attempt to steer the ship without understanding the implications of what they are asking for. Once this has gone on for a while, the system will be so intractably broken, and the dead sea effect will have caused such a brain drain of all those capable of fixing the problems, that at some point there's no economical path to restoring the software systems to a healthy and maintainable state. At that point you might as well just call in the private equity guys and figure out how to extract maximum cash out of the business as it stands, because any code change becomes more likely to break more things than it improves.

So yeah you need ego. That said, it must also be tempered with the reality of needing to compromise enough to satisfice all stakeholders (including both technical and business stakeholders of all the different flavors). The beautiful thing about software engineering though, is there is a reasonable amount of objective facts, metrics and tradeoffs, that given a critical mass of sufficiently skilled and mature engineers, common ground tends not to be too hard to align on. Or at least, far easier than to get a non-technical stakeholder to understand the long-term implications of a bad decision.

Agreed.

To make the best work you have to take pride in it. This work has my name on it, customers will use it, I want to improve their lives not make them worse.

The developers who come after me will need to assimilate this work. They'll need to build on it. I want to make their work a joy, not a burden.

Do I take pride in what I do. It's not enough that the code just compiles.

Pride is balanced by humility. I'm prepared to defend my choices (with well informed, well experienced) answers. But the choices I make are always a balance of upside and downside. And over my career things have changed which reweights some of those decisions. I'm open to external input from others because I want the result to be good not me to be right.

I want to be proud of my work. But I'm humble enough to let others help me to improve it.

[The above is my goal, sometimes I fall short]

Huh. I thought it was thought of negatively because people confuse the word ego (self) with egotism/conceit (exaggerated sense of self-importance).

The same sadly has happened with confusion of the word selfless (having no concern with self) with unselfish (concerned with others before oneself) and altruistic (unselfish concern for others' well being).

Personally, I don't see any incompatibility between having a sense of self and healthy self-esteem and having compassion.

Indeed, I see a major incompatibility between actual selflessness and universal compassion - as selflessness would preclude compassion for oneself.

Selflessness merely means understanding that selfless service to others' happiness is a fundamental element of the spiritual path. We do not have to love them more than ourself, just equal, but we must take the chances we get to serve their happiness as much as possible.

You're right about the negativity of the ego's self-important nature via conceit and egotism. Those are negative traits of the self. The goal of self-improvement is to become a consciously virtuous person who puts the needs of the whole in its proper place, and doesn't indulge their selfish vices, which always cause unhappiness to those around them.

Positive self-esteem, when due to being a compassionate person, is a necessary component of the self-evolving person, because honesty in grokking the truth of ourselves is an important part of our growth.

And, remember, universal compassion also includes being compassionate to our own self, and as we increase our virtuosness, we are ever more beloved by the universe, itself. The happiness on that path is not known by but a small minority of the world's cultures/societies.

Sorry I'm not writing so clearly this late in the day, but know that the ego we have a birth is mostly selfish. It takes a definite turn towards the light to begin the process of purifying it by degrees from egotist to self-actualized bearer of compassion. It's a true fight, fighting against our own fallabilities and weaknesses and selfishnesses. But it's the most worthy struggle we will ever undertake.

Well the ‘pathology’ is clear, isn’t it?

They’re not actually smart enough to keep track of what every other team is doing, at any point in time.

FOSS works because there’s usually only at most a few dozen balls in the air simultaneously, so someone who believes they can keep track of balls in the air gets by without looking ridiculous.

But that’s just not viable when there are hundreds or thousands of balls in the air simultaneously… their eye muscles literally couldn’t move and focus fast enough.

I think FOSS really only works well for infrastructure type of projects, things where the customers are downstream programmers or at the very least very technical sysadmin types and power users who can understand the gory details to some reasonable depth. Those projects work because they are centered around proven abstractions that are broadly applicable, thus allowing for a tight charter and some stability in requirements.

End user software by comparison, has not really been successful in the FOSS model. There have been many attempts, but they perenially lag behind commercial offerings, and thus primarily see adoption from the ideologically motivated and/or very cost sensitive users.

Check out Hackers, by Steven Levy, for some fun tales from early in computing.