I am a programmer

The problem I have with Patrick's essay ("you are not a programmer") is that it addresses a situation that hardly any developer ever finds himself in. If I go to interview for an engineer position, it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth. All they want to know is how long I've been coding Blub, which frameworks I use and why did I quit my last job? If all is well I will start on Monday with checking out the SVN repo and start getting to know the code. Should I start trying to analyze the company's business processes that would be an awkward conversation indeed with the department manager.<p>I think that is the reality most developers find themselves in. I doubt it's been any different for Patrick until the consultancy spinoffs he can now pull on account of his personal brand.<p>So I kind of agree with Jacques here, with the exception that I don't call myself a programmer in conversation with people outside the field, since it sounds a bit like "punch card operator". That doesn't change the fact that I really am a programmer first and foremost.

"We're middle-men (and women), glorified translators"<p>By that rationale, teachers are glorified dictionaries, accountants are glorified calculators, and lawyers are glorified secretaries.<p>"Programmers don't 'unemploy' people"<p>Bullshit. If I build an automated fraud detection system for a bank and they lay off 50 people in charge of fraud detection after it goes live, I most certainly made their jobs redundant. If I build a more efficient control system for an automobile plant, and they lay off operators as soon as it goes live, I've certainly made their jobs redundant. Efficiency kills jobs by definition. You only create more jobs when you start in a new area, or as a competitor. And even then it's only temporary until efficiencies kill those jobs as well.<p>"As a ground rule, as long as you are calling other peoples modules you're not yet programming"<p>Then, as a ground rule, as long as you're drawing triangles, arches, and straight lines, or using a CAD program, you're not yet architecting. As long as you're using 2x4s or windows made of glass you didn't blow yourself to build a house, you're not yet building.<p>Why does everything have to be built fron scratch in an intellectual vacuum in order to be "real"? Isn't the whole point to stand on the shoulders of the giants who came before?<p>"Whether you use the word programmer to describe yourself or not has very little to do with what your bank statement tells you at the end of every month."<p>Actually, it has a LOT to do with what your bank statement tells you at the end of the month. The world runs on respect. And respect comes from other people. Give yourself a title that engenders respect and you'll find yourself able to negotiate FAR better deals for yourself than you would with a less respectable "I'm-just-a-replaceable-cog" title.<p>"And in such places (and unfortunately also in quite a few smaller ones) the market value of what a person doing your work is charging is what will determine your pay"<p>No, the market value of a person with your TITLE is what will determine your pay, unless you're known to be a pushover who accepts promotions without pay increases. And if such a 'promotion' happens, you gladly accept it anyway, and then leave 6 months later with your new title to leverage a better salary.

The problem I had with Patrick's essay is how derogatory it is to what we do.<p>I am a programmer because it's what I like to do. People pay me money to do it. And when I go home I read about it, talk to others about it, and I practice, practice, practice. I think about how I can write better software, reduce the amount of bugs, test better designs, and improve my productivity. I think about programming all of the time.<p>And like Jacques, I'm not afraid to tell others that I'm a programmer. I think most people understand what that is by now. I write programs for computers. If I say "Systems Analyst," or "Solution Architect," they will probably look at me funny and ask what that means. In an interview... it will probably be passed over without a second thought. So I call myself a programmer.<p>And I call myself a programmer with a bit of pride. It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff. Experienced employers will have realized this before sitting some one such as myself down in an interview. They want someone with enthusiasm for the craft, the experience building many different systems, and the ability to learn. There was a time when I would have accepted any programming job. However there comes a point where talking to yet another company who just wants to replace a cog in their machine becomes a waste of your time. It is hard to be good at this job and experience and ability has a cost associated with them.<p>So yes, I am a programmer. Thanks Jacques for writing this.

Patrick's essay had nothing to do with titles. It was about describing what you do in terms of the benefit you provide to your customers/employers rather than in terms of the skills or tools you use to provide that benefit.<p>I could tell people I can program Excel interop in .NET, or I could tell them I saved my company dozens of hours a week by automating an administrative process. To non-programmers, only one of these descriptions sounds interesting. A programmer can hear "Excel interop in .NET" and infer automating administrative tasks. A business person, generally, cannot.<p>Patrick's essay was about being explicit about the value you provide, not about picking a fancier name for yourself.

Yes, me too, I'm a programmer. That's how I think of myself, regardless of what infinitely varied tasks I may do. And me too, that's what I blurt out when people ask me what I do.<p>In more formal contexts, like resumes and job apps, I call myself a software developer, because that's a more encompassing description of what I do. Software development is not just programming, even if that's the most obvious and the most fun part.<p>My employers call me whatever they want to call me. That's been technical staff member, programmer, software engineer, etc.<p>I never voluntarily call myself a software engineer. I've never worked under the supervision of a PE who was legally responsible for my work, and I've never been on a track working toward my PE. Very few software developers work in that environment.<p>I don't mind the informalization of the term software engineer, but I don't use it because I've never, ever worked in an environment where programming or software development was practiced as an engineering discipline using national or international standards of practice or product. Software development where I've been, and where most people are, is much more an individual art than a community science. So I don't want to give the impression that what I'm doing is in any way a legal, formal engineering practice.

I am a programmer, but I am not a programmer.<p>The problem is, 'programming' as such is the end of a process. That process begins with talking to a customer about his or her idea/business problem, and asking questions and (basically) doing consulting to help the customer understand what his or her problem really is. Once that's clear, I write a proposal that outlines how I would address that problem, all in strictly high-level layman-understandable language - no mockups, no screenshots, no technical language, nothing. Then, once we agree on that, I contact a designer to help out with the design of the app, and to think about new and novels ways to make the interface as simple as possible. We show it to the customer, refine it, and get an agreement on all that stuff. And then, finally, three months since that first meeting, I can start with the programming.<p>So yes, I'm a programmer - but only if an academic is a writer, if an architect is someone who draws, and if a manager is someone who talks to people.

<i>Job security, job satisfaction, good pay. Pick any two.</i><p>This statement doesn't make much sense when you think about it. It seems to be a lazy riff off of:<p><i>"Fast, cheap, quality: Pick any two"</i><p>Each of those characteristics are in competition with each other. Doing something fast often hurts quality and/or cheapness. Doing something cheaply may take longer and may harm quality.<p>Job security vs. job satisfaction don't really compete with each other. In fact, being more satisfied (i.e. happy) at your job may lead to better security indirectly, as a happy worker is a more productive, engaged, and charismatic worker.<p>Perhaps JMJ is trying to appeal to the commonly-held notion that fulfilling, satisfying jobs are ones that don't pay well - teaching, research, social work, etc. OK, it applies to certain sectors. But not across all sectors. A failure to recognize the inherent structural differences and opportunities between job fields (and public vs. private) hurts whatever rhetorical argument he's trying to make here.

The biggest quarrel I have with this whole debacle is how it all started out. A group of wise asses decided they should fancy their title up and now everyone has to "to stay relevant".<p>The fact is I <i>AM</i> a Software Engineer. I have a degree in Applied Science and I have my Iron Ring. I am registered with my provincial Professional Body. Saying that, I am not just a "Programmer" (I do not mean to sound derogatory) but there is a difference in the fields that I think is getting blurred.<p>I turned down many jobs that wanted "programmers" because I am an "engineer" and don't want to fall behind in my primary field to take a job that is loosely related. I code at home in my own time releasing small projects only recently digging into bigger ventures that are potentially able to turn profit but that's beside the point. Where I am now is an engineer's job. I do programming yes, but my job requires more than an understanding of computer architecture and design pattern competency to succeed.<p>I feel like I'm sounding like an ass. I am much more humble I swear! The point is that Software Engg != Programmer we need to stop fooling ourselves and allow the segregation to occur so that programmers are properly recognized and respected for their work!

Although there is no mentioning of any references, I have a clue that it is a response to "Don't call yourself a programmer" (<a href="http://news.ycombinator.com/item?id=3170766" rel="nofollow">http://news.ycombinator.com/item?id=3170766</a>)

I would argue that this semantic debate over the meaning of "programmer" is getting a tad tired. The author description would be more aptly described, in my opinion, as an entrepreneur.<p>Conflict management, and the other business-focused tasks he mention are completely separate from the programming side in the corporate world. I worked at a company where the software developers spent 90% of their time writing code based on tasks, and nearly no time on these other facets described in the article.<p>Suffice to say, I think that more focus should be spent on what people are doing, and not what they're calling it. Which is sort of what the author was saying, in the end.

Patrick's essay covered a lot of ground. It expanded on its title by explaining what companies value. The essay as a whole did not seem focused on job titles. The essay title did focus on job titles.<p>I see a wonderfully self-referential thing happening when people focus on the title of the essay. Maybe people do focus more on titles than they should -- both essay titles and job titles. Maybe job titles are as important as essay titles and email subject lines.<p>Patrick's essay was adaptibly engineered. If titles are what get through to people, the essay title will convey what's imprtant. Otherwise, the essay body will convey what's important.

What this particular farcical drama boils down to is the tension between the creative and the business. It is identical in spirit to the musician's dilemma.<p>Usually it comes out to something like this, "Do we take pleasure in our art and pursue the art, or do we take pleasure in selling our art in pursuing that?"<p>It's painfully obvious that good businesses pay people to create a positive value proposition for them. Therefore, if you are running your career like a business, you need to be seeking to maximize your value proposition. Part of that is passing yourself off as a maximal value creator. That is one half of the essence of patio11's point.<p>A lot of the artists I've dealt with are content to seek their art and to work in badly paid jobs to maximize their pursuit of their art. As someone who can program computers, we can draw value from our art. We do not <i>need</i> to hack at night and work as a barista during the day. That is the other half of the essence of patio11's point.<p>No one has to take patio11's advice, and their priorities may not align with his priorities.<p>But if you're maximizing wealth creation through being a programmer, you need to stop 'being a programmer/hacker/ninja/rock star/operator' and start 'being a person who creates wealth for other people via technology'.

I've been re-reading the Gervais Principle series[0] recently, so I can't help but to construe both the original essay[1] and this response in terms of Sociopath, Clueless and Loser dynamics.<p>The original essay could also be called "A Loser's Guide To Careers" -- it's a realistic assessment of the options and opportunities offered to most engineers. It recognizes that most readers will be, in the grand scheme of things, on the short end of the stick and will have relatively little to bargain with. Accordingly, it dispenses cold, rational advice for how to best bargain with that limited leverage.<p>Both the Sociopath and the Loser are realists, it's only that the Loser has little meaningful leverage; he accepts this and so makes the best time-money bargain he can negotiate.<p>The Clueless, however, is clueless -- he would like to believe he is making a difference by keeping his head down, working hard and following the rules; instead, he is setup to be a mediocre middle manager at best, and a scapegoat at worst. And this essay could best be called "A Clueless Defense." That is not meant to slight any of Jacques technical achievements or prowess. Instead, I apply the term "clueless" here to mean that Jacques is being hopelessly naive. This essay is essentially a celebration of Jacques refusal to accept the situation in which he and other engineers find themselves: a world where those who hold the largest stakes (in any venture we choose to participate in) generally have no clue what value we provide and are incented to reduce our stakes.<p>(Yes, there are exceptions, even successful ones, and I think I work at one of those. But I don't blindly believe it, and I wouldn't bet my life or my family's future on it.)<p>I could write a lot more about my feelings on "I am a programmer,": I don't like it. I've already said that I find it naive and I don't want to cause unnecessary offense. Still, I commend Jacques for writing it at all and there's no reason to alienate him in disagreement, because it's an honest expression of his feelings. But I do want to say that, as a worldview, the idea of it being useful for understanding the trajectory of your career... well, I'm reminded of a line from the Futurama episode "Love and Rocket":<p>"Oh I would dearly love to believe that were true. So I do."<p>(And also -- the original essay has nothing to do with job titles.)<p>[0] <a href="http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/" rel="nofollow">http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...</a> [1] <a href="http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/" rel="nofollow">http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...</a>

Excellent post all in all, but the part I consider the most important is:<p><i>Job security, job satisfaction, good pay. Pick any two.</i><p>I've been keenly aware of that for a while now. For someone like me, someone who chooses the first two, it stings a lot until you come to terms with it and make it your conscious choice. It all has to do with one's priorities and no combination is bad in itself. You just need to be aware of these things or it might be a source of unhappiness for you.

Jacques mentioned in the article that someone doing COBOL gets paid megabucks, i did a very quick search on UK job sites for <i>contractors</i> and they seem to make the same day rate as PHP developers. Is it different elsewhere? Is it just in permanent jobs that it commands more money? Anyone know where and why COBOL gets the big bucks?

I am a experienced programmer, too. No "software architect" or another label can convert the stupid into brilliant. In most cases is related to recognition, power, and pay, so may be that's the reason of accepting such labels as "normal" (I have no problem with others telling me X, Y or Z, although I find it non-sense as well).

I don't think you are (a programmer).<p>From the article:<p><i>"Programmers are guys and girls that can take real-world problems, that can analyze those problems and that use that analysis to come up with a way to improve the world, usually in an incremental but sometimes in a revolutionary manner by solving those problems (hopefully) once and for all."</i><p>You are a systems analyst. The difference (to me at least) is that a programmer solves the presented problem by writing a program, a systems analyst solves the problem by tuning or refactoring the system. Sometimes all that takes is programming, but sometimes it takes more than that, a new data base schema, a different partitioning of roles of machines participating in the solution, user education, or even getting the rules of the game changed.

I just think the debate about identifying oneself "as", like pointed by other comments, is specific to a cultural context. In India specifically "programming" is as much about sector of work like "Information Technology" as it would be individuals profession. So most of the time "programmer" or "software engineer" inter-changeably explains the where one works for someone outside the profession. In case the person shows further interest, one could go further into what exactly is the span of work. So unlike Patrick's essay tries to convey, "programmer" per se is not a restrictive definition.

The title makes it sound as if the author is in complete disagreement with Patrick's essay (and perhaps he feels that he is) but it's not how I see it.<p>Both articles are about the way you present yourself, not really about the "programmer" label. Sure, your label is part of what do for a living, but the important point brought up by both articles is that you have to recognize what your value is in the workplace and use that as your selling point in order to achieve job satisfaction and/or recognition (that's the way I understood them anyway).

I am going to change my title to janitorial engineer.

I'm a software developer... who cares, really... to outsiders we are weird kind of folks no matter what

I agree "Programmer" is a sufficient job title, but my favourite "alternate" title I've seen anyone use is "Technical Enabler". It says "I use technology to solve problems and create value", which I think is very apt most of the time. You might be programming or you might simply be sharing/applying knowledge about computers, software, the web etc. that most people don't have. At least that's what I feel it's like most days.

Honestly, who besides programmers even know the difference between software engineers and programmers?<p>I personally don't really think there is a difference. They are essentially the same thing. I'm both and I don't really see a case where I'd call myself one and not the other.<p>So who is making the distinction? Us (engineers) or other people?<p>If you really want to make the assertion that non-engineers are making the distinction between programmers and software engineers, who do you think told them what the difference was?

The problem I have with "software engineering" is that it's not real engineering. Sure you might do thinking to create proper requirements, design, build a prototype, build the real thing and iterate, use agile or whatever.<p>But comparing programming to actual, real-world engineering is a different kettle of fish. Engineers make things with actual physical requirements - if they're not met, people will die. You're not going to be doing proper engineering unless you can sue the engineers for the wholes in their software that caused people to lose money from their bank. Sure it works and may well solve a problem, but it's not engineered.<p>Real software engineering is using formal methods to do your utmost to prove that your stuff actually will work (Intel does that for some of their chip development) or make 5 different control systems for your rocket and have them vote on the correct course to add extra backup to prevent fuckups (NASA did this for the Apollo iirc - the EU Ariane didn't, so they had a rocket crash at one point).<p>Until that happens, you're just going to be developing sandcastles - you're going to have buggy software that will break at some point - because software development is so fast that it's not worth the effort to engineer from the get-go.<p>In other words, coding is coding - you can have good coding that uses best practices - but if you call it engineering you're deluding yourself in most cases.

It agrees with my view that programming and mathematics are no different. I build models with my toolkit. End of story.

There's an inverse snobbery in effect here to an extent. If you've made it / made a name for yourself you can call yourself a programmer.<p>I don't know know whether it was the recently departed dmr or ken, but one of them answered 'programmer' when asked what he put as a profession on his landing/visa/immigration card.

<i>as long as you are calling other peoples modules you're not yet programming</i><p>How about while you're <i>not</i> calling other peoples' modules, you're not programming <i>effectively</i>?<p>Why am I supposed to waste my time rewriting code available in the STL, or better, why is it held against me that I don't waste my time on such?

<i>As a ground rule, as long as you are calling other peoples modules you're not yet programming, but that doesn't mean that what you do can't be meaningful or useful.</i><p>Oh, I see. Do I also have to code my own compiler before I start rewriting glibc?

-- <i>...but the fact of the matter is that I'm a programmer. It's what I do best and it is the job title that I associate with most</i><p>and then<p>-- <i>What you call yourself or what other people call you is utterly irrelevant.</i><p>I am utterly confused and no better at my job.

I don't know about this one. I have a degree in comp sci and a master in software Eng. I've worked too hard in my life to be treated as a janitor. Why shoudnt we get the respect other engineers get?

"<i>Glorified translator</i>?"<p>Now I feel like a Geico caveman.

"My main occupations are being owner/operator of ww.com"<p>This guy is not a programmer. He is a business owner that can program. He can call himself a trashman and not loose a dime.

I am an information Manipulator.

Here is something constructive to take away from Patrick's essay.<p>If you work in a bureaucracy dont whine about code quality ,better testing etc coz guess what ...No one really gives a shit!<p>If you really want to do good work do where its actually going to matter.WORK ON OPEN SOURCE PROJECTS.<p>When you are at work.Keep in mind that the only thing the management cares about is increasing profits and cutting costs.So go ahead and make them the ugly PHP5 form that they want.It will take you very less time anyways.Spend the rest of the time working on open source projects.This is a complete win-win strategy.<p>Yes years later when your companies stock value is in single digits ,some people in upper management will maybe understand the value of good source control,good testing procedures etc.But guess what they are not going to give much of a shit even then.All they will care about even then is (Repeat After Me)"Increasing profit and reducing costs".