(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.
I agree with your comment about hiring the best. Would you rather have the 'best' [1] programmer who is also a team cancer or a group of good programmers who individually aren't better than the best guy, but as a group deliver better results?
[1] 'Best' can be defined so many ways that without a definition saying they only hire the best says very little.
In regards to your second point, I think we should optimize for the best team, not necessarily for the best programmers. Ergo, try to hire the best team player, not the best lone ranger.
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.
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.
There's something to be said for taking the simplest possible path. There's a temptation to "show-off" by doing something complicated. That generally leads to over-engineered solutions and difficult to maintain code. Good criticism would be pointing out a simpler solution.
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.
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.
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.
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.
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.
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.
Maybe own it till you're proud of it, then let it go! Schedules don't always allow every codule to be the shining star in your portfolio, but there should maybe be pride to be had in a really dirty hack done on an insane deadline ^_^
I think that just loving the process of developing and solving problems is a better approach.
We can be so much more than the artifacts we create.
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.
I don't think that was what the article was about, but I think that bare statement,"Your identity ≠ Your code", is wrong.
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.
(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.
I've mentioned before my rule of three. That is, my code will pretty much suck until about the third time that I've solved (or refactored) a problem.
If I ever come across code that I think is particularly nice, it's quite likely that the developer either reworked said code or has solved a very similar problem multiple times. If, on the other hand, I come across bad code, I generally assume the developer was simply pressed for time and created as much value as possible under the constraints.
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.
[1] http://en.wikipedia.org/wiki/Fundamental_attribution_error
[2] Unfortunately, I can't think of the correct term for this effect
