
Dont call yourself a programmer (2011) - MindTwister
http://www.kalzumeus.com/2011/10/28/
======
CodeMage
_sigh_ Again?

There are tons of great advice in that post, but the title and the eponymous
section are based on something I didn't buy the first time around, either:
_“Programmer” sounds like “anomalously high-cost peon who types some mumbo-
jumbo into some other mumbo-jumbo.”_

Heck, I'm just 34 years old, but you make me feel like a friggin' _dinosaur_
because I got into this line of work out of my love for _programming_. It used
to be an exciting thing to do, with a whole world of new things to explore.
Nowadays you have people who are trying to make it sound like you're doing
something mundane and boring, like you're expendable and should be ashamed of
not having achieved anything greater than being a nerdy peon.

Look, as far as I can tell, it doesn't matter what _you_ call _yourself_. From
what I've lived so far, until you build up some solid skills and experience,
nobody gives a damn if you come up with a fancy name or explanation for what
you do. And once you've built up some cred, it won't matter what you call
yourself either, because you'll be able to prove your worth.

Here's another piece of advice people don't offer frequently because it's not
glamorous: do what makes you happy. We all grow up thinking we want to be
rich, famous and/or powerful. If that's what you still believe in, go read or
watch "Fight Club". Then come back and try different things and different
paths. Maybe founding startups will make you happy. Then again, maybe working
for BigCo Inc. and programming your own stuff on the side will make you happy.

TL;DR: The post offers good advice, but use your own judgment. There's nothing
wrong in being a programmer.

~~~
phillmv
Of course there isn't. A programmer will probably always be a (relatively)
high-skill, high-wage job.

The point behind the post is that 'programmer' in business thoughtspeak means
you're basically an undifferentiated commodity. "Programmers" are people
you're always trying to outsource to India.

If you want to improve your career, you need to market yourself better. You're
not paid to write code; you're paid to provide business value.

~~~
CodeMage
_You're not paid to write code; you're paid to provide business value._

I once had an argument with a friend who had an indie game development
company. He wanted to develop games so he could make money. I wanted to
develop games and make money off them. It's a very subtle difference that
becomes clearer when you dig deeper: he would have (e.g.) made soap if he
thought it was a better way to make money; I wouldn't, because for me the
important part was "developing games".

It's true that you're not paid to write code, but provide business value
instead. Indeed, good programmers will try to write as little code as possible
and if they can provide business value by _removing_ code, so much the better.

On the other hand, if you're reading the OP out of your own interest, you're
most likely not being paid to provide business value by drawing pictures of
stuff or assembling furniture or arguing in the court of law (to give some
examples of activities), but instead you're being paid to provide business
value by dealing with code.

Yes, you need to market yourself in order to improve your career. Good
marketing won't hurt and really bad marketing can hurt you badly. None of that
means that you should disregard the fact that you _are_ a programmer and that
good programmers _aren't_ an undifferentiated commodity that you can
"outsource to India" without second thought.

I agree that marketing yourself is important, but there are many -- perhaps
too many? -- people telling kids that marketing is important and not enough
people telling them that doing what makes you happy and becoming awesome at it
"just because" is even more important. I'm just trying to help balance the
scales ;)

------
agentultra
Great advice if you want to optimize for salary.

Most of this stuff I learned from the streets and I've done pretty well
following it.

However I've reached a point where a bigger salary, better benefits, and
equity offers won't cut it for me anymore. There's a hidden nugget in this
article that suggests that there are things in life outside of work which are
better sources of happiness. One of the sources it fails to mention is
accomplishment and achievement. If you are a programmer that spends their time
reading the latest research, crafting your skills by implementing a compiler
for some exotic language you're interested in, and following your passion then
you will find optimizing your career by writing CRUD forms for an accounting
package for 8+ hours a day to be an incredible waste of time and energy.

(It's also incredibly hard to develop a source of accomplishment and
achievement if you spend the majority of your life being bored)

I've once heard the advice that you should optimize for happiness and great
things will begin to happen. If modelling weather simulations is what turns
your crank you will never be happy building web APIs to a legacy CRM system.
If you enjoy pushing the envelop of static analysis then what good are you
doing for the world hacking on a javascript front-end for a client at a
creative agency? Rather than optimizing for salary you optimized your life
around what motivates you and makes you happy then perhaps we'd have better
weather predictions and early warning systems for tropical storms or better
tools that allow us to write safer, faster, bug-free code. The icing on the
cake is that you'd be happy to do it.

If you're just getting out of school though, then I'd follow the advice in
this article for a while first. You don't know where to go without getting a
lay of the land first. And a good salary will help you build up a "screw-up"
fund for when you're ready to take the dive and follow your calling.

------
SatvikBeri
I find it's really helpful to be flexible with your terminology. The power of
different phrases is enormous-it can make a difference between taking 5+
minutes to explain a concept to someone so that they superficially understand
it, vs. having them instantly get it at a deep level.

For example-I work on Machine Learning, and that's the phrase I'll use with
the HN crowd. With the general public, I'll use "Big Data". With
Statisticians, I'll use "Predictive Analytics".

One problem with the phrase "programmer" is that it's just too general. It is
impossible to get a sense of what value you create when you tell someone
you're a "programmer", because the term is so broad. "Web Developer",
"Statistics Automation Guru", "Ruby on Rails Consultant", "Data Scientist",
"SEO", "Marketing Automation Expert"...all these are really useful terms
simply because people instantly grok them. And when people have a clear sense
of what you do, it opens up a world of career opportunities.

------
weinzierl
"In the real world, picking up a new language takes a few weeks of effort and
after 6 to 12 months nobody will ever notice you haven’t been doing that one
for your entire career.".

Not exactly my experience. I agree that there are many programmers that
_think_ they are fluent in a new language after a few months.

Learning the syntax of a new language, like learning how chess pieces move,
takes a few hours. Mastering a programming language is like mastering chess, a
lifelong journey.

~~~
cynicalkane
I think patio's targeting the HN crowd, and not the mediocre-programmer-
with-30-resume-padding-languages crowd. Most very smart programmers know
enough about software engineering to do it in any language, and good
engineering is far more important than mastering language idioms.

~~~
CodeMage
It's not about idioms themselves. It's about the thought processes behind
those idioms. The difference between learning language idioms and learning the
thought processes behind them is like the difference between learning how to
solve math problems that appear frequently in exams and learning math.

I'm not arguing that you can't be a decent programmer without "mastering
language idioms", but there are good reasons why different languages exist. If
you just pick up a language without understanding the problem it solves,
you're just adding a tool to your toolbox without knowing how to use it
effectively, when to reach for it and how to accomplish what it does when you
don't have it.

~~~
cynicalkane
This is true for what pg calls Blub programmers who get stuck in idiomatic
ruts, but there's so much idea-sharing among the current popular high level
languages that I think once you master a certain number you can pick up new
ones fairly easily. The current ecosystem is one in which the really important
idioms--fundamentals of good software--translate well from language to
language.

Exceptions might exist for things like APL, and to a lesser extent "extremist"
languages like Haskell, Lisp, Forth, which require paradigm shifts to think
about effectively.

~~~
CodeMage
Almost everyone starts as a Blub programmer -- "Blub" was BASIC when I was a
kid and that's what I learned first -- but that's beside the point.

You're right in that the more languages you learn, the easier it gets to pick
up new ones, but that only happens if you make an effort to master them, so
you can learn the thought processes behind them.

Of course, after a while you'll hit the point of diminishing returns, where
most new languages you learn won't have a boatload of new, eye-opening,
paradigm-shifting concepts for you to discover and learn. However, there are
two things to keep in mind:

1) You never know when a new language will teach you something important
unless you try your best to learn it properly.

2) If you think you're going to spend a lot of time working with the language
X or if you're going to dive into a huge codebase written in that language,
then by all means try to master it. The better you are in that language, the
less code you'll write in it and the less code there is to maintain, the
better.

------
jt2190
Earlier discussion on HN: <http://news.ycombinator.com/item?id=3170766>

------
Zenst
Dependant upon who your dealing with you tailor the description. In general I
use the term `Binary BDSM` this means that I can avoid a lot of silly
conversations.

Programmers spend there time programming computers, debugging computers and in
effect deprogramming computers. They operate upon binary and in that there
will be those that appreciete a more encompasing term.

Now of all the work labels we encounter the one I find most off is `Human
Resources` when it is mostly paper programming that they do. So you could
equaly have the term Binary Business Muscian or many other permutations, its
fun.

Now if as a programmer you work to the letter of yoru contract and job
description then many of you would see that programmer do alot less work. That
is how you qualify your worth in part. Ironicly engaging with HR and all the
other overheads of working life also help. So by doing less work you can get
paid more money. That tells you more sadly.

But there are two types of programmer, those working in large business and
those who are not and with that the definition and the work involved vary
greatly. Also the opertunities too work bomb yourself with no return are also
varied.

No two programming jobs are the same, yet the job title stays the same. Maybe
we could learn something from other industries like the food industry and the
various types of Cheifs. Who wouldn't want to employ a mitchlen stared
programmer, sadly there is no standard that is respectfuly recognised. This is
why in many area's programmers are looked upon as the labourers in the digital
construction undustry and don't get the love they deserve or truely need.

Bottom line if your not happy then you are doing something wrong or letting
somebody else do something wrong too you. This is true of all jobs, nomatter
the title bestowed upon them and with that does a label effect your work or
the perception that work has is realy the question here.

------
drd
“90% of programming jobs are in creating Line of Business software”

That is awfully true. That is why I always teach my students at the very
beginning the simplified versions of software business life cycle for both
categories of consumer software and customized software.

<http://www.drdacademy.com/?id=12>

I am also planning a set of lessons-learned for new hires to avoid their
frustrations. Stay tuned.

------
dawidw
c) ”What is your previous salary?” is employer-speak for “Please give me
reasons to pay you less money.” Answer appropriately.

Could you elaborate on 'appropriately'?

~~~
factorialboy
"Why is my previous salary relevant to what I offer you today?" Or something
along those lines..

~~~
dawidw
"Because you haven't improved much since yesterday so your salary should stay
more or less the same" - they may answer :-)

~~~
nostrademons
"That salary was what I was worth when I started working for them. I've
learned things since then. If you don't believe I'll be more valuable to you
than to them, why are you hiring me?"

------
andrew_wc_brown
If a company is smaller than 10 people I can't be bothered with formal
processes and HR people. When I get people applying that call themselves
engineers I just think of comp-sci graduates who have no practical skill or
someone trying to play up their ego with a fancy title. When it comes down to
it, its the code you produce. I never give out résumés. At the end of the day
its what you can produce.

------
philhippus
I don't have a problem with calling myself a programmer because, when you take
away all the fluff, somebody has to tell the machine what to do. The only
people that can do that are programmers. An engineer can have the brightest
ideas,but still needs programming. The buck stops at the programmer, you'd
better respect us.

------
euroclydon
Lots of good advice, but don't get hung up on the title.

<http://www.linkedin.com/in/patrickmckenzie>

------
dualogy
Yeah, programmer, engineer, software developer, those names all don't cut it
for me these days. I call myself low-brow "caveman-coder".

------
pixie_
Have some pride in what you do for gods sake.

------
cfontes
Very good text, I liked it a lot thanks for sharing it.

------
rymith
I'm a programmer..

------
djbender
[2011]

------
dschiptsov
Yeah, I almost see it.)

You are not your stack.. Not an IDE you're using.. Your are not any particular
design pattern or an agile process.. You are not special. You are not a
beautiful or unique snowflake. You're the same decaying organic matter as
everything else.

But this was already taken and became a cliche years ago.)

