Your identity ≠ Your code

The easiest way to open yourself up to accepting criticism is to realize you are not the smartest person in the room, so to speak. It is never about being the smartest person because at some point even the smartest person will be replaced. I've learned to accept criticism by realizing that it's not about where I am now but where I am going. As long as I can look back on code I've written in the past and think to myself that I could do better now then I feel I'm headed in the right direction. Criticism then becomes a tool to keep me on course and I am grateful to receive it.<p>(But only if it comes from someone genuine of course... ignoramus' are an unfortunate reality we all have to learn to cope with).<p>It can be hard to learn to accept criticism of our code. So much emphasis is put on being the smartest or the brightest person. All too often I hear people at start-ups and companies say things like, "We only hire the best people." (To which I smile and wish them luck). A lot of effort is put into evaluating code in order to determine the worth of a programmer so I hardly find it surprising that it is common to conflate code with intelligence (or random computer science trivia for that matter).<p>I really appreciate articles like this. I think people should be a little more bold and creative when they sit down to write a program. It doesn't hurt to be impractical once in a while. Or absurd, witty, or whimsical. It should be something to be enjoyed, studied, and improved over time.<p>All that being said there is room for improvement in how we deliver criticism as well. A few less pejoratives would be helpful. As well as having something constructive to say. It's not always about ranking people according to some ideal standard.

Everyone seeks validation. Everyone is looking to justify their existence. It is the very essence of the human condition to find something we can point to and say "I have value because of X"<p>All too often, X = Someone else's flaws. This is the first great shortcoming in the human condition that we have to get over. Validating ourselves by pointing out the flaws of others cripples relationships and society as a whole.<p>The next logical step in this progression is X = My Career. Money is the ultimate measuring stick in our society, so the thing that we all do to make money is what we often use to declare our value.<p>This is also a mistake, because whatever your career achieves - whether it be shipping a new piece of code or inventing a widget - your contribution to society will ultimately be fleeting. It may out live you, but it will not last.<p>The realization we all need to come to is that our value compared to one another does not determine our worth. The greatest human being is not substantially different from the least human being. And in realizing that the difference between human beings is unsubstantial, the only way to determine your worth as a human is how well you treated your fellows.<p>Feed a hungry person. Clothe a naked person. Shelter the shelterless. Cheer up the depressed. Comfort the mourning. That's where you'll find validation. That's where worth is derived.

I agree, and I think this is probably a response to the recent post that stated GitHub can be your resume.<p>However, one thing I've learned in recent tech interviews, and I'm a senior developer, is that if you don't provide good code in those interviews, you will fail those interviews. Therefore, regardless of the method you use to hack, you better be prepped for writing some solutions to well known problems quickly and easily if you want a job.

The article raises some interesting issues. I've solo written my fair share of prototype or rush-to-market code that tens of millions of dollars of revenue became dependent upon and then had to deal with criticism over how I wrote it years later from guys who really wouldn't have gotten hired if I hadn't hacked the hell out of things in the first place to close the deal and get the money flowing.<p>That said, when I look across the spectrum of developer types from those who feel too much ownership of their code vs. those who take no ownership of their code -- I find the latter to be more common.<p>These days, when I'm advising junior developers on how to make their mark while getting better at their craft; I lean more toward stressing their need to take ownership of the code they write and the projects they work on.<p>I'd agree more with another poster in this thread, agentultra, who stressed learning to accept criticism -- rather than this article's seeming recommendation of avoiding association with your own work.

The good part: You get more compelled to improve your programming skills and style. The bad part: Lot of procrastination and fear of rejection.<p>I think that just loving the process of developing and solving problems is a better approach.

On the other hand, your code is definitely a part of your identity, and projects that are awesome got that way because people poured themselves into their work. For me, only the pieces I'm passionate about become part of my identity.

Code is just like other external indicators to who you are. Talking, clothes, hair style all inform people as to who you are.<p>I don't think that was what the article was about, but I think that bare statement,"Your identity ≠ Your code", is wrong.

<i>Stop equating bad code with bad developers. Stop equating code criticisms as a knock against you as a person.</i><p>To me, what I find jarring is how common bad code is and how incredibly rare well-designed systems and good code are. It seems obvious that the causes of bad code are numerous (only one of which is unskilled developers) and the conditions that allow good software to be created are very rare. You have a lot of "goldie-locks" variables that ruin everything if out of a narrow range. One of these is time pressure. If there are tight, rigid deadlines the code will turn bad, but if there's no sense of time pressure at all the code will usually rot in a different way (becoming increasingly "clever" and impractical after the project is essentially finished but no one wants to admit that).<p>I've come to the conclusion, over the years, that getting mad at people for "writing bad code" is both useless and wrong, because (1) you really don't know what conditions caused the code to become bad, and (2) it means you make an enemy of the one person who can help you out. I've generally come to view standing code-quality problems (and the lack of budgeted time and resources to fix them) as a managerial fault.

Eckhart Tolle would say we don't even have an identity.

This is an example of the fundamental attribution error[1]. When confronted with bad code, we tend to attribute this to the dev being bad. This in turn[2] leads to the idea that the dev is bad <i>in general</i>: i.e. dumb, incompetent, incorrigible <i>by nature</i>. If you manage to forego such thoughts (and that requires active effort!), you will often find people are much better persons, capable of much more, than you would have thought otherwise.<p>[1] <a href="http://en.wikipedia.org/wiki/Fundamental_attribution_error" rel="nofollow">http://en.wikipedia.org/wiki/Fundamental_attribution_error</a><p>[2] Unfortunately, I can't think of the correct term for this effect