Justa Programmer
Justa ProgrammerI'm JustaProgrammer. All I want to do in life is code, eat, have relations, and sleep. --PhlIp
If you're JustaProgrammer, you have the relations ==, != etc. Thanks for asking.
I hear you on the fear of being called 'just' a programmer. The late Dijkstra (EwDijkstra) 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 MinimalMethodologies.
While all JPs could wish their bosses followed the more obvious industry BestPractices (like, maybe, UnitTestChristopherAlexander? 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. -- LaurentBossavit
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? AndrewCates
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. -- AnonymousDonor
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 SourceForge. Or the DotCom bust. Or Symbolics and the AI winter.
In this part, you can't be more wrong. DotCom 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. AnonymousDonor 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. -- JonathanTang
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 --PeteHardie
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. -- JonathanTang
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?
-- DavidMcNicol
I consider myself to be JustaProgrammer. 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 JustaProgrammer. Come to my talk at SmalltalkSolutions and ask to see one. -- RonJeffries
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 CoreDeveloper?? Ours do ExtremeProgramming (and more) and were never considered JustaProgrammer although none of them would mind being called a programmer -- you should see what they produce!
-- MartineDevos
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 JustaSoftwareEngineer
(I'd be happier to be JustaSoftwareCraftsman?)
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 -- DanielEarwicker)
Yeah, CodeGenerationIsaDesignSmell.
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.
-- ToddCoram (a steel drivin' man)
No Way! :) JustaProgrammer is the guy who does the implementation. The rest is undefined yet. :) I guess it's JustaSoftwareEngineer. 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. :) -- PatricIonescu
In my mind a coder is the guy who does just the implementation, while a programmer takes on the whole job. -- DavidThomas
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. -- RonJeffries
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 JustaProgrammer - but being a programmer is much, much more than being able to type a line of syntactically correct code.
-- JezHiggins
If JustaProgrammer is what you want to be, and you're looking for a new job, you might want to look for QualifyingEmployers. -- AndreasKrueger
On which page AK wrought thus:
Making a virtue of a necessity, we may soon be forced into being JustaProgrammer.
"Engineer" is still up for grabs ;-)
Another drawback to "Engineer" is that (due to JobTitleInflation?) 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.
-- LukeSamaha
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.
-- MarkSchumann
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 JustaBodger. 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 CooperativeGamesman/Software. Maybe I'll put that on my next business card. -- AlistairCockburn
(You have business cards? You ain't a programmer! -- DanielEarwicker)
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 FredrickWinslowTaylor'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.)
AndersenConsulting, 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.] -- GeorgePaci
HTML is not merely far from begin Turing-complete, it is not even remotely a programming language in any sense of the word. -- DavidConrad
Job titles are abstractions of the contents of your job (or your identity!) and AllAbstractionsLie. Use an abstraction when it helps you, otherwise not (see also LittleWittgensteinQuote). -- LarsAronsson (19 May 2001)
Is there a category for JustaProgrammer, CodeMonkey, GruntProgrammer, CowboyCoder, etc? Where's the taxonomy?
CodeSlinger? (along the lines of "hash slinger"?, then again HashSlinger? 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 PythonLanguage. The other 10% is spent herding cats. Am I JustaProgrammer? 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. - MalcolmCampbell
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 LarsAronsson - "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 JustaProgrammer - 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 JustaProgrammer 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. -- JeffFranks
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 SoftwareEngineer. And though you have yet to meet a competent SoftwareArchitect, 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 SeniorSoftwareEngineer. The skillsets are not exclusive. Some JustAProgrammers have some SoftwareArchitect in them and a good SoftwareArchitect relies on their input. But without the leadership of a SoftwareArchitect, a team of JustaProgrammers 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... -- MalcolmCampbell
I'm a 'practitioner of software', and I must also confess to using the term JustaProgrammer, 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, JustaProgrammer 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 AllAbstractionsLie. 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'. <applause>
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 ComputerPrograms?. 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 JustaProgrammer. I should be a FullFledgedEngineer.
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 HolderOfCards. However, I fell happy when I had to sit down in front of my terminal and act JustaProgrammer.
While thinking about refactoring this page, I've found these connotations for the phrase "Just a Programmer":
Negative
Focus on writing code as the primary activity of software development I think this rules me out of being JustaProgrammer. 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. --StuartScott
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 WhatIsSoftwareDesign? "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 JackReeves 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. ProgrammerAsAuthor?, anyone? I've used this analogy quite a few times in my Corporate employement... --DanielBernier
Perhaps SoftwareDevelopmentAsJournalism?
cool page
There's another one that've understood everything: http://programming-motherfucker.com/
EditText of this page
(last edited October 7, 2012)
or FindPage with title or text search