Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Egoless Engineering

egoless.engineering

Post reply on HN
Print view View original

91–100 of 309 posts

Re: Egoless Engineering

#91

Post by beepbooptheory »

dpc_01234 wrote: post #34

The stab at Musk seems out of place. You might not like him, or his politics, but he took over and reformed a slow and bloated place, and despite all the doomsayers Twitter is still working and IMO better than before. And he has a solid track record of delivering: finance app, electric cars, rockets. Sure he over-promises and under-delivers, sometimes borderline lies, etc. but there is a huge amount of wisdom behind…

Do we really have to do this? How can this possibly be in good faith? Like, its 2024 dude, he is literally going to hold unelected office in the US. He is unquestionably a polarizing person. I'm not saying you have to have one opinion or another, but unless you are truly living on mars right now, how can you even feel the need to make this comment? Are you not witness already to the surely GBs of text saying different variations of what you said and all the replies and all the next replies. Like it is borderline insane to me!

How can you possibly care? Do you really not feel like you have won yet? What is even at stake!?

I just dont even understand the discourse anymore. Can't yall all be like "oh he is simply genius, of course all these normies won't get it. we dont need their validation anyway!" And then maybe we can stop doing this? Please?

Re: Egoless Engineering

#92

Post by tbrownaw »

thanksgiving wrote: post #59

I want to go off a small tangent > In Theory There Is No Difference Between Theory and Practice, While In Practice There Is I for one used to believe in a cross functional team. I used to believe that everyone in a team should be able to do every task in the team. I still believe it somewhat but my ego is shattered. I worked on one team where the lead believed in this more than I ever did. Consequently, I was doing t…

> I for one used to believe in a cross functional team. I used to believe that everyone in a team should be able to do every task in the team.

Learning some skill requires X hours. Maintaining that skill requires Y hours/year.

Those numbers vary both by task (webdev has quite a bit of churn, where server OSes tend to have decade-long support lifecycles) and by person (not everyone learns at the same speed, and sometimes people learn different kinds of things at different speeds).

A team where anyone can do anything can work or now work, depending on how hard the things they do are, how many different things there are, and who's on the team.

Re: Egoless Engineering

#93

Post by itishappy »

oscillonoscope wrote: post #85
pjmorris wrote: post #45

An ageless idea... "There once was the first software engineering best-selling book. It was called The Psychology of Computer Programming (Weinberg 1971). There was a peculiar idea contained among the many excellent ideas of that book. It was the idea that the task of programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building. ... What’s the alternative…

I'm not entirely convinced that ego-less is even a better way of doing things. Sure, the ego can go overboard but it also gives a sense of drive and direction. It isn't just the bad stuff. Without it, there's nobody taking ownership of the design or it's just designed by an apathetic committee.

Pride and passion can exist without ego. I view this as appreciating things for what they are, not who they belong to.

Re: Egoless Engineering

#94

Post by MrLeap »

thanksgiving wrote: post #59

I want to go off a small tangent > In Theory There Is No Difference Between Theory and Practice, While In Practice There Is I for one used to believe in a cross functional team. I used to believe that everyone in a team should be able to do every task in the team. I still believe it somewhat but my ego is shattered. I worked on one team where the lead believed in this more than I ever did. Consequently, I was doing t…

> I was doing tasks I sucked at and therefore didn't enjoy s lot more because as she said, it will help me improve.

I've been here. I find it helpful to try and automate away reoccurring dread tasks. Not everything can be automated, but most things can be.

Re: Egoless Engineering

#95

Post by xyzzy4747 »

srid wrote: post #80
pjmorris wrote: post #45

An ageless idea... "There once was the first software engineering best-selling book. It was called The Psychology of Computer Programming (Weinberg 1971). There was a peculiar idea contained among the many excellent ideas of that book. It was the idea that the task of programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building. ... What’s the alternative…

The last paragraph is the interesting one, and here's the full quote in context: One of the reasons Communism eventually failed is that it assumed that we could all accept the philosophy "from each according to his ability, to each according to his need." The assumption that we could all subjugate our needs to those of others is about as faulty as the assumption that we can subjugate our egos for the betterment of th…

One of the reasons Communism failed was because of incentives. People were not rewarded with more compensation for working harder.

Re: Egoless Engineering

#96

Post by weitendorf »

01100011 wrote: post #73
weitendorf wrote: post #62

Earlier quoted context omitted.

People may bring ego into programming because of some kind of pathology (eg the need to always be right or in control) but I think in many cases it's because they truly care about the work. And the problem is not that they truly care, but that there is a mismatch between the amount of influence/control/autonomy they wish to exert on their work and the amount they are actually able to exert on it. I wasn't there, but…

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 o…

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.

Re: Egoless Engineering

#97

Post by xyzzy4747 »

nox101 wrote: post #19
datadrivenangel wrote: post #2

The part about intentional team values is very good: • Digs ditches. Nobody is too good for any task. • Returns shopping carts (even if nobody's watching). We leave things better than we found them. It's amazing how most teams don't set norms/values at all!

Western society (or at least USA society) seems to me to foster the idea of "not my responsibility". My example would be, going to a fast food place and not cleaning your table even though there are trashcans and places to put your tray. Spilling something and not even attempting to clean up after yourself. Unions have this in spades. "My job is X, I don't do Y, in fact I'm not allowed to do Y as that takes a job awa…

Incidentally I noticed in India most fast food shops have enough spare workers to clean tables for you. So you don't have to clean your own table.

Re: Egoless Engineering

#98

Post by dasil003 »

MichaelZuo wrote: post #67
weitendorf wrote: post #62

Earlier quoted context omitted.

People may bring ego into programming because of some kind of pathology (eg the need to always be right or in control) but I think in many cases it's because they truly care about the work. And the problem is not that they truly care, but that there is a mismatch between the amount of influence/control/autonomy they wish to exert on their work and the amount they are actually able to exert on it. I wasn't there, but…

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 a…

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.

Re: Egoless Engineering

#99

Post by worksonmymach »

oscillonoscope wrote: post #85
pjmorris wrote: post #45

An ageless idea... "There once was the first software engineering best-selling book. It was called The Psychology of Computer Programming (Weinberg 1971). There was a peculiar idea contained among the many excellent ideas of that book. It was the idea that the task of programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building. ... What’s the alternative…

I'm not entirely convinced that ego-less is even a better way of doing things. Sure, the ego can go overboard but it also gives a sense of drive and direction. It isn't just the bad stuff. Without it, there's nobody taking ownership of the design or it's just designed by an apathetic committee.

Taking ownership is very much egoless! You are doing that for the team.

Ego would be making sure you got "your" sprint tickets done, did no code reviews, skipped the retro. I think few people do that but they will if Goodhart's Law happens.

Re: Egoless Engineering

#100

Post by itishappy »

default-kramer wrote: post #90

Kind of tangential, but: > Then one day, our designer broke the build in the middle of the night. Everyone came in the next day and couldn’t work until they figured out what had happened. I've heard this [campfire?] story before. A bad commit happens and now no one can do any work. And I don't understand... Is it really that big of a deal to have to revert to an older commit or comment out the broken code until it ge…

Stateless code makes for boring programs, but stateful code can be difficult to roll back.

As a toy example, imagine a database with columns for `first name` and `last name` and an update that combined them into a single `full name` column. That's going to be tough to revert for users signing up with just their full names.

Post reply on HN