I'm Justa Programmer. All I want to do in life is code, eat, have relations, and sleep. --Phl Ip
If you're Justa Programmer, you have the relations ==, != etc. Thanks for asking.
I hear you on the fear of being called 'just' a programmer. The late Dijkstra (Ew Dijkstra) fought it all his life and never made much headway. It is easier for me than you, since I am a card-carrying methodologist (purveyor of poisons) and occasional project manager (dispenser of poisons) and rarely any more a card-carrying programmer. (I suppose I should blanch at admitting in public that I am a methodologist, too.) If another name is better, then it should not be Extreme anything, because that sounds unnatural. It should sound natural, as natural as you and Ron claim it to be. See Minimal Methodologies.
While all JPs could wish their bosses followed the more obvious industry Best Practices (like, maybe, Unit Test Christopher Alexander s), JPs should follow a list of their own...
I am a programmer with management tendencies (and ambitions), and I must confess to labelling people as "just a programmer". Some people will not, for reasons of inherent ability or simple choice, be managers, VPs, or CEOs. And yes, a good programmer is less valuable (in dollar terms) than a good CEO. But this shouldn't be taken as a statement of moral worth...
Your bias is showing a bit ;) I'll go along with the above with an addition -- insomuch as any worth can be found in this sort of generalization. A good programmer is worth less (in above sense) than a good CEO, but a good programmer is worth more than a good manager (not exec), on avg., and a great programmer (i.e., there are few of these) is worth more than most CEO's. Many middle management people in software fail to realise this, and thus fail to realise their own potential as managers. This is, again, not a statement of moral worth, just a (hard-won) observation.
On the 'market value' of any given type of employee - that is determined to a very small extent by intrinsic characteristics of the person, or of the position; I see it as essentially a function of offer and demand. If you are one of few people with skills that are in great demand, your value goes up. If you are one of a large number of people with skills not in demand, your value goes down. I posit that your 'value' has nothing whatsoever to do with what those skills actually are. Thus, programmers are currently cheaper than CEOs, because CEOs are rarer. CEOs are rarer because of contingent reasons - to sell yourself as a CEO, you must claim relevant experience, and starting a business is something fewer people have the occasion to do than learning to program. If you want to be a highly paid programmer, acquire rare skills that are or will be in high demand. -- Laurent Bossavit
And yes, a good programmer is less valuable (in dollar terms) than a good CEO.
Three programmers without a CEO can create a video game that generates millions of dollars of income. What can three CEOs create without a programmer?
Suspense for a punchline?
::what is less clear to me is which is more expensive, a bad programmer or a bad CEO? Andrew Cates
Yes a bad CEO is the greater of two evils. A CEO 'thinks' he/she is more important than a good programmer, but a CEO is generally nothing but a good-ole-boy which gets you into the money club (i.e. venture capital). I also have to agree with a statement you will find below. What is really needed is good software engineers not programers.
Here's the joke: Q) What do you get when you have more upper level management than programmers in a software company? A) Hype and delays. There are too many CEOs that think they can create technology with funding, superior managment and hand waving. Technology companies need to concentrate on technology. Managment, marketing and legal are only necessary after you have a real product. If you can elimitate these factors early and concentrate only on technology the start up of costs of a software business are relatively small. -- Anonymous Donor
Not true at all.
There are two elements to getting a successful product to market: building the right product, and building the product right. Marketing is responsible for building the right product, tech is responsible for building the product right, legal is responsible for making sure somebody doesn't rip off this product once you've gotten it right, and management is responsible for making sure everybody can talk to everybody else.
You need all of them, and unless you're fantastically lucky, marketing should come first.
There're plenty of computer programmers who think that having superior technology on the market first will make them a million bucks. History's littered with dozens of examples where they were wrong. Take a look at all the dead projects on Source Forge. Or the Dot Com bust. Or Symbolics and the AI winter.
In this part, you can't be more wrong. Dot Com was investment fuckup which had nothing to do with technology. Technology goes at its own pace and cannot be speeded up by money too much. If you want to succeed with excellent management and marketing, than go sell something, don't develop. Anonymous Donor is plainly right. -- Dramenbejs.
My goal in life is to found a successful startup and grow it into a stable company (or sell it to a stable company ;-). The technology part doesn't faze me at all - I've got about 30 languages I could choose from, I can pick up most libraries through a reference manual or example program, and I know how to structure programs so they don't collapse under their own mass of code. The marketing part, however, scares me. Because people don't behave predictably. They may say they desperately want a product, but then close their wallets as soon as it goes on the market. -- Jonathan Tang
The problem is (IMHO) more that management tends to start believing Marketing when they say that all you need is Marketing, and Engineering is devalued. Nobody gets fired when the makret projections change, but Engineering gets the heat when requirements change and the development schedule needs to be lengthened --Pete Hardie
Quite possibly this is because most management tends to come from the marketing side of the business. This is a good argument for why techies need to learn management skills - otherwise, you get management who doesn't have the slightest clue about what it takes to get the product right. Unfortunately, most techies don't have the slightest interest in management. Hence the title of this page. -- Jonathan Tang
100% true sir!
Re: Fear of being labelled "just a programmer"
While discussing my future career, a potential employer asked me something like, "do you want to be just a programmer..." Is this view widespread? If there is no career path for "just" a programmer, where does a young programmer person go, career-wise?
I consider myself to be Justa Programmer. I am certainly very conversant and even somewhat capable in methodology, management, administration and so on. I've done it all, and could do it again, could do it again. But what I like to do, and therefore do best, is hang with small groups of bright people and help them develop software. Coach, mentor, manager, leader ... yeah, sure. I just help people get software out. Right now it says "Computer Scientist" on my card. I think I'll change it to Justa Programmer. Come to my talk at Smalltalk Solutions and ask to see one. -- Ron Jeffries
I like Miss Manners' riposte of "Oh, no, I used to be just-a-secretary, but I was promoted."
Some companies do think of non-management-track developers as "just-a-programmer". In my experience, these are companies to avoid. Somebody with 15 years of programming experience (assuming it isn't the same year repeated 15 times) is an invaluable resource, and should be compensated accordingly. Many software companies now offer dual career tracks, with one track leading to management and the other leading to "senior programmer" or "lead programmer" status, in which the most respected developers serve as in-house consultants, responsible for architecture and mentoring, and as project leads (as opposed to project managers).
How about Core Developer? Ours do Extreme Programming (and more) and were never considered Justa Programmer although none of them would mind being called a programmer -- you should see what they produce!
Around 1989 a manager took me aside and showed me this wonderful CASE tool that he was going to purchase (it cost several tens-of-thousands of dollars so it must have been wonderful). This tool, he explained, would reduce the need for staffing in-house programmers. The tool could generate the application with just a few instructions here and there. For a moment I felt like John Henry. Then I realized that the CASE tool generated Ada so I wasn't in any immediate trouble...
Seriously, the industry keeps trying to abstract away the act of programming until programmers are no longer needed.
Programmers aren't needed. Software engineers are. I'd be happy to be Justa Software Engineer
(I'd be happier to be Justa Software Craftsman)
For example, look at all the Java tools that automatically write java programs for you. Hey, they are even preaching that Java Beans will get rid of the need for those pesky programmers. (And Beans grow on trees, I guess -- Daniel Earwicker)
In order for software development to be a whole craft, it must consist of analysis, design and implementation. Each is difficult in its own right.
-- Todd Coram (a steel drivin' man)
No Way! :) Justa Programmer is the guy who does the implementation. The rest is undefined yet. :) I guess it's Justa Software Engineer. Software development IS a craft, and a nice and interesting one...automatic code generation is cool -- but we have to wait for processors with the DoWhatIMean instruction incorporated. :) -- Patric Ionescu
In my mind a coder is the guy who does just the implementation, while a programmer takes on the whole job. -- David Thomas
There are folks to whom management comes because the folks have solved problems in a way that made management happy. It doesn't matter what those folks' titles are. There are folks who may or may not have solved problems, but in any case didn't make management happy. These folks are not come to to solve more problems. Again, it doesn't matter what their titles are. -- Ron Jeffries
Of course, the interesting question is : Are the go-to people the ones that caused the problem in the first place? Consider a code hero that can fix any problem in hours, and gets the opportunity to do so often, on his own code. Management love him: all those swift emergency bugfixes!
I have this misfortune to be currently contracted to a project in a software house where the business of actually designing and writing code is considered almost distasteful.
The project chiefs are very keen on generating as much code as possible, having a couple of trusted sidekicks writing huge, all-encompasing libraries, and so on. Basically I believe it comes down to not trusting their programmers because they are, after all, just programmers. Hey, what do they know about the business of running a multimillion DM project? They just write code, and any fool can do that.
This puts them in a bit of a Catch22, because in spite of it all, they need programmers. No one wants to stay as a programmer, because they don't feel valued, so they recruit more people, send them on a month-long training course and then throw them into the trenches -- where they flounder. The upshot of all this is, of course, that things take longer, the quality is low, it costs a fortune and so on and so on.
I am Justa Programmer - but being a programmer is much, much more than being able to type a line of syntactically correct code.
-- Jez Higgins
If Justa Programmer is what you want to be, and you're looking for a new job, you might want to look for Qualifying Employers. -- Andreas Krueger
On which page AK wrought thus:
"Do they value you if Justa Programmer is all you want to be? I left my last place of work because they wanted to promote me away from software development, which I like and know how to do, to management duties." -- Andreas Krueger
Remark to the statement above:
Andreas cleverly avoided to fall into the traps of the Peter Principle
I thought enlightened companies offered multiple advancement paths; one to research, another towards management. This might help to weed the People Persons out of research. Prob'ly just a rumor. -- Phl Ip
Making a virtue of a necessity, we may soon be forced into being Justa Programmer.
"Engineer" is still up for grabs ;-)
No it isn't. In my previous job (in a tiny corner of IBM) we had to change job title because of complaints from chartered Engineers in the US.
A fact of interest only to US residents, surely? In the UK, IT professionals may obtain the title "Chartered Engineer", after jumping through suitable hoops.
BTW, a new book has been written by Jan Bosch based on both his academic and industrial work with RISE (Research In Software Engineering) called Design & Use of Software Architectures: Adopting and evolving a product-line approach. I'd recommend it to anyone interested in either of these issues -- you need not be an enthusiast in the Product Line Approach. The first part goes into Software Architecture, and Architectural Description Languages in general while the second part concentrates on Product Line Architecture and an Architectural Process for Software Product Lines. Most of the work is supported by actual case studies and where ever possible, Bosch attempts to show both the academic and industrial approaches to Software Architecture.
Another drawback to "Engineer" is that (due to Job Title Inflation) in the UK the term seems to be overloaded with "technician" -- hence the guy who comes around to fix your heating would call himself a heating engineer. No offence to technicians, but that is not a job title I'd aspire to.
All coders spend time operating as technicians. This is necessitated by the crude tools we use to communicate our instructions to machines. When today's development practices and toolsets are carefully inventoried, it represents the lion's share.
My mentor began programming in 1958 and claims he still wonders when the world will realize we're overpayed technicians -- just like the folks who come to fix the furnace or install a new phone line.
-- Luke Samaha
I don't know how bad that is, really. Plumbers or similar tradespeople in the US make pretty good money per hour. On little fix-it projects, certainly with admin or virus cleanup or other non-programming tasks, I justify my rate by that sort of comparison: "Sure it cost $200 to deal with upgrading Sendmail, updating your firewall software, and rebooting your server. What's your HVAC contractor charge for annual boiler maintenance?" Maybe that doesn't apply so well to system design and programming. Maybe it does.
I think the distinction that they were trying to get across is that while we programmers also do technician-type work, that's not all we do. We not only repair, we also create.
How's about Justa Bodger. Some days, I feel I'm doing a lot more bodging that engineering. --rad
By the way, bodge means "botch."
In the spirit of restructuring our speaking about what we do away from Software Engineering to "Sw Devt is a cooperative game of invention and communication", I'd like to propose the alternative title (to Software Architect or Software Engineer) called Cooperative Gamesman/Software. Maybe I'll put that on my next business card. -- Alistair Cockburn
(You have business cards? You ain't a programmer! -- Daniel Earwicker)
Job-title inflation has a lot to do with why some people don't like being labelled a "Programmer" -- and certainly "Just a Programmer" has clearly disparaging connotations, unless you reverse those with standard-issue hacker irony.
But "programming" (in the sense of writing code) has been treated as a mechanizable (or at least routinizable) activity by managements that see Fredrick Winslow Taylor's time-and-motion approach as the obvious way to improve productivity. (It's neither, of course, for the simple reason that, if the code you're writing today is very similar to the code you wrote yesterday, you're obviously doing something horribly wrong. Contrast with ditch-digging.)
Andersen Consulting, for instance, hires humanities majors and call them "programmers". What do they do? Translate pseudo-code written by computer-science graduates into code in an actual programming language. So the title "programmer" has been debased in a serious way, and on a large scale.
Ten or more years ago, people fled the "programmer" title for the euphemism of "programmer/analyst", then simply "systems analyst" and related, p-word-eschewing titles. Partly, this was to seem more important, and partly, it reflected a realization of how little programming (in the strict sense of coding) most people do.
While I'm on the subject of misconceptions about programming, and how it's affected the "programmer" title: why, after two decades, are software companies still promising end-user programming (or, equivalently, the ability to customize "without having to program")? Producing working code is hard, and takes certain skills and non-trivial effort.
The only way around this is to restrict the power of the language: HTML (which is far from Turing-complete) can be successfully written by non-programmers; by the same token, it's also easy to write editor apps which will let the users describe what they want more naturally, and generate (pretty good) HTML for them. [The preceding two paragraphs should probably be refactored to somewhere else; feel free to do so.] -- George Paci
HTML is not merely far from begin Turing-complete, it is not even remotely a programming language in any sense of the word. -- David Conrad
Job titles are abstractions of the contents of your job (or your identity!) and All Abstractions Lie. Use an abstraction when it helps you, otherwise not (see also Little Wittgenstein Quote). -- Lars Aronsson (19 May 2001)
Is there a category for Justa Programmer, Code Monkey, Grunt Programmer, Cowboy Coder, etc? Where's the taxonomy?
Code Slinger (along the lines of "hash slinger"?, then again Hash Slinger might be appropriate for a perl programmer.
My title is Senior Systems Developer. I was a Systems Integrator for awhile, but then my company had a reorganization during a merger, and realized they would need to bump my salary almost double if I kept the title - so they downgraded me. I do R&D (limited), architecture, design, implementation, testing, deployment, maintenance, and limited project management (vendors - gotta love 'em). About 90% of what I do is programming - and I do it mostly in Python Language. The other 10% is spent herding cats. Am I Justa Programmer? I've been doing this for so long, this is my assumption of what a programmer should be. Needless to say, I don't have much patience for more specialized programmers. The worse part for me is playing phone tag and organizing meetings of a plethora of individuals, none of which are talking to each other about my system - slug slow progress - 'nuff said. - Malcolm Campbell
Just an update to the above with a decade of hindsight - today I'm a technical architect - and the programming to other things ratio has flipped as 10% of my time is spent writing code (most of which is for my own use - such are collecting data from systems for research, experimenting with new tools (part of my job being the selection of tools and standards), and so on), and 90% is spent herding cats. A key part of my job is working through other programmers to get complex projects done - and I've taken it upon myself to mentor programmers on my teams in not only good design, but also how not to become an outsource statistic. It goes back to a key quote above by Lars Aronsson - "Use an abstraction when it helps you, otherwise not." I believe the application of that in a situation where HR makes the rules about your job title and responsibilities would be: don't let your job description get in the way of you defining your engagement and value - and most importantly - making sure your management sees that value in every project you participate! This attitude has helped me succeed and grow in my job - while the IT job market itself has declined.
In response to the negative or positive connotations of Justa Programmer - I think the right way to look at this is where your career is concerned, never let yourself be pigeon-holed as one. On the other hand, there are moments when you are in the 'flow' as going through cycles of code/test/modify in interactive/investigative programming on systems that you may not know well, or where deep magic is involved, or conversely when you are quickly coding up something that is a clear pattern that you've done a million times before - where you are Justa Programmer at that moment in time (irrespective of how you manage your career). From that perspective - there isn't a clear category or taxonomy for this without understanding the context in which it is being used.
--Malcolm Campbell (2012)
Programmer, software engineer, developer -- these are overused labels that obscure the line between architect and carpenter. Both are worthy pursuits, but the former requires a more refined skill set. As it is with a software development. Programming is a skilled occupation, just as carpentry is. But I've met few programmers that were skilled architects of software. Great problem solvers yes, but most fall short when it comes to creating the vision of a large project. That requires a different skillset, a different title -- Software Architect -- and a different salary:) Senior Software Engineer just sounds like you've been there longer then the SE III. In my opinion, Software Architect demands more respect. -- Jeff Franks
In principle, I agree with you, Jeff. Unfortunately, I don't believe there is such a thing as a Software Architect. Let me re-state: There is nobody (yet) with the training to do the equivalent job in software that an Architect does in constructions. This isn't for lack of trying, it is just that some of the basic knowledge doesn't exist yet. When it does, then we will be getting somewhere. But because of this lack, things get messy -- and people who think they can work at the same remove as Architects do tend to have lousy designs once they are off paper. The best we can do now is a sort of 'visionary carpenter'. Even then, it is hit and miss. Most of the people I have met who had the title "Software Architect" (or equivalent) were an order of magnitude less competent than they thought they were. Several were noticeably less competent at overall design than one or two people working "under" them, people they wouldn't listen too.
The analogy may not be perfect, but I think it is acceptable and is certainly more suitable - when the applicable skillset is present - than whitewashing our profession with the title of programmer or Software Engineer. And though you have yet to meet a competent Software Architect, that does not preclude their existence. The ones you've encountered are just poor architects, much like there are poor 'construction' architects, city planners, etc.... Software architects do exist - they are the folks on your team making design decisions. There is a clear, measurable difference between the folks that can program and the folks that can program AND design, and that demands the respect of a title superior to Senior Software Engineer. The skillsets are not exclusive. Some JustAProgrammers have some Software Architect in them and a good Software Architect relies on their input. But without the leadership of a Software Architect, a team of Justa Programmers will produce inferior applications - that is indisputable.
I have to disagree 180 degrees on the assertation that we have no such thing as an architect position in software development. I have had the pleasure of knowing a number of journeymen carpenters over the years (of extensive home remodeling). I have often heard them bemoan the fact that most architects know little about construction. Heck, look at the hallowed Frank Lloyd Wright. Most of his designs took considerable engineering revisions to make them work, let alone last. It's one thing to whack out a beautiful GUI, it's entirely another to make the underlying code work well. Software architects must have a deep understanding of the underlying implementation to do their jobs. I have known few competent software architects who could not also write solid code.
From my own experience as both a programmer and now a technical architect - I would add a twist, most of the architects I deal with come from the network or hardware side of things. In these projects I am involved in, software is merely one factor in the overall project. You are absolutely right that architects should have a deep understanding of the underlying implementation to do their jobs well (and where we are talking about layering on additional functionality to existing systems the term 'systems integration' is probably appropriate). Unfortunately - at least in my industry - they by and large do not have that understanding, of no fault of their own given their EE backgrounds. Of course, this provides me with an opportunity... -- Malcolm Campbell
I'm a 'practitioner of software', and I must also confess to using the term Justa Programmer, and (to some extent) the mindset that goes with it. When we start in our chosen profession, coding and testing is filled with learning experiences, and it's not yet time for more. Later, our skills usually broaden to include more than 'just programming'. For me, Justa Programmer means an apprentice, not an experienced practitioner, and it's a useful term.
All these alternatives, Engineer, Architect, Developer, borrow and analogize from other disciplines and suffer from All Abstractions Lie. The only word we have so far that has any uniqueness to it is Programmer, and that's losing its potency. Perhaps the only way to come up with an accurate label for what we do is to invent a new word. Engineer comes from engine, Architect comes the Greek root for building, etc. Our word should have a root that more or less symbolizes what we really do. That might not be as hard as it seems, and I think there are a lot of potential candidate words. My vote goes to Logoneer, from the root logos, or 'reason'.
maybe even 'logician'? Yeah, that would've been better, but it's already taken.
When I was young, I felt in love with computers and Computer Programs. My father, who actually introduced me to then, more specifically giving me a programmable calculator and a Sinclair ZX-80 clone (full 16K of memory, K7 secondary storage) and a book about LISP had serious concerns that I would become Justa Programmer. I should be a Full Fledged Engineer.
I now hold a Electronic Engineering B.Sc., a Systems Engineering and Computing Ph.D, a professorial position at University, and own a small software company. I am a Holder Of Cards. However, I fell happy when I had to sit down in front of my terminal and act Justa Programmer.
While thinking about refactoring this page, I've found these connotations for the phrase "Just a Programmer":
Negative
Implication of lack of experience/seniority/skills
No ambition for higher levels of responsibility
Lack of regard for design issues
Less income than people with other positions
Positive
Rejection of pretentious or inappropriate titles
Rejection of unwanted non-programming roles
Focus on writing code as the primary activity of software development
Understatement/irony
Did I miss any? --Kris Johnson
Focus on writing code as the primary activity of software development I think this rules me out of being Justa Programmer. I don't even see it as a positive for such people. The primary activity of software development is the creation of software. Coding can (and sometimes should) often be a minimal part of that. Then again, coding is the bit that I truly love. --Stuart Scott
Perhaps a better answer for describing the many facets of most computer jobs would be to phrase your responsibilities in the form of a haiku. This would give you more lines and syllables to work with, rather than forcing you to choose only 1 to 3 words to describe everything you do, and it also allow you to shade your statements with deeper meaning. For example my official title is 'analyst', which doesn't mean particularly much, but in haiku form my job might be listed as:
I transform data web design and programming are held in reserve
Herd the daily build scripts lovingly track my code this haiku is crap
Get requirements spewed forth from the waterfall design, build, and test
viewing the above agile men scream and impel, "Mind the waterfall"
i ask the questions and write ugly documents that coders all hate
What about What Is Software Design? "Coding is a design-time activity, and that we need to re-examine both the analogies we use to describe our field, and the attitudes we have towards its different roles." So, a programmer who focusses primarily on coding is a low-level designer. I think Jack Reeves is trying to raise the low-end of who we consider programmers. That must have some impact on this discussion...
On another note, maybe we're happy when we're programming because we're putting those ideas down in a more concrete form, moving from the imaginary to the actual -- like an author who's moving from idea-phase to rough-draft-phase. Programmer As Author, anyone? I've used this analogy quite a few times in my Corporate employement...
Perhaps Software Development As Journalism?
cool page
There's another one that've understood everything: programming-motherfucker.com 
See original on c2.com