Comment by finnthehuman | Hacker News Reader

Comment by finnthehuman | Hacker News Reader

Parent Full thread

This guy ties his ego to his code, and assumes everyone does the same. The proposed solution is to not devalue the person by devaluing the code.

This seems exactly backwards to me.

Disconnecting ego from the work was the first big lesson I had when I started working in software. I hear parallel ideas from friends across industries, in fact an electrical contractor explained to me how he expects it of his apprentices just a few days ago.

I once had a joint software team with a client and put my foot in my mouth assuming they separated code and ego the way we did. The first time I reviewed some of their work, there was a design decision that I sorta assumed was the best of a few bad options. So I asked the developer why they did it that way.

I just wanted to hear some reason, any at all would have done. Something special about that approach, or that they considered the others and found it was, in fact, the least worst. Then we'd just move on, happy enough with our implementation. I'm used to doing that (and having it done to me) dozens of times a month. But what I got was not a defense of the design decision, and more a defense that he made a design decision. I touched a nerve. I now know to hedge, apologize before giving feedback and ask questions by asking around them. I don't really think it's an overall plus. Especially when the business domain puts high standards on us.

I wish I had 100 up votes for this quote: "Disconnecting ego from the work was the first big lesson I had when I started working in software."

Until you can do that, you'll always be a lesser software developer. You'll concentrate on maintaining your ego instead of developing the best software for the problem at hand. In a way that's the gist of the article.

It's interesting, but at the company I've worked at, where we've had dozens of senior developers come and go, we've never had this problem. Our approach to code reviews is purely educational. "Here's how we do it so we have the least amount of trouble understanding each others code." Everyone seems to be good with that, and egos get left at the front stoop. I've learned lots, I've taught lots, and I've never felt better than anyone or worse than anyone. It's all about the learning.

And let me tell you, when you hire some junior dev, and he gets these code reviews, and 3 years later he's a senior dev and anchoring a project, it's a pretty good feeling. I think better than any feeling you can get from lording knowledge over others.

> Until you can do that, you'll always be a lesser software developer.

Reminds me of a joke-ish comment I saw on here some time ago: The difference between a junior and senior developer is the willingness to say "that bug was totally my fault".

Also, "maybe we shouldn't build that".

Also, "No, it's not worth all of the hacks and shortcuts it would take to get it done in the given time. We need to cut features, not quality."

lol

Well I guess that makes me a senior developer at heart despite never holding a development job

> Disconnecting ego from the work was the first big lesson I had when I started working in software.

100% agree. Any code you write for your employer is not your code - you should be comfortable leaving it forever tomorrow if a better opportunity presents itself elsewhere.

It's a theme I hear a lot when I see interviews of powerful business people - you don't do anyone a favor by pretending something that is bad is good.

Agreed that the OP took the wrong lesson - the fix is not to lower standards, the fix is to learn to deliver honest and complete feedback with empathy.

I've had my fair share of controversial code reviews, both on the giving and receiving end.

I no longer ask 'why?' inside a code review, because it immediately puts the author in the position of justifying what they did, while feeling like they have to defend a decision.

Instead, I'll take a coaching (or a more socratic) approach that doesn't risk making the author feel dumb, or like they never considered the alternatives: "what was your reason for this?", "did you try x,y,z?", "I wondered if this would work?", "what is this for?", "what does this do?"

In addition to that, if I have a suggestion (or a suqqestion [0]), I will always follow it up with a refactored, copy/pastable code snippet to make it clear what I'm talking about and also to help push the review forward. This is especially useful for learning by example.

This means that code review takes more time and effort, but that investment of time has value. Code reviews become an implicit, shared mentoring space, and people like it when they see your review pop up.

[0] https://www.urbandictionary.com/define.php?term=Suquestion

I find it fascinating that people don't immediately translate "what was your reason for this?", "did you try x,y,z?" and "I wondered if this would work?" to "why?" "why?" "why"?

Yeah I had to learn this lesson, and I think I will continue to find my ego cropping up in strange places, and again practice letting go.

My ego drove me to work extra hard to try and impress others. I would become petulant if I didn't get my way. I look back on the first few years of my career with so much cringe!

Couldn't agree more -- one of my first real important lessons in the industry on the soft skills side of things. What went along with that was that it really took a while to sink in and figure out not just how to personally avoid it, but in a team setting how to help build a culture of that.

> Disconnecting ego from the work was the first big lesson I had when I started working in software

I wish it was my first big lesson, it took me way to long to learn and my mental health suffered greatly until I did.

“Disconnecting ego from the work was the first big lesson I had when I started working in software” This is so important in Design as well.

Reply on news.ycombinator.com