8 ms·

Your identity ≠ Your code

96 points by kentonwhite 15y ago

hullibu 15y ago
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 15y ago
  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.
tsewlliw 15y ago
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.
- artursapek 15y ago
  Yeah, and in terms of getting a job, I think it's well-accepted that your code reflects how good you are as a developer...
  - recursive 15y ago
    That's true, but my job isn't my identity either.
    - bmj 15y ago
      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.
- zmoazeni 15y ago
  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.
  - tsewlliw 15y ago
    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.
  - w0utert 15y ago
    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.
lince 15y ago
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.
losethos 15y ago
Everybody else is a brainwashed imbecil. I wrote a kernel and compiler. The genius academics fall for useless faggot languages because those languages tickle their faggot bone. Is it really better to alphabetize your soup cans or is hashing okay? Is ever stricter typechecking better et nauseam? Linus programs in C. Peter Gadwa banned ASM macros. Wise experienced programmers know not every feature is good to use. I banned preprocessor #define functions in LoseThos -- didn't make them. A 10,000 line program is fine with global variables. If you disagree you are a brainwashed faggot who cannot reason for yourself. Namespaces on a program of 10,000 lines? Is more namespaces better, et nausea? I used to think C++ operators were cool. They only make sense fo linear algebra and complex numbers, though. I loath the STL. See my sort demo to be blown away. It will shock you. http://www.losethos.com/LTHtml/Demo/MultiCore/RadixSort.html http://www.losethos.com/LTHtml/Demo/MultiCore/RadixSort.html By not using a library I got a factor of 5 speed-up. Code reuse is very rare. Don't make tiny source files. Put all header entries in one file.
AznHisoka 15y ago
Eckhart Tolle would say we don't even have an identity.
- crusso 15y ago
  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.
  - tim_buck 15y ago
    Ugh, I wish I didn't know about him but Oprah had a lot of the world brainwashed at one point that he was the man. He had some interesting ideas, but he is just another new age evangelist trying to sell his wares. Basically anybody that doesn't write the books for free is about making money.
agentultra 15y ago
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.
- kentonwhite 15y ago
  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".
- matwood 15y ago
  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.
michaelochurch 15y ago
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 15y ago
  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 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.
crusso 15y ago
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.
- tfm 15y ago
  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 ^_^
- zmoazeni 15y ago
  > ...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.
padobson 15y ago
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 15y ago
  > 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.
voidfiles 15y ago
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.
Confusion 15y ago
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 http://en.wikipedia.org/wiki/Fundamental_attribution_error [2] Unfortunately, I can't think of the correct term for this effect

96 points by kentonwhite 15y ago

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 15y ago
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.

tsewlliw 15y ago

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.

artursapek 15y ago
Yeah, and in terms of getting a job, I think it's well-accepted that your code reflects how good you are as a developer...
- recursive 15y ago
  That's true, but my job isn't my identity either.
  - bmj 15y ago
    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.
zmoazeni 15y ago
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.
- tsewlliw 15y ago
  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.
- w0utert 15y ago
  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.

lince 15y ago

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.

losethos 15y ago

Everybody else is a brainwashed imbecil. I wrote a kernel and compiler. The genius academics fall for useless faggot languages because those languages tickle their faggot bone. Is it really better to alphabetize your soup cans or is hashing okay? Is ever stricter typechecking better et nauseam? Linus programs in C. Peter Gadwa banned ASM macros. Wise experienced programmers know not every feature is good to use. I banned preprocessor #define functions in LoseThos -- didn't make them. A 10,000 line program is fine with global variables. If you disagree you are a brainwashed faggot who cannot reason for yourself. Namespaces on a program of 10,000 lines? Is more namespaces better, et nausea? I used to think C++ operators were cool. They only make sense fo linear algebra and complex numbers, though. I loath the STL. See my sort demo to be blown away. It will shock you. http://www.losethos.com/LTHtml/Demo/MultiCore/RadixSort.html http://www.losethos.com/LTHtml/Demo/MultiCore/RadixSort.html By not using a library I got a factor of 5 speed-up. Code reuse is very rare. Don't make tiny source files. Put all header entries in one file.

AznHisoka 15y ago

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

crusso 15y ago
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.
- tim_buck 15y ago
  Ugh, I wish I didn't know about him but Oprah had a lot of the world brainwashed at one point that he was the man. He had some interesting ideas, but he is just another new age evangelist trying to sell his wares. Basically anybody that doesn't write the books for free is about making money.

agentultra 15y ago

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.

kentonwhite 15y ago
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".
matwood 15y ago
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.

michaelochurch 15y ago

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 15y ago
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 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.

crusso 15y ago

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.

tfm 15y ago
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 ^_^
zmoazeni 15y ago
> ...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.

padobson 15y ago

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 15y ago
> 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.

voidfiles 15y ago

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.

Confusion 15y ago

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 http://en.wikipedia.org/wiki/Fundamental_attribution_error [2] Unfortunately, I can't think of the correct term for this effect