“You are not your code” is a popular saying in developer circles with the idea being that the code you create is just code, and you shouldn’t be offended if someone points out faults, makes jokes, or is pessimistic toward it.
In order to spend weeks, months, or years building something you have to have an enormous amount of passion for it. This intensity is what drives you to wake up day after day to work on it. It’s not just “code” to you. It’s a part of you. It’s a love affair.
To me, it relates back to school projects. If you put in the work and really tried then received a bad grade it’s personal. If you are lazy, don’t care, and just turn in the minimal who cares if you get a bad grade because you are not the work you put in. Maybe that is the difference between why the saying is offensive to some and not others?
Take this guy who built his own log cabin by hand:
If you were invited to come see it as his guest would you start pointing out the flaws in his work? If you did would he want to punch you in the face? Or would he say, no big deal it’s just nails and wood? You and I both know he’d be offended.
When you put yourself out there through any creative endeavor you are being vulnerable. You are sharing a part of you that isn’t natural and to be slighted is like taking a dagger right in the gut. It hurts.
Unless feedback is specifically asked, it’s best to point out the positives and keep your complaints to yourself. As the old saying goes, “If you don’t have anything nice to say, don’t say anything at all”.
Agree? Disagree? Sound off in the comments below.
Eric L. Barnes 
If you have experience in building log cabins, and you come visit this guy and see that the roof he is building is too heavy, will surely collapse at one point on top of him, will you hold back and say – nice fireplace you’ve got there?
LikeLike
Do you really believe that bad code will eventually collapse and literally kill you?
LikeLike
Mārtiņš was mostly just using your analogy, and I’m sure he doesn’t think that a poorly written CRUD validation will cause death.
On a larger scale it depends what system is being built. Poorly written code can absolutely kill, especially as we move into an age of self driving cars and all sorts of drones.
Of COURSE feedback should be given politely, with humility and respect, but if providing constructive criticism to your team-mates, peers, open-source collaborators, etc causes them to lose their shit, then that person is going to be a problem for the company.
“I’m pretty worried about this PR Gary is submitting, but every time I try to give him feedback he gets all defensive and screams at me…”
Does that sound like a productive situation? Is that a trait you would want in a team mate? 😕
LikeLiked by 1 person
Without feedback you are limiting yourself.
The best feedback comes unsolicited and the worst feedback comes unsolicited.
To be able to optimice yourself to receive feedback, you need to be able to deatach yourself and your feelings from your work. If you fail to deatach, some constructive and valid feedback is going to be subject to your biases and be discarded only because of the feelings you had when receiving it.
But is not only about feedback from other people, is also self-feedback. Solving problems and finding solutions is our craft, but coding, databases, networking, devices are just a part of it, the part that changes a lot. We learn from the problem while we are solving it, so we need to constantly re-work our code and solution. Taking pride in your code is limiting your capacity to adapt quickly and learn.
Instead taking pride on your code and your implementations, be proud of your ways, your discipline, your team communication, your standards, your craft.
LikeLiked by 1 person
Interesting post and something I’ve not thought about in that way before. But feedback is very important for me. I take great pride in my work but if I ignore constructive feedback then I’m ignorant to my own faults. If I want to improve I not only want to hear feedback, but encourage it. Key is being constructive not destructive (which we can do to ourselves).
Of course, if somebody doesn’t want feedback then I’ll respect that; I’m hoping now I haven’t crossed that line, but this is my opinion so I hope not! 🙂
I suppose it’s different from being in a team and working on something for you. A team you need that feedback I think and, as a developer or designer, it can be hard. not to say it’s not rewarding getting that feedback; one company I worked with had the saying “feedback is a gift” and, as much as it sounds like “biz speak”, it’s true in the right way.
I try and swallow my pride and take on board what people say and I’ve found myself better for it.
LikeLike
As with all things… it depends.
My opinion is that your responsibility as a developer to accept and work with feedback varies depending on what the nature of the project is. In some cases you’re in the right to take ownership of it and in others this is a caustic behavior. Feedback is always useful, however, not every type of comment is feedback. As a commenter you are never off the hook for using empathy, intelligence, and constructiveness in your comments.
If what you’ve created is a personal project, which you own, and which nobody else is paying for, then my opinion is wholly in line with the idea that its like the log cabin metaphor above. The burden is on the one who wants to give feedback to do so in complete deference to your feelings and sensitivities. Your code is a reflection of your vision and passion.
There may be some other cases where this isn’t quite the same, and where being overly sensitive might be inappropriate and in some cases, a problem that needs to be solved.
The lesser of these cases is when you make an app that hosts a community. There are many subscribers and other members, who through your board have invested a tremendous time in building and gaining value from the community formed there, whether its months of payments or dozens of answered questions. If you make changes; both as subscribers and even just as community members, they have a vested interest in the site/application and are entitled to voice how those changes affect them. I do not think that comes without limits though, but I want to mention the other case first.
The stronger of these two is when you are working on a project for someone else. Sometimes you may be the lone developer, other times a member of one of many teams, or anything in between. Here we talk about ‘code ownership’ as a problem. Developers who get touchy about others “touching *their* code” or who get frustrated or offended by his or her PR being returned with change requests are corrosive. Usually, the cause is just devs who have had limited experience working outside their bubbles and a good team will have empathy and work to bring him or her around and make the team a “safe place” for contribution while still upholding standards of quality.
The main point is, regardless of whether unsolicited feedback on your project is expected or not, feedback should provide the receiver with something useful and be through an interface that is compatible with that user. Rudeness, dismissiveness, discouragement, and frustration have no role to play in constructive feedback. Most people with healthy psychology do not implement the motivated-by-abuse interface. When you fail to comprehend that and push on with destructive comments, you betray your own immaturity and newness. A little empathy and delayed review of your own comments can go a long way to making them work.
LikeLike
At some point, if you’re in the business of making things, you have to care more about improving and learning new things instead of just getting a good vs a bad grade. Cause you’re never going to be an expert at everything, right? Some people deal with that by just sticking in their small areas. Yeah it does suck to get bad feedback, and you’re never gonna please everyone in the crowd, but you can’t let that hobble you.
LikeLike
I’ve been coding for nearly 50 years, and managing engineering teams for close to half that time. In my experience, junior programmers do identify with their code, but the ones who go on to become great programmers grow out of it and realize code is as much a liability as an asset (and the ones who, after many years of coding and climbing the engineering levels, still strongly identify with their code are generally asses and no-one wants to work with them).
LikeLike