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

291–300 of 309 posts

Re: Egoless Engineering

#291

Post by Joker_vD »

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…

And sometime you really can't do anything except but waiting and letting the potatoes to grow, so to speak ("We plant potatoes in the spring, and harvest them in the autumn" — "Well, we plant potatoes in the morning and harvest them in the evening" — "Wow, do they really grow that fast at yours?" — "No, we just become really hungry by the evening").

Re: Egoless Engineering

#292

Post by deepakarora3 »

gorbachev wrote: post #285
Aeolun wrote: 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 th…

I see that you gave the person 5 warnings - I feel 3 times is less and this is exactly what I would do. Its so much better to give people more chances rather than less and then letting them go instead of letting an ego or something similar come in detween earlier.

Re: Egoless Engineering

#293

Post by maximus93 »

Egoless engineering is such a great mindset—focusing on team goals over individual credit really makes collaboration smoother and ideas stronger. It’s amazing how much better things get when everyone’s just working toward the best solution, not personal recognition. Definitely something more teams should embrace!

Re: Egoless Engineering

#294

Post by MrMcCall »

ulyssesv wrote: post #210
MrMcCall wrote: post #109

Earlier quoted context omitted.

Our expertise in any kind of technical skill that allows us to participate in society is of no importance compared to our becoming a positive member of all the societies/cultures we encounter. This requires becoming a compassionate, empathetic human being via deliberate, honest, self-critical work on the areas of our personality that cause unhappiness to others via selfish negativity. We are the only beings on Earth…

wow, thanks for this.

Thanks for the thanks, friend. You can find more info in my various comments in these last couple of days. I want nothing from anyone, I'm not trying to get anyone to convert to any religion or join any group. I just want you to be happy and learn how to help yourself help others. Happiness is only earned by making others happy. There are ways to help that process.

Peace be with you. You are loved.

Re: Egoless Engineering

#295

Post by gorbachev »

deepakarora3 wrote: post #292
gorbachev wrote: post #285

Earlier quoted context omitted.

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

I see that you gave the person 5 warnings - I feel 3 times is less and this is exactly what I would do. Its so much better to give people more chances rather than less and then letting them go instead of letting an ego or something similar come in detween earlier.

Please do not take number 5 so literally. It's the process that matters. You do 2, 3, 4, 5, 6, 7, 8, 9 or 10 chances whatever suits your needs. The actual point is you don't fire people on the first mistake unless you're an asshole.

Re: Egoless Engineering

#298

Post by seadan83 »

sensanaty wrote: post #192
bibabaloo wrote: post #12

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 feel this. The zero-sum pendulum of time is a bitch.

I wonder, are you under 35? This story reminds me of my experience. When I was younger, all the problems could be solved - all at once. I'd throw time at just about everything - cleaner code, fewer bugs, features delivered.

Later, the scope of what I was working on grew. No amount of time could be thrown at all the problems - it was zero sum. I had mentors try to guide me, to focus on solving what you need to, to focus on areas of impact and let the other things slide. If you don't, then the areas of impact never get done.

On the other side of the coin, the really frustrating part - is the bullshit processes you speak of. Time is zero sum. Yet, here was the team wasting time on another status meeting and time estimation; not getting the things done. Small quick wins, which do have impact, are not small quick wins because - did you fill out the TPS report regarding user impact? Did that get approval and story pointing? Is it a strategic initiative? No, then why are you working on it? Those are unhealthy orgs. Places like that I think are filled with folks that can't do the job and ride the coat tails of those that get shit done. These are also places where people want to go, clock in, and just not think that hard about their job - just do it and get home to their families.

Though, I've come to also appreciate that mentality too. I've never been a true owner at any place I've worked at. I've cared, I've been tricked into caring - but the long hours only went to enriching the person that had 1M shares, while I had just 2000. They were an owner, I was pawn.

Re: Egoless Engineering

#300

Post by Cpoll »

munksbeer wrote: post #286
safety1st wrote: post #212

Earlier quoted context omitted.

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…

> t's not actually possible to force someone to own something till production

Only in the same way that it's not possible to force someone to complete their work?

Put their name on the ticket and clearly communicate what it means to "own" a ticket (an oft-missed step). It's just another task, like writing the ticket, testing the ticket, doing security review, etc.

Post reply on HN