Live data from Hacker News

Egoless Engineering

egoless.engineering

281–290 of 309 posts

Re: Egoless Engineering

#281

Earlier quoted context omitted.

That these levers are the tool instead of mentoring and validating plans is an extremely strong signal these people should not be managing engineers. > Engineers have this lever of "technical ingenuity". LMAO this is not merely a lever. This is why you hired engineers.

I believe that the GP's point was that different roles have different tools in the box that are more efficient in their particular areas, and tend to rely on these rules even when solving problems in other areas. It is very common to see engineers trying to solve non-engineering problems using the "technical ingenuity" to attempt resolving social issues; sometimes it works well enough (e.g. timezones), and sometimes…

Exactly, and I'd claim this is even true in their area as well. "Technical Ingenuity" is the obvious arsenal in an engineer's bag, and that's why it will bias engineers as the solution to all problems, even engineering problems.

For example, on a previous team we had an issue where configuration was littered in too many places. It was confusing, and people didn't know where to change what in order to onboard a new client, and they'd always forget something.

Well, most engineers went directly to re-architecting/refactoring as the solution. We should centralize all config in some new central config store, and have all systems pull their configuration from there. Once it's all in one place, it'll be clear what to change and we can't forget to change any.

One engineer though said, we just need a good wiki that clearly describes all the steps. Well, that took about 2 days, and it solved the problem. No technical ingenuity needed.

Re: Egoless Engineering

#282

Earlier quoted context omitted.

And he'd be even more successful if he didn't insist on also being a complete, utter egotistical asshole. Leave whether or not you agree with his policy positions aside for a moment; it's fairly obvious that the guy is a complete shitheel of a person who's basically the dictionary definition of "brilliant asshole." Steve Jobs seems to have poisoned the brains of whole huge swathes of people into thinking that "being…

First, I have no idea if he's a "utter egotistical asshole". Never met the guy, and I assume that most people hating on him formed opinion of him by consuming heavily negatively biased sources. However, I assume he is some type of an "asshole". And "he'd be even more successful" if he wasn't is just very wrong, IMO. From my experience the top of any organization is completely overrun by assholes. Some smart, some dum…

> and I assume that most people hating on him formed opinion of him by consuming heavily negatively biased sources.

You know what they say about assuming.

I won’t begrudge the guy his successes, but I formed my opinion of him based entirely on his own actions. He broadcasts every other brain fart he has, I don’t need to rely on reporting to influence my decision making when he had himself and his half baked shower thoughts inserted into my feed directly.

I’d probably agree on the asshole front but. As in it being a contributing factor in some manner to some of his upwards trajectory.

Re: Egoless Engineering

#283

Earlier quoted context omitted.

I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.

I remember in a prior job that I had just joined when I was still new to the field, they had a bug board where they collected all the most common bugs users were experiencing. I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm workin…

I've worked in mid-sized companies where my job wasn't just one thing, and where I was not owned by a project manager. Other concerns existed. Even back at the ancient bank I worked at, our implementation of ITIL recognised this, and put incident and problem managers on equal footing with project managers. If a frequent issue is caused by some underlying problem, that problem needs to be fixed. Working on it was absolutely legitimate. During sprint planning a team could take work from the new features like or the bugs pile without interference from a project manager. If they complained that you worked on a bug, you could lean on the problem manager to talk to the project manager. If the project manager's timelines drift, part of their job is to deal with that, inform stakeholders and extend the deadlines. If they continually fail to factor in the possibility of conflicting work then they suck at their job. If their boss gives them shit for a slipping deadline that was out of their control, then they also suck. In your example the company allocate 100% of your time to working on new features and none of it to maintaining the product or keeping customers happy. There's no point in putting a brand new engine into a rusty car with bald tyres. This a bad organisation.

Re: Egoless Engineering

#284

Earlier quoted context omitted.

I believe that the GP's point was that different roles have different tools in the box that are more efficient in their particular areas, and tend to rely on these rules even when solving problems in other areas. It is very common to see engineers trying to solve non-engineering problems using the "technical ingenuity" to attempt resolving social issues; sometimes it works well enough (e.g. timezones), and sometimes…

Exactly, and I'd claim this is even true in their area as well. "Technical Ingenuity" is the obvious arsenal in an engineer's bag, and that's why it will bias engineers as the solution to all problems, even engineering problems. For example, on a previous team we had an issue where configuration was littered in too many places. It was confusing, and people didn't know where to change what in order to onboard a new cl…

You know... if you had managers that didn't suck ass this wouldn't be a problem and you could reign it in. Point proven exactly.

Re: Egoless Engineering

#285
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…

First time: teach them the right way to do that

Second time: you did it again, did you forget the right way?

Third time: we've talked about this before, what's the deal? If this keeps happening, we're going to have to reconsider your employment here as a web developer

Fourth time: last warning

Fifth time: bye

Good people don't do this sort of thing repeatedly. If your organization refuses to get rid of people like that, you shouldn't stay at that place either.

Re: Egoless Engineering

#286
post #9

Earlier quoted context omitted.

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer ne…

If you were the benevolent dictator of a small engineering with no stakeholders to answer to how would you fix this? How would you make ownership all the way to prod a reality and who would the owner be?

We have this. It's a culture thing. It's not actually possible to force someone to own something till production, but we encourage it and most people follow that.

One of the keys though, is a very easy process from development to code being in production. The more obstacles you put in the way, the less inspired a developer is to own the whole thing.

Not everyone is great at this, and people get frustrated when others don't own their stuff, but typically things are cordial and encouraging, rather than aggressive. But we're still a relatively small place (150 staff, about 40 developers), and inevitably, and sadly, this will change.

Re: Egoless Engineering

#287
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…

In my humble opinion, this is excellent advice. Honestly, so on point.

Re: Egoless Engineering

#288
post #175

Earlier quoted context omitted.

The context of "stop making reactive decisions" isn't "start making proactive decisions." It's to just make fewer decisions. The specific example is of a rare event which, while regrettable, does not justify the cost of policy changes to prevent it.

> The context of "stop making reactive decisions" isn't "start making proactive decisions." It's to just make fewer decisions. You don't get the luxury of not making decisions. You always have to make decisions.

What if the decision is to not do anything because the event is so unlikely to happen again that it isn't worth the cost to fix.

Re: Egoless Engineering

#289

Earlier quoted context omitted.

The failure in this paragraph is that our highest and most important ability as human beings is to self-evolve ourselves out of our selfish ego into its selfless version. That paragraph is as completely wrong in its understanding of human nature as a paragraph can be. Yes, it is difficult, but we are all capable of choosing to put ourselves through this self-evolution of our ego's vices into their corresponding virtu…

First of all, be it "self-modification". We all have some hopes about that, if we care enough. (Self-evolution implies playing with genes as species, which is a dangerous business.) As I personally caught the last chance to see a country promoting the selfless version, my stance is that the quote is spot on. We all have some hopes about altruism, if we care enough. But then you look around and 90% of people don't car…

First off, you are right about the "90%". The breakdown is that ~90% of that 90% are the uncommitted "confused by confusion" folks. who have neither committed to trying to be virtuous, or have committed themselves to selfish evil, which account for less than 10% of that original 90%. The uncommitted (~80%) vacillate from virtue to vice in their actions depending on how their day is going; ultimately, overall, they end up acting out of selfishness, as that is our default baseline state, which is a result of our body's mammalian heritage, with its packs and squablles for power and pleasure.

Still, the odds what they are, with the negative momentum of the selfish, by either their ebbs and flows, or by their deliberate selfishness, we must become good within ourselves for our own peace and happiness and for the ripple effects our goodness will have on those around us. It does not matter that those ripples will likely not progress very far out into the populace, because we need to do it for our own peace and happiness; that is why the universe's sublime Law of Karma exists (only for we humans with our free will, conscience, and mind) to give us internal feedback as to how our treatment of others affects their happiness, positively or negatively. That is why regime dictators are never happy or peaceful, as the unhappiness of the countless folks they have oppressed comes back into their being as a force of unhappiness. Stalin may have died in his sleep, but he was NOT happy.

The most important thing to understand is that, as evidenced by our knowing of but not in-any-way understanding Dark Matter and Energy, we live in a universe we don't understand very well yet. Our souls, minds, and free wills, are parts of our multi-dimensional selves that have no direct observability in this physical world -- we can only see some bits of their effects, and only if we are very open-minded and observant. So, when I talk about self-transformation, you must understand that our soul ("energy/astral body" that we dream with and resides within our physical body's 3-space while we are conscious) is what the spiritual path evolves/changes from vice-eousness to virtue-ousness, from selfishness to selflessness, from callous disregard to compassionate, caring service.

The spiritual self-evolution of human morality happens on that plane, not in our physical body. Yeah, that's quite a leap from where common human understanding currently is, at this point in history, but the destructively selfish ignorance is so deep and pervasive in nearly every culture on Earth that an open-hearted person should wonder how deep this willful ignorance goes, and what is its source. Read my other comments to find the explanation, if you are bold enough, that is.

Peace be with you. You are loved.

Re: Egoless Engineering

#290

Earlier quoted context omitted.

you fire them

That takes months or years if it's possible at all (at least in many places). For any place where you can neither fire bad devs nor find very good ones to replace them with, the trick is to make good processes and products using mediocre people. And that's hard . But that's also why a lot of processes appear, that would seem unnecessary to someone who is a good engineer and used to working only with good engineers.

You fire them anyway. The problem isn't incompetence. It's the inability to self reflect and see your own mistakes as mistakes that is missing.
Post reply on HN