

When programmers are real programmers or just know how to do it dudes - snitko
http://romansnitko.posterous.com/when-programmers-are-real-programmers-or-just

======
10ren
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.

~~~
xtho
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?

~~~
10ren
Good point, thanks, I was thinking I should have addressed that. The thing was
that no one was digging ditches. Yes, given a choice, it would be more
efficient to use unskilled labour than a surgeon... but it would be better to
have a surgeon doing it than having no one doing it.

In practice, I imagine his role as an advocate and organizer: a kind of
charity-entrepreneur, and maybe leading by example, gandhi-style, rather than
being an ordinary ditch digger. "This is so important, that I can save more
lives by doing it instead of doing surgery". Of course, there are many
problems with making infrastructure changes, cultural, practical, political;
and maybe it needs special talents, skills, values and especially personality
that even a highly intelligent, competent and committed surgeon may lack. But
if you believe that's the best way to improve health, and you are committed to
improving health, then...

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

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

~~~
snitko
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
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 :)

------
j_baker
(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
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
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
"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?

------
araneae
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
You didn't make it to the end of the post, didn't you?

~~~
Groove
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
_her_ self.

~~~
araneae
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.

