6 ms·

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 ex

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.

whateveracct 8y ago
> 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.
redleggedfrog 8y ago
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.
- Izkata 8y ago
  > 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".
  - tomlagier 8y ago
    Also, "maybe we shouldn't build that".
    - brianpgordon 8y ago
      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."
      - mirroredfate1 8y ago
        lol
  - meko 8y ago
    Well I guess that makes me a senior developer at heart despite never holding a development job
coleifer 8y ago
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!
yowlingcat 8y ago
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.
freewilly1040 8y ago
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.
daleco 8y ago
“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.
flukus 8y ago
> 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.
ljm 8y ago
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 https://www.urbandictionary.com/define.php?term=Suquestion
- switch007 8y ago
  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"?

whateveracct 8y ago

> 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.

redleggedfrog 8y ago

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.

Izkata 8y ago
> 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".
- tomlagier 8y ago
  Also, "maybe we shouldn't build that".
  - brianpgordon 8y ago
    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."
    - mirroredfate1 8y ago
      lol
- meko 8y ago
  Well I guess that makes me a senior developer at heart despite never holding a development job

coleifer 8y ago

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!

yowlingcat 8y ago

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.

freewilly1040 8y ago

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.

daleco 8y ago

“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.

flukus 8y ago

> 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.

ljm 8y ago

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 https://www.urbandictionary.com/define.php?term=Suquestion

switch007 8y ago
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"?