Live data from Hacker News

Egoless Engineering

egoless.engineering

261–270 of 309 posts

Re: Egoless Engineering

#261
post #80

Earlier quoted context omitted.

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.

Did it fail though? China is doing pretty well and by most metrics Russia is doing worse post communism.

Re: Egoless Engineering

#262
post #161

Ok, but how do you deal with people that submit broken CSS, break the site, and are unapologetic? Especially when you are in no position to fire them (because laws, or organisation)? All these “if you do it this way it works” posts seem to assume everyone has the best of intentions (or at least want to do the best job possible), and especially in corporate settings I just don’t think that’s always the case. People ar…

If it's clear someone is not acting in good faith, I can think of three options:

1. Find out why and try to fix it

2. Fire them

3. Embrace the low-trust environment by trying to mitigate the dysfunction with layers of bureaucracy

Strategy 3 seems quite popular, and to be fair it might be the only one that scales.

Re: Egoless Engineering

#263
post #204

Earlier quoted context omitted.

Literally on the second slide: "I’ve done engineering since the turn of the century, and led small teams and biggish orgs." If that is not navel-gazing or humble bragging, what is?

I would propose to you that those might be factual statements. I don't really see any self-indulgence in stating where one is coming from when writing a post that is a critique of organizations. It is a pretty common thing for people giving a talk to introduce themselves to give an idea of the experience on which the information that follows is built, normally at much more length. I don't think it is uncommon for peo…

I‘m sure it‘s factual and common, but it‘s tone-deaf given the slide deck title.

Re: Egoless Engineering

#264
post #80

Earlier quoted context omitted.

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.

>People were not rewarded with more compensation for working harder.

Nit: they had worker’s medals and similar non financial recognition.

However yes, the price paid for labour was far below the point to ensure supply met the demands of economic development.

Re: Egoless Engineering

#265

Kiva's engineering drew quite a few lessons from Etsy, though we never got so big. I think Dan is missing mentioning one ingredient: Security. Not code security, the human feeling of personal security. Most especially, of being secure in one's role. And that drives so much of this. If everyone is secure in themselves, or able to transcend worrying about their personal security, then magic happens. Without it, things…

Years and years ago I helped someone with a remote team (quite a while before remote was common) try to get his team to be more productive.

We'd sit and chat about the state of things, ups and downs since we last spoke, and try to figure out strategies to improve process and get things working more smoothly. For a few months virtually nothing changed despite all kinds of small efforts scattered around.

He was dealing with pretty insane stuff. Clearly competent developers were letting PRs languish for weeks. They weren't producing code to their own standards consistently. Designers were dumping deliverables last minute with no documentation or guidance for implementation. Just assets, hurriedly put together, with some palpable hope that they'd just get used and everyone would carry on without their involvement. There was no collaboration, very low communication, and hardly any cohesion across teams.

After a few months I came to realize that everyone was struggling in their role in some way or another, afraid to admit it, and unsure of how to catch up and keep up. Expectations of them were remarkably low, but no matter who fell behind they would eventually begin this oscillation between scrambling and vanishing.

I recommended that he let everyone know it's okay. We all fall behind, we've all got life going on, and having no deliverables happens. I suggested that the messaging would need to be sincere, clear, and personal in order for everyone to really believe that it was okay that they weren't performing well. After a week or so of figuring out how he wanted to address everyone about it, he did it over a group call and was a total human being about it, describing his own struggles, challenges with staying on task, his inability to program "well" due to his lack of training, and so on. It was great, and very sincere. He made it clear that he knew what was happening, but he wasn't upset and he wasn't pointing fingers.

The results were like night and day, though not immediate. Everyone gradually started explaining where they were. Maybe they had kid stuff in the way, got stuck getting a test to pass, didn't understand the problem well enough, no sleep, sick, etc. PRs got reviewed more often because there was less shame around letting them sit at all. Everything generally got better. Not perfect, but workable.

At the time that I recommended he do that, I felt a little bit insane. Like, what if this just permits everyone to be even worse? What if it comes off like it's a trap, and everyone gets even more paranoid and insecure? Am I just imagining everyone wants this because it's what I've wanted in the past?

Since then I consider it one of the most essential components of functioning teams. People can still be high performers in unsafe roles, but the team as a whole suffers for it, then the company does as well. Especially the company, over time.

Re: Egoless Engineering

#266

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…

What I have been thinking a lot about lately is that the focus should not be on the work. The focus should be on the handoff. If you build something, the goal is to have someone else use it. The work should focus on easing that transition. If it's a technology, what do you need to characterize so that the product people can work with it? If it's a product, how do you make it easy for your customers to get it? If it's an internal tool, what context and familiarity does the user group have?

Re: Egoless Engineering

#267
post #3

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…

> Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.

This is a central theme in Bruce Schneier's 2003 book Beyond Fear, which I continue to recommend 20 years after I first read it.

Re: Egoless Engineering

#268
post #3

Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * Don't add process just for the sake of it. Only add it if seriously needed. * Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.) * Stop making reactive decisions. If something bad happened on a total, e…

The Process Person who wants to build a Mature software organization will say, process is seriously needed.

That dork can only become factory manager when there are factory workers, see? "Process" is just a word for a production line of some kind - narrower or broader, but still a life-sucking endeavor.

Re: Egoless Engineering

#269
post #53

Earlier quoted context omitted.

Claiming that the "egoless" crowd is egotistic, because "they want everyone to think like them" is like claiming the "tolerance" crowd is intolerant, because "they don't tolerate intolerance". In my experience, It's both non-factual (ego-less people are the first to learn from others when poised with new ideas) and short-sighted.

There's a manifest difference between people who are naturally humble+curious, and people who are idealistically seeking an "egoless" environment. The latter is what I am referring to. Now that you mention it, there are parallels with the "tolerance" ideologues. There are people who are naturally patient and empathetic, and then there are people who opportunistically pursue the in-vogue virtue of "tolerance", and end…

I can agree that there's people who preach tolerance but don't actually seem to mean it, yeah. Have yet to see egotistical egoless-ness, but I'd suppose it'd just look like empty speech in a smilier fashion.

Re: Egoless Engineering

#270

Kiva's engineering drew quite a few lessons from Etsy, though we never got so big. I think Dan is missing mentioning one ingredient: Security. Not code security, the human feeling of personal security. Most especially, of being secure in one's role. And that drives so much of this. If everyone is secure in themselves, or able to transcend worrying about their personal security, then magic happens. Without it, things…

Chapters 4 and 5 of "Crucial Conversations" were an enlightenment for me, as full of cringe as it is.

Their hypothesis (intuitive, no science there) is that fear has second side beyond passiveness, wall-building and procrastination.

Fight or flight: people attack mostly out of fear. People micro-manage employees mostly out of fear. At work you don't think much about this aspect, as boss is simply a "jerk". (Bad mouthing, yet another way to deal with fear.)

Post reply on HN