5 ms·

When programmers are real programmers or just know how to do it dudes

26 points by snitko 17y ago

araneae 17y ago
Oh whatever. People are continually obsessed with being "real"- being a "real" atheist or a "real" Christian, being a "real" submissive, or a "real" man, or a "real" whatever. What it really comes down to is that some people think they are better whatever it is- Christian, programmer, or man- than other people. And in order to prove this, they make up some arbitrary definition of what it means to be a "real" this or that. The only one who cares is you and your big fat ego.
- snitko 17y ago
  You didn't make it to the end of the post, didn't you?
  - Groove 17y ago
    In dissecting his statement I presume he is having conflicting issues with his religion and masculinity. Presumably being challenged socially or in an introspective way based on how he "feels" about himself. Possibly soon to be herself.
    - araneae 17y ago
      You managed to offend me here, but not for the reasons you think. I have two very close friends who are transgender, one of whom got transitional surgery less than a week ago, so you can go fuck yourself.
  - araneae 17y ago
    I did. The point still stands. It's akin to how people say that we need Mexicans in the country, because who else is going to do the farming? You can declare a group of people both necessary and inferior all in the same sentence.
- gaius 17y ago
  Case in point: ESR's how to be a hacker.
alexgartrell 17y ago
First, the "know how to do it dudes" thing is kind of lame. But that's not super relevant to the argument he's making. I think the author has an interesting idea, but kind of fails to follow it through to the end. More than anything, he's hinted at a division that I think is present here at HN. My only beef is that he was kind of a dick about why 'real programmers' would do what they do. "Of course it does not mean they're destined to work their whole life like that - they can still quit and start their own company, but probably not as much because they want more money and their own business, but more because they disagree with, say, the corporate policy for brackets {} style." This, as much as anything, solidifies the authors argument that he is not a "real programmer". I think that real programmers get excited in the same way that the "dude who ..." (and so on) does, but only about products that have the properties of both being incredibly technologically interesting as well as useful. This is arguably where things like Linux and Google came from.
- j_baker 17y ago
  In fact, my experience is that the "dude" would be the one more likely to quit over bracketing. Issues like that are simply boring to real programmers (which I consider myself). A more valid reason for a real programmer to leave a company would be that they can't get anything done because people keep complaining about their bracketing. :-)
- snitko 17y ago
  You're right, I was kind of a dick saying things this way. But I didn't mean to seem disrespectful. I greatly respect real programmers and I often wish I was one and had the sources for motivation which are available to them. Actually, I was hoping I managed to be a dick to both sides in this post.
  - alexgartrell 17y ago
    I think you succeeded in that, it's just going to seem biased to anyone reading it, because they'll inevitably fall one one side or the other and agree with exactly half of your dickish statements. Maybe I was a little oversensitive :)
10ren 17y ago
To clarify his terminology: the "real programmer" values the means; the "dude" values the ends. It's a question of what one values, and this does tend to be mutually exclusive, in the specific sense that when they are in conflict, you must choose one over the other - which one do you choose? That shows what you value. While you can be highly skilled at both, you will tend to focus on what you value more, and therefore practice it with greater attendance, and therefore get better at it (and you probably were better at it in the first place - which is why you value it). I think Catmull (of Pixar) is a great example of brilliance at both means and ends - but he values ends. This "real programmer" is a professional, who will tend to be obsessed with technical skills, whether they are useful or not, because to him these skills are valuable in themselves. The "dude" is an entrepreneur, looks at what is needed, and how these needs can be met. Here's an illustrative story: I met a surgeon who worked in Nepal for 10 years, as a missionary, religious calling. Although he tried really hard, and worked really hard, he felt he didn't make any lasting impact, and in fact, he said that "digging ditches" for sewage would have helped more people, by preventing diseases through better sanitation. I was excited about this deeper understanding, and asked him why he didn't do that. He said that it was because he was a surgeon, and his skills would be wasted if he didn't use them. He cared more about means (being a surgeon) than ends (actually helping people). He was a professional. I enjoy solving problems. It's exciting, interesting and engaging. But it seems to have a kind of negative basis, like a doctor preferring sickness to health, or a priest who practices always compassion, never appreciation. But in the end, it's far better to care about something - whether it's means or ends - than to care for nothing at all.
- michaelneale 17y ago
  Wow that is really quite profound.
- xtho 17y ago
  Almost anybody can dig ditches but fewer specially trained people can do surgery. Leaving aside remuneration and social status, when optimizing the use of your resources, you'd let people with that training to the surgery in order to achieve your goals in the most efficient way. So one could say that he actually cared about optimal use of human capital in order to best (= in cheapest way possible) achieve the goal. If you take the problem to that level, do you still care about the means or the ends?
chipsy 17y ago
There's definitely a huge ego thing in distinguishing yourself as a "real programmer" or perhaps a "software engineer," vs. "a <x> who programs" or "a weekend hacker." In other words, a professional vs. an amateur. I don't think it reflects at all on the quality of the work, though, just on the attitude brought to the table. The professional is going to want to overengineer, more often than not, because surely, with all the vast knowledge and experience they've accumulated, tackling the business's requirements with a quick hack is beneath them when they could do a "real" long-term solution instead! Right? Coming at it from the "amateur" perspective instead is going to shift the perspective towards the opposite - the underengineered "good enough for now" solution that may ignore fundamental architectural problems until they've blown up into huge monsters. So for a startup or early-stage product, the amateur attitude is probably the more worthy one, and as the concept establishes itself into more refined forms, professionalism, process, and specialization can take hold. But the skills could easily be just as good from either angle - you just have to learn to "flip the switch" and use the right attitude for each situation. I've spent a long time obsessing over programming practice, and it's only been recently that I've managed to make myself back off. This conveniently started to happen only as I started pushing myself 100% to build a real, user-facing product, vs. some development tool or hack.
j_baker 17y ago
(Full disclosure: I definitely fall under the real programmer category) I agree with about 90% of what the author said. However, I don't know that I agree that the "dudes" and "real programmers" shouldn't work on a project together. In fact, I think it's good for them to be in a state of healthy conflict. I also would dispute that the "real programmer" would be more productive than the "dude". The real programmer would probably outperform the dude in terms of sheer amount of code written, but the dude is likely to get more done. I think that the ultimate product would be that the dude would actually get the product done and the programmer would make a higher-quality product that won't fall apart at the slightest change.
- snitko 17y ago
  Since you're not the first to say this in the comments to the post, I simply must surrender and at least review the point - indeed it might be good for the project to have both people on the team. But I suppose only when both have certain qualities. What do you think those qualities are? And when does the team of 2 different types outperform the team of equal types?
  - j_baker 17y ago
    I think that both groups always outperform each other and are always behind each other at the same time. It's that the two groups are really working towards different goals. The dude will likely want to get a product out as quickly as possible. The real programmer will want to make something that will be maintainable and good to work on in the long-term. I think this is why you will see conflict often between the two groups if you're not careful. Personally, I think that the key is understanding. Both types need to recognize that the other is working towards a valid goal and that sometimes the other's goal is more important. Otherwise, you end up with two people who wonder why they never agree on anything.
julius_geezer 17y ago
"So, what's a real programmer? I believe it's the one who's obsessed with the programming itself, not with the result. It's the guy who would spam your IM with tons of code and discussions about it 4 times out 5 when you have a conversation." That sounds to me like pedantry. Isn't the real programmer the one who knows programming well enough that he has not just mastered the detail but can put it in perspective?

26 points by snitko 17y ago

Oh whatever. People are continually obsessed with being "real"- being a "real" atheist or a "real" Christian, being a "real" submissive, or a "real" man, or a "real" whatever. What it really comes down to is that some people think they are better whatever it is- Christian, programmer, or man- than other people. And in order to prove this, they make up some arbitrary definition of what it means to be a "real" this or that. The only one who cares is you and your big fat ego.

snitko 17y ago
You didn't make it to the end of the post, didn't you?
- Groove 17y ago
  In dissecting his statement I presume he is having conflicting issues with his religion and masculinity. Presumably being challenged socially or in an introspective way based on how he "feels" about himself. Possibly soon to be herself.
  - araneae 17y ago
    You managed to offend me here, but not for the reasons you think. I have two very close friends who are transgender, one of whom got transitional surgery less than a week ago, so you can go fuck yourself.
- araneae 17y ago
  I did. The point still stands. It's akin to how people say that we need Mexicans in the country, because who else is going to do the farming? You can declare a group of people both necessary and inferior all in the same sentence.
gaius 17y ago
Case in point: ESR's how to be a hacker.

alexgartrell 17y ago

First, the "know how to do it dudes" thing is kind of lame. But that's not super relevant to the argument he's making. I think the author has an interesting idea, but kind of fails to follow it through to the end. More than anything, he's hinted at a division that I think is present here at HN. My only beef is that he was kind of a dick about why 'real programmers' would do what they do. "Of course it does not mean they're destined to work their whole life like that - they can still quit and start their own company, but probably not as much because they want more money and their own business, but more because they disagree with, say, the corporate policy for brackets {} style." This, as much as anything, solidifies the authors argument that he is not a "real programmer". I think that real programmers get excited in the same way that the "dude who ..." (and so on) does, but only about products that have the properties of both being incredibly technologically interesting as well as useful. This is arguably where things like Linux and Google came from.

j_baker 17y ago
In fact, my experience is that the "dude" would be the one more likely to quit over bracketing. Issues like that are simply boring to real programmers (which I consider myself). A more valid reason for a real programmer to leave a company would be that they can't get anything done because people keep complaining about their bracketing. :-)
snitko 17y ago
You're right, I was kind of a dick saying things this way. But I didn't mean to seem disrespectful. I greatly respect real programmers and I often wish I was one and had the sources for motivation which are available to them. Actually, I was hoping I managed to be a dick to both sides in this post.
- alexgartrell 17y ago
  I think you succeeded in that, it's just going to seem biased to anyone reading it, because they'll inevitably fall one one side or the other and agree with exactly half of your dickish statements. Maybe I was a little oversensitive :)

10ren 17y ago

To clarify his terminology: the "real programmer" values the means; the "dude" values the ends. It's a question of what one values, and this does tend to be mutually exclusive, in the specific sense that when they are in conflict, you must choose one over the other - which one do you choose? That shows what you value. While you can be highly skilled at both, you will tend to focus on what you value more, and therefore practice it with greater attendance, and therefore get better at it (and you probably were better at it in the first place - which is why you value it). I think Catmull (of Pixar) is a great example of brilliance at both means and ends - but he values ends. This "real programmer" is a professional, who will tend to be obsessed with technical skills, whether they are useful or not, because to him these skills are valuable in themselves. The "dude" is an entrepreneur, looks at what is needed, and how these needs can be met. Here's an illustrative story: I met a surgeon who worked in Nepal for 10 years, as a missionary, religious calling. Although he tried really hard, and worked really hard, he felt he didn't make any lasting impact, and in fact, he said that "digging ditches" for sewage would have helped more people, by preventing diseases through better sanitation. I was excited about this deeper understanding, and asked him why he didn't do that. He said that it was because he was a surgeon, and his skills would be wasted if he didn't use them. He cared more about means (being a surgeon) than ends (actually helping people). He was a professional. I enjoy solving problems. It's exciting, interesting and engaging. But it seems to have a kind of negative basis, like a doctor preferring sickness to health, or a priest who practices always compassion, never appreciation. But in the end, it's far better to care about something - whether it's means or ends - than to care for nothing at all.

michaelneale 17y ago
Wow that is really quite profound.
xtho 17y ago
Almost anybody can dig ditches but fewer specially trained people can do surgery. Leaving aside remuneration and social status, when optimizing the use of your resources, you'd let people with that training to the surgery in order to achieve your goals in the most efficient way. So one could say that he actually cared about optimal use of human capital in order to best (= in cheapest way possible) achieve the goal. If you take the problem to that level, do you still care about the means or the ends?

chipsy 17y ago

There's definitely a huge ego thing in distinguishing yourself as a "real programmer" or perhaps a "software engineer," vs. "a <x> who programs" or "a weekend hacker." In other words, a professional vs. an amateur. I don't think it reflects at all on the quality of the work, though, just on the attitude brought to the table. The professional is going to want to overengineer, more often than not, because surely, with all the vast knowledge and experience they've accumulated, tackling the business's requirements with a quick hack is beneath them when they could do a "real" long-term solution instead! Right? Coming at it from the "amateur" perspective instead is going to shift the perspective towards the opposite - the underengineered "good enough for now" solution that may ignore fundamental architectural problems until they've blown up into huge monsters. So for a startup or early-stage product, the amateur attitude is probably the more worthy one, and as the concept establishes itself into more refined forms, professionalism, process, and specialization can take hold. But the skills could easily be just as good from either angle - you just have to learn to "flip the switch" and use the right attitude for each situation. I've spent a long time obsessing over programming practice, and it's only been recently that I've managed to make myself back off. This conveniently started to happen only as I started pushing myself 100% to build a real, user-facing product, vs. some development tool or hack.

j_baker 17y ago

(Full disclosure: I definitely fall under the real programmer category) I agree with about 90% of what the author said. However, I don't know that I agree that the "dudes" and "real programmers" shouldn't work on a project together. In fact, I think it's good for them to be in a state of healthy conflict. I also would dispute that the "real programmer" would be more productive than the "dude". The real programmer would probably outperform the dude in terms of sheer amount of code written, but the dude is likely to get more done. I think that the ultimate product would be that the dude would actually get the product done and the programmer would make a higher-quality product that won't fall apart at the slightest change.

snitko 17y ago
Since you're not the first to say this in the comments to the post, I simply must surrender and at least review the point - indeed it might be good for the project to have both people on the team. But I suppose only when both have certain qualities. What do you think those qualities are? And when does the team of 2 different types outperform the team of equal types?
- j_baker 17y ago
  I think that both groups always outperform each other and are always behind each other at the same time. It's that the two groups are really working towards different goals. The dude will likely want to get a product out as quickly as possible. The real programmer will want to make something that will be maintainable and good to work on in the long-term. I think this is why you will see conflict often between the two groups if you're not careful. Personally, I think that the key is understanding. Both types need to recognize that the other is working towards a valid goal and that sometimes the other's goal is more important. Otherwise, you end up with two people who wonder why they never agree on anything.

julius_geezer 17y ago

"So, what's a real programmer? I believe it's the one who's obsessed with the programming itself, not with the result. It's the guy who would spam your IM with tons of code and discussions about it 4 times out 5 when you have a conversation." That sounds to me like pedantry. Isn't the real programmer the one who knows programming well enough that he has not just mastered the detail but can put it in perspective?