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.
I think this is the most important lesson that I learned in Grad. School. Taking a few courses in abstract mathematics quickly strips away any illusion that a scale of "smartness" is anything but flawed. The best you can get beyond a certain level of intelligence is improvements based on either subject level experience (intuition in the mathematical fields) or conscious changes that you do on a day to day basis. Unfortunately, this kind of requires that one is open to not being so dickish about the validity and absolute cleverness of one's solutions and be open to learning new stuff. Sad to say this but I agree with your assertion that both engineers and companies that hire them suffer under the delusion that intelligence is correlated with trivia know how. I have no problem with companies believing this (groups don't generally have to be as smart as individuals) but individuals who are under the impression that they are "rockstars" can be rather trying to work with.
This is so true. I welcome criticism because it forces me to evaluate my work critically and make changes if need be.
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.
This is very true. Also, the software development process is very empathetical. We need to be in constant touch with the end user and make sure we're pushing for the right features.
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.
You are what you code! If someone criticizes or changes your code, they want to change a trace of your soul or of your mind. If you accept their criticism it means you were wrong. And if you were wrong once, that means you can be wrong more in your new programming. If you once made a mistake, how can you not make more? And how can someone else or you, can trust yourself if they know you made a mistake and they caught you red handed? And if you accept any critic, that means noone will have confidence at your code (or at you, because you are what you code). If you welcome critics, and change your code, your personality will change again and again; instead of a respectable, rigid person, you will end up being the soft guy everyone will push anywhere.
What you said is not at all true, my parent commenters; it is my critic at you, and of course if you accept it.
ps: this is just a satire, and i fully agree with my parent commenter s.
Interestingly enough, I have very little personal connection to my code [1]. I'm almost sure there are better ways to code everything I've ever coded in the last 15 years. I know this because when I look at old code that I have written I see better ways to do it, and that's just me!
I think my lack of personal code connection comes from the fact that I view code as a tool to solve a problem. My overall solution I will certainly defend and feel that it reflects who I am, but the code to implement it? Who cares. I love elegant code as much as the next programmer, but at the end of the day for many problems the code is just an implementation detail.
[1] I've worked with people who have a deep personal connection to their code, and it can be very challenging to change anything without upsetting them.
> 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.
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.
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.
Sorry, but I don't buy the "It is a truly wise man who believes he is not" meme. A truly wise man has confidence in his wisdom, and the humility to realize that it isn't infallible.
Giving graceful criticism is as hard as gracefully accepting criticism. That's what I liked about this article -- decoupling the person from the code on both sides of the equation. My favorite line is "Criticize the code, not the developer".
It's alright (and should be encouraged) to enjoy programming. I'm not sure it's worth being "bold" and "creative" though. For me, I'm keenly aware of my limitations. I'm human and I'll screw something up, or forget why I did something "clever" when I look back at code I wrote 6 months ago.
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.
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.
> 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.
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.
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.
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.
> ...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.
Fine line to walk, isn't it? Taking ownership of your code would seem to be pretty closely related to taking pride in your work, and the motivations that entails. Having worked with and for $BIG_COMPANIES I would have to agree with your observation that the majority of developers are not, uh, enjoying a personal association with the fruits of their labour, and it shows.
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 ^_^
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.
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.
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.
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.
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.
Right, when I got my current gig, I took a HUGE ego hit because I went from just committing stuff to getting absolutely everything code reviewed, and that means bugs in my code were pointed out before I'd had a month to think everything I'd done earlier was crap :) You definitely need to be more to yourself to weather harsh lessons.
Yes, but it is part of your identity. That said, while I enjoy my job, and take some satisfaction from it, it isn't the whole of my being. My family, faith, and hobbies define who am I more than what I do.
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.
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.
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.
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.
To me, what I find jarring is how common bad code is and how incredibly rare well-designed systems and good code are
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.
(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.