
Your identity ≠ Your code - kentonwhite
http://collectiveidea.com/blog/archives/2012/03/16/your-identity-your-code/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+collectiveidea+%28Collective+Idea+Blog%29
======
agentultra
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.

(But only if it comes from someone genuine of course... ignoramus' are an
unfortunate reality we all have to learn to cope with).

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

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.

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.

~~~
vibrunazo
> The easiest way to open yourself up to accepting criticism is to realize you
> are not the smartest person in the room

I think that's irrelevant. Every human being is stupid. Saying you're the
smartest person on the room, in absolute terms, is analogous to saying you're
the smartest termite in the planet.

Even if you're much smarter than others, that's irrelevant. Suppose the
smartest person on earth is right twice as often as other people. That might
sound like you're brilliant relative to others. But looking at the bigger
picture that just might mean that you're wrong ~80% of the time, and they're
wrong 90% of the time. From this angle, even the smartest person on earth is
stupid.

And I don't think the real numbers are too far from that. Human beings are
imperfect, our perception is incomplete, our sensors fail and our brain has
more bugs than windows vista. You cannot trust yourself. You're stupid, and it
would be even more stupid to not admit that.

We're all stupid. But the smarter of us understand that, and often correct
themselves. While the less smart, are the ones who think they're smart. And
insist on their mistakes.

~~~
agentultra
> _I think that's irrelevant._

Irrelevant? It's my entire proposition in no absolute terms. Of course
everyone is stupid and anyone with a modicum of critical thinking skills can
understand this. My point was that it is often difficult to accept criticism
because we're pressured to believe we need to be the best or at least better
than everyone else we see ourselves competing against. Criticism then seems
like a personal attack and makes it difficult to accept since it can lower
your perceived position amongst your peers.

Humility is the easiest solution I put forth. Once we realize just how stupid
we are we can look at criticism as a chance to learn something and improve
ourselves. And maybe when we give some criticism we'll try to be more
thoughtful and be constructive.

~~~
vibrunazo
I do agree. What I mean that is irrelevant is whether or not you consider
yourself the smartest person in the room. It's best to be humble, like you
say, even if you are the smartest person on the planet. Humility is important
regardless of how smart you are, that's all I'm saying. Because even if you're
the smartest human being, you're still just a human being. Which means you're
stupid anyway.

------
padobson
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"

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.

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.

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.

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.

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.

~~~
limeblack
> 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. > 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 very much agree with your statement, but wonder how many students force
themselves through school by comparing themselves to others.

For so many years, I would push myself in the desire of the shortcomings of
others, and success of myself.

Now with this anxiety and comparison gone, I am no were near as committed. My
performance has drastically decreased (practically failure in one class), and
my selfish hopes have subsided.

Do you have any advice on how to overcome this complacency without comparing
myself to others?

School feels insincere and not in agreeance with treating my fellow students
kindly.

------
hullibu
I agree, and I think this is probably a response to the recent post that
stated GitHub can be your resume.

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.

~~~
zmoazeni
I'm the author, and no, this was not in response to that post. However I don't
see them mutually exclusive.

I'm fine with Github being someone's resume, and in fact the less concern you
have over other peoples' opinions of your code, the better code you'll
actually write. It's like anything, practice makes "better" (not perfect) :)

I think code is a qualifier for evaluating a candidate, but that's not the
main indicator. In fact, I suspect someone won't go very far if all they do is
plagiarize other peoples' well written code.

I could be wrong though, I just don't have the balls to pull it off.

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

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.

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.

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.

~~~
zmoazeni
_> ...rather than this article's seeming recommendation of avoiding
association with your own work._

I'm not sure how you read into this. I certainly wasn't intending for that
statement. Code can be a medium of expression but it usually is a means to end
(a working solution). I don't think there's anything wrong in someone taking
pride in a solution. It's when their pride holds them back from improving or
worse, not even attempting due to the inevitable criticism that will follow. I
don't see them mutually exclusive, you just need a healthy dose of humility.

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

I'm sure there are many developers who just to clock in and clock out, however
I'm also guessing there is a good portion who want to take ownership but are
afraid of the risk of criticism. And fear it for the wrong reason.

------
lince
The good part: You get more compelled to improve your programming skills and
style. The bad part: Lot of procrastination and fear of rejection.

I think that just loving the process of developing and solving problems is a
better approach.

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

~~~
zmoazeni
I'm the original author, and I agree with your point. I _do_ think the things
you produce are _part_ of your identity. It's when a person mentally replaces
"part of" with "is" that it becomes dangerous.

We can be so much more than the artifacts we create.

~~~
w0utert
One thing you didn't mention in your article, but which I think is a relevant
and interesting observation to make, is that 'your code =/= your identity'
works both ways.

It's not just that you should not project messy code onto someone's
personality/identity, but you also cannot reliably do the inverse. I know
people who are meticulously organized in everything they do in real life, who
hate to be around a mess, who always want schedules, predictability and
stability in their daily life, who optimize their daily routines to
perfection. Yet they write lousy code, take shortcuts, do not think the
problems they solve through enough, etc. Likewise, I know people who are
chaotic in every way, who don't adhere to many of the things almost everyone
else considers to be the norm, who have little to no self-discipline for
mundane tasks, who are non-conformist by choice, and who are often perfectly
aware of these shortcomings. Incidentally, I count myself into this group.
Despite all this, I consider the code I write to be very thorough, organized,
maintainable, proven to be very resilient to bugs, efficient, etc. The process
that gets me there may not be the prettiest, thought-out, elegant process you
could imagine, my workspace may be cluttered with 10 terminals, my temp dirs
maybe full of old cruft, and so on, but still, I consider the products of my
work to have all the qualities I seem to lack in real life.

So apparently, personality really doesn't say much (if anything) about the
quality of the software you write. It's a profession that is so far from our
daily lives that you cannot project one onto the other or vice versa, exactly
like you already wrote.

~~~
j_baker
_Likewise, I know people who are chaotic in every way, who don't adhere to
many of the things almost everyone else considers to be the norm, who have
little to no self-discipline for mundane tasks, who are non-conformist by
choice, and who are often perfectly aware of these shortcomings._

You'd consider those to be shortcomings? I'd consider them to be strengths.
Granted, you can take those strengths too far such that they _become_
weaknesses. But as long as you're careful not to turn them into a Golden
Hammer, I wouldn't count those as weaknesses.

~~~
w0utert
In some ways I can imagine they could be strengths, or at least beneficial in
some situations. For example being chaotic and non-conforming sometimes you
learn something you would otherwise miss out on. Most of the other things I
mentioned only work against me, such as lack of discipline, not finishing
stuff I started, or lack of focus and not being systematic enough and getting
hugely frustrated about forgetting where I left something.

I guess like always, truth is somewhere in the middle.

------
voidfiles
Code is just like other external indicators to who you are. Talking, clothes,
hair style all inform people as to who you are.

I don't think that was what the article was about, but I think that bare
statement,"Your identity ≠ Your code", is wrong.

------
michaelochurch
_Stop equating bad code with bad developers. Stop equating code criticisms as
a knock against you as a person._

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

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.

~~~
zmoazeni
I was considering elaborating on this point in the post, but the post was long
enough already. So I decided to keep it out. But I think this is a very
important point.

 _(1) you really don't know what conditions caused the code to become bad_

There is totally a spectrum all the way from laziness to understandably tight
deadlines to unreasonable deadlines. You totally hit the nail on the head.
There is a lot more context surrounding why code is written the way it is than
just "This guy/gal is horrible".

 _(2) it means you make an enemy of the one person who can help you out_

There are peers of mine that I look up to, that I consistently am impressed
with and they continually push me to be a better developer. The funny (and
slightly embarrassing) thing is that for most of them that I met early on I
thought were idiots. The favorite phrase "You're doing it wrong!"

I'm lucky that I kept my mouth shut and honestly tried to digest their
perspectives/opinions. Now I may still disagree with them, but it's from a
place of respect, not out of condescension.

I joke with one of my favorite coders, <https://twitter.com/#!/bkeepers> ,
that the first time I met him I thought "This dude is a complete asshole." And
I ignored him for months afterwards. That was all from my own insecurity.
Brandon is a hella smart and nice guy.

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

~~~
crusso
I had to give you an up vote just for making me google "Eckhart Tolle" and
read the wikipedia page on him.

As I read the main article for this thread, I was thinking, "what does this
guy mean by 'identity'"? A little jaunt down a philosophical rat hole can be
fun sometimes.

------
Confusion
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 _in general_ : i.e. dumb, incompetent,
incorrigible _by nature_. 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.

[1] <http://en.wikipedia.org/wiki/Fundamental_attribution_error>

[2] Unfortunately, I can't think of the correct term for this effect

