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

161–170 of 309 posts

Re: Egoless Engineering

#161

Post by Aeolun »

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 are just there for a paycheck and to divert any possible responsibility away from themselves…

Re: Egoless Engineering

#162

Post by Aeolun »

robswc wrote: post #124
xyzzy4747 wrote: post #95

Earlier quoted context omitted.

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

I know its getting off topic but I never understood why people seemingly couldn't accept that. Current systems don't have a 1:1 with "hard work" and success/comp but its about as close as you can get, IMO.

It’s fine if everyone gets the same. It’s not fine if some people are more equal than others.

Actually, no, it’s still not fine, because whole heaps of people will pretend to be unable to do much.

Re: Egoless Engineering

#163

Post by Aeolun »

mc3301 wrote: post #149
01HNNWZ0MV43FF wrote: post #125

Earlier quoted context omitted.

If there's a country that doesn't speed and litter please get me a visa so I can go home

Japan (only 80% serious here)

Go to the countryside and be amazed. Exactly why people litter to that extend 20km from civilization escapes me.

But yeah, most people just bring their trash home.

For those interested, Visas are really easy to obtain as long as someone is willing to hire you.

Re: Egoless Engineering

#164

Post by cdchn »

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…

How does giving them deploy access prevent them from breaking the build, too?

Re: Egoless Engineering

#165

Post by pineaux »

travisgriggs wrote: post #152
agumonkey wrote: post #32

Earlier quoted context omitted.

the one who solves this problem will flood the world with a neverending wave of light.. every day I wonder how come I do so few now that I'm paid compared to when I was jobless and hacking prototypes for $0 finding the recipe for creating goal driven, high speed, high quality, frictionless teams is a difficult quest

Lobby your government to tax management hours. That’ll fix things. I often wonder how some open source projects manage to be so successful/productive with so little of what looks like corporate management.

How would you implement this though? Wouldn't things just be renamed?

Re: Egoless Engineering

#166

Post by rglynn »

01HNNWZ0MV43FF wrote: post #125
nox101 wrote: post #19

Earlier quoted context omitted.

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…

If there's a country that doesn't speed and litter please get me a visa so I can go home

Japan, although both of these are taken to the opposite extreme.

Re: Egoless Engineering

#167

Post by rglynn »

Aeolun wrote: post #163
mc3301 wrote: post #149

Earlier quoted context omitted.

Japan (only 80% serious here)

Go to the countryside and be amazed. Exactly why people litter to that extend 20km from civilization escapes me. But yeah, most people just bring their trash home. For those interested, Visas are really easy to obtain as long as someone is willing to hire you.

How is the work culture in Japan these days? Is it possible to find a company that doesn't have their peculiar (read "awful") work culture?

Re: Egoless Engineering

#168

Post by throwaway2037 »

didibus wrote: post #158

One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew…

    > hire more engineers
I was listening to a podcast with Joel Spolsky recently. He told a story that when he went to Microsoft, they had done internal research (and experiments) to debunk some of the theories from Fred Brooks' "Mythical Man Month". At the time, he generally believed in the "rules" from "Mythical Man Month", and was pleasantly surprised to learn about this further research. In short: Adding more developers does help, up to a certain point.

Re: Egoless Engineering

#169

Post by motorest »

spuds wrote: 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.

I don't think this item was well thought through. Taking proactive decisions means allocating work for tasks that do not solve a concrete problem but bear the risk of introducing regressions. On the absolute best scenario, things continue to work as always. On the absolute worst scenario, you introduce a critical regression that brings down the service. There is literally no upside and all downsides.

There are many reasons why "if it ain't broke don't fix it" is tried and true.

> * Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)

That really depends on what you mean by "walls". The reason Conway's law is a thing is that in order to have functioning teams you also need functional independence. If you need to book a meeting with anyone to justify pushing a change to a service you do not own, that's already a wall. No matter how easy it is to get through that wall, it's still easier to not have to go through it.

I can tell you an example of how independence always beats collaboration. Once I worked on a project where QAs were a separate team entirely, and made it their point to be the sole owners and maintainers of all automated test suites beyond unit and integration tests. We experienced a major regression that the regression test suite wasn't caught. I went right to the head of QAs and asked if I could push a commit to add a couple of regression tests. He politely declined by saying that they were already working on it and I wouldn't need to bother with that. Great, a victory for not building walls I guess? Except that his "we are working on it" ended up being "we added a ticket to our backlog and we might pick it up two months from now". Literally. And they never did, by the way, and the same regression was eventually introduced without anyone noticing.

In case you wonder how I solved that problem, I created my own regression test suite. Conway's law always wins.

Re: Egoless Engineering

#170

Post by solatic »

weitendorf wrote: post #88

Definitely agree that domain experts are preferable to domain owners, and that overly explicit specialization causes problems, but at the same time I think it's quite possible to stray too far in this direction too, and that the author didn't really address that. The problem is not just that the Designer might Break the Build or ship something broken one time (but know how to fix it). The problem is that stuff can (o…

> In these situations your "egoless domain experts" might actually need the authority to force these things to stop, or might get burnt out spending all their time firefighting or playing hero.

The broader approach here is to encourage frameworks where changes must go through policy-as-code frameworks. SMEs write policy that is then enforced (or just warned, for some period ahead of enforcement) by the policy framework. Policies can encode exceptions, but changes to policy (i.e. to add exceptions) require SME review. The benefit is - stuff that passes policy doesn't require explicit review, so in the normative case autonomous teams are not slowed down, and when they are (due to policy failure), then it is for Good Reasons.

> Mandatory code review isn't a "feel-bad program", it's precisely to guard against disasters like this (also I'm pretty sure it's literally required by SOX/SOC2 and I'd certainly want my software vendors to implement this).

High-trust environments trust engineers to understand the difference between "this is a serious change so I need someone to review it" and "I'm just fixing a typo here so I'm going to rubber-stamp it." But yes, SOC2 requires mandatory code review, tickets, the lot. Yes, it slows things down, but that is the price you pay to become a Serious Enterprise Vendor. No, it doesn't fundamentally erode high-trust culture. People can just mark their MRs as "I need a rubber stamp" and find someone else to rubber-stamp them.

Post reply on HN