What would you define a programmer as?

Well, dictionary.com says a programmer is one who writes computer programs. Add the two definitions together and a programmer is:

One who writes sequences of instructions that a computer can interpret and execute.

Sounds like a good defintion to me :).

A person who can take a problem, design, implement and create a solution to it, while at the same time fully researching the problems many factors and tasks needed to solve the problem, and again, at the same time, breaking the problem down into a manageable number of sections in able to fully maximize his temporal effiency, while making sure he stays on schedule and possibly keeping many other people on schedule, as well as someone who will interface with whoever needed the problem solved, and interface with everyone else.

This devinition is far too broad. No one person can properly undertake all of these tasks in all but the most trivial of exercises. What this definition does is to take the process of developing a computer application, and personify it. Lets look at it step by step:

A person who can take a problem, design, . . . a solution to it

This is an analyst (or business analyst). An important first step. Often this involves developing a business case first (why should we do this?), then the requirements analysis (what should we do?), followed by the design (how shall we do it?).

implement and create a solution to it

Ahhh. . . here is the programmer.

while at the same time fully researching the problems many factors and tasks needed to solve the problem,

A combination of the analyst(s), architects, programmers, data modellers, and project manager. It is very helpful to have some business area experts involved as well.

at the same time, breaking the problem down into a manageable number of sections in able to fully maximize his temporal effiency, while making sure he stays on schedule and possibly keeping many other people on schedule, as well as someone who will interface with whoever needed the problem solved, and interface with everyone else

This is the project manager.

As you can see, there are quite a few different skill sets involved in the process of developing systems. That is not to say someone who is a programmer cannot be an analyst or a project manager. It is just very difficult (some would say impossible) to fill all roles properly on all but a trivial project.

The succinctness of the answer to your question can vary as much as you like, because programming is something hard to really nail down. To most quasi-IT-literate people, HTML is something you can 'program' in, but I wouldn't call someone who exclusively wrote HTML a programmer; not even if I were in a pink fit and tripping on LSD. So, it depends on who you ask. TMTOWTDI - there's more than one way to define it :)

If, however, I were to have a stab at defining "the programmer", I would say he or she is someone who "solves problems using algorithms". Sound good?

Just my 2 Australian Pesos.

--
Ash OS durbatulk, ash OS gimbatul,
Ash OS thrakatulk, agh burzum-ishi krimpatul!
Uzg-Microsoft-ishi amal fauthut burguuli.

Most companies do assign other people to gather requirements, perform testing, manage projects, troubleshoot problems, etc. In a few cases, I have met people in those roles who were smart and capable and made my life much easier. The vast majority do not. Most of them don't really understand the work being done and this leaves the programmer to fill in the gaps for them.

It's typical to be handed a vague spec, which needs to be turned into a set of understandable requirements through discussion with the spec's author and sometimes the business owners of the project. Then the project manager asks for a list of tasks, which requires the programmer to do some basic analysis, choose an approach, describe the tasks involved, and estimate how long they'll take. During development, the programmer has to keep an eye on the schedule, and bear that in mind while choosing the details of implementation. During the QA process, the testing team will need help from the programmer in understanding the details of the system and often in how to test functionality. Some of this might be unnecessary if perfect detailed specs were written, handed over to the programmer, and then handed to QA, but outside of the space shuttle that doesn't happen.

Am I being arrogant? Maybe. But if all I did at my job was write code, my projects would fail, and my manager understands this.

There are people who do less of some of these things. Some programmers are lacking in communication skills and thus don't do as much requirements work. Some have less experience and thus do less of the analysis and design. They damn well test their code and watch their schedules though.

I've always felt that writing code was easy, and I still do. It's the other stuff -- figuring out what code to write -- that's hard.

Perrin,

I would say that you might well have crossed the line from a "Programmer" to something more complex. Some people use the term "Software Engineer", however others feel there should be a lot more stringency on the use of that term.

Much of the existing writing on managing software development argues against having the Developer themselves responsible for all the aspects you list; This is for both focus and issues regarding organizing a team.

Exactly how would it work if each programmer in a 20 person team was responsible for defining their own time tables and deliverables? Some sort of consensus would have to be achieved, correct? There is usually an individual assigned this role in a team, often the team lead or the project manager. While a developer can handle this task, it is often a better use of resources if the developer is allowed to develop rather than worry about organizing time schedules. There are people much better suited to this role, who can focus on it. While I do empathize with the situation that often the people who are given this role, often are not well suited; But this is a problem with the Co. assigning the wrong people.

It is well documented that a developer is often the worst tester of their own product. Unconcious bias relating to certain sections of the code which are unstable can creep in, personal opinions regarding ease of use and desired functionality can arise from a misunderstanding of specs, as well as the time required for testing is often business-wise much better done by someone the company doesn't have to pay as much. A QA dept can build a standard procedure and reporting chain, which when done right will result in a better testing of the product -- assume the QA group and programmer have the same testing skill, the difference would be the benefit of having an unbiased set of eyes to examine the product, and if the skills are not equal then the QA group needs to be better trained.

During the QA process, the testing team will need help from the programmer in understanding the details of the system and often in how to test functionality
This injects the programmers personal bias, and restricts the QA teams efforts. A QA team should proceed as a user, not as a knowledgeable developer. A QA teams job is to be the best BDU you can find, if you educate them too much about the system then you eliminate much of their value.

Spec gathering, this is part of a system designer's job. However, how time consuming and redundant would it be for each programmer in a 20 person team to do their own spec gathering? Quite. Even if they only gathered specs for their own particular section, there is always going to be overlap and it is quite possible that transition issues within the system would be overlooked. So, again the management of this process should be given to a single individual ( often the project manager, but sometimes an analyst ), which can bring in team members as required but in general leave the developers to develop.

From reading your view it seems that you either work in an extremely small development shop where you are the only one, or maybe one of two, on a project. Having the individual developer responsible for all of these tasks simply does not work for larger development teams and is often a collosal waste of resources.

I have experience developing in Co's with both large and small development teams. The Co is much better off in software development when they can afford to staff a team with developers, a project manager, a relationship manager, an analyst, a documenter, and a QA team ( yes multiple, not just one ).

I think the issue here is that you're interpreting what I said as "everyone does everything", which is not the case. Some programmers do a lot more of one thing than another. I don't usually bother with terms like analyst, architect, etc. They're all part of the team that creates the programs, and there's a ton of overlap in responsibilities. These days I spend more time on analysis and design than on actual coding, but I still think of myself as a programmer because the end result of what my team does is still a program. You can make distinctions if you want to, but I prefer to let the process be a little more organic than that and let people contribute where they feel able to.

Much of the existing writing on managing software development argues against having the Developer themselves responsible for all the aspects you list

That's true, but there's also a counter movement in Extreme Programming and similar methods to remove some of the bulk that is caused by trying to separate these things so much. Even when these tasks are officially separated, there is a lot of collaboration required.

Exactly how would it work if each programmer in a 20 person team was responsible for defining their own time tables and deliverables?

The programming team should reach this conclusion together, with input on priorities and schedules from the business. Usually the more experienced people contribute more to this part. It requires an ability to break features up into logical chunks and a basic understanding of the system design in order to know what can be separated. I don't know any project managers who can do this without extensive hand-holding from the programming team.

A QA team should proceed as a user, not as a knowledgeable developer.

Of course, we all know this. However, there is a lot of interaction between the QA team and the programmers because not everything QA needs to know is written down. They often need to create certain conditions in order to run their tests, like artifically making a product in a store application out of stock. Doing this requires some knowledge of the data model, the interaction between the application and the database, and some basic SQL. Most business projects don't have tech specs that go into the necessary detail on this sort of thing, so help from a programmer is needed.

The bottom line is that I'm not opposed to separating these tasks, or giving out fancy titles, but the best programmers I've met knew enough about each of these things to help make them happen if the person with the official title couldn't do it for themselves.

Using the terminology of Pete McBreen's wonderful Software Craftsmanship, Perrin is a master programmer. Generally you only want one master programmer working on a project, a bunch of journeymen and a few apprentices. The master makes the big decisions, but delegates many decisions to his journeymen who may in turn delegate to apprentices.

Note too that just because one knows how to do something doesn't mean one has to do it. Given good people filling the various other roles one can delegate upwards too. But when the buck stops with you (and if you think it doesn't then you're fooling yourself) then you must be aware of the issues and be prepared to nip problems in the bud.

I've always felt that writing code was easy, and I still do. It's the other stuff -- figuring out what code to write -- that's hard.

Amen brother!

This hits the nail squarely on the head and drives it a good way into the wood.

In a perfect world I'd be able to spend my time designing and coding based on a perfect understanding of a perfectly defined, immutable, project spec. But if the world were perfect it would be no fun.

Maybe you will get lucky and have reasonable requirements and a spec. But they won't be complete. You're still going to have to gather/clarify requirements with the person who produced the docs.

Maybe the big, `strategic' design has been taken out of your hands; you're still going to have to deal with the tactical design issues of functional composition, naming of parts, algorithm choice and all the other details that help you build a good program instead of a ball of mud.

Of course, you may want to be micro managed, but if that's happening wouldn't it be much quicker for your puppetmaster to just fire you and do the job himself?

You don't have to excel at all these things. You don't have to do them all all the time. But if you intend to get better at your craft you're going to end up either knowing how to do them, or you'll have some pretty strong ideas on the subject that you could put into practice if you had to. It's all part of the process of active learning that (I claim) is one of the fundamental skills/goals of any half way decent programmer.

You are using an unpretentious title which is part of the misunderstanding here. I wouldn't say you're being arrogant about what a programmer should do. I think you're being humble by calling yourself only a programmer.

Gathering user requirements is often the job of a dedicated analyst, or at least a lead programmer. Translating these into a development project is the job of some sort of visionary or logistical person (like an analyst or programming lead). This is similar to a land developer or a really good general contractor in building construction. You might call this position a 'Applications Analyst', or possibly a 'Requirements Specialist' or 'Customer Needs Analyst'.

Deciding what parts need to be made and how they fit together is the job of a software designer or software engineer. This is sort of like an architect, and sometimes the job title is reminiscent of such -- 'Software Architect'.

A linguist, psychologist, or artist (or preferably all three) is best suited to UI concerns. Which is best depends upon how much the interface differs from what the users have already seen, the major goals of the interface design (being more attractive than normal, just being familiar, or actually being easier to use). In any case, some projects which a user sees have a dedicated interface designer. Programs that only talk to other programs are generally okay to have an interface done by a programmer or software designer. Ideally, this person is equivalent to part interior designer, part landscaper, and part Feng Shui master.

A programmer often is someone who simply writes programs. This is especially true of people employed specifically to maintain an already operational project with no budget for redesign or major refactoring. This might include some unit-level design decisions, but often just consists of translating the requirements of a single component at a time into code. These are the carpenters, bricklayers, plumbers, and electricians. The construction jobs of panellers, painters, plasterers, carpeters, etc. fit into this category or the one above, inclusively.

Keeping everyone working together and keeping them on schedule is the job of a project manager, kind of a general contractor of sorts. They make sure the requirements analyst's (land developer) vision reflects the user's needs and is in turn reflected in the software designer's (architect) more detailed design. They make sure the programmers (trades workers) implement what the software designer's design mandates. They make sure the interface makes sense to the user, that the main program and the interface work well together, and that everyone has everything they need in order to make all of this come together. The quality assurance is ultimately the project manager's responsiblity, as is setting reasonable timetables and providing for the needs of the people working on the project. Additional people are often used to help the project manager do all of this, abive and beyond what I've already mentioned. This can include unit testers, system testers, staff assistants, dedicated customer liasons, documentation writers and for extended maintenance programming departments (which any successful project turns out to need, of course) this can include technical support, customer complaints and suggestions staff, etc.

Under certain methodologies, many of these tasks are shared among a group, with each person filling part of every role. Extreme Programming seems to promote this to an extent, for example.

In small IT shops, in constulancy businesses which aren't dedicated to programming, in an IS department at a non IS company, or in some other cases people have to take on more than one job role. simply by neccessity. In fact, in very small businesses, such as a self-employed consutlant or a partnership with two or three people, it's common that every role in a company is upon the shoudlders of one person. Not only does this include requirements, design, initial programming, testing, debugging, maintenance programming, and documentation, but also the mundane business matters of sales, marketing, accounting, facilities management, reception, and public relations.

Just because one person fills more than one role doesn't mean there's not more than one role to be filled. A person employed as a 'Programmer' in title might be expected to do more than write code. There's really more to the job in that case than the title implies. That's where a resume comes into play, showing what a particular title really means at a particular company.

Christopher E. Stith
use coffee;

Either way, it is a really fun read.

This cant be right. While this is a slight exageration, it does prove my point.

Please clarify. What is your point?

Matt

My point was that a programmer is not, and should not be expected to be, a manager, QA, tech support, customer support, etc etc etc. He is a programmer. While he might be expected to utilize some of the skills of the above people, there is no way he could get his job and everyone elses done at the same time.

I'd argue the opposite. A programmer that only writes code is a waste of a paycheck, oxygen, and air conditioning.

Manager

Manage his own time and resources against the things which need to be done. Given a list of tasks and priorities he needs to complete those tasks in the given order. If there are resources he needs, he needs to make those needs known to his management and those peers who can fufill those needs in a timely and effective manner so they can be met.

Appropriate meetings will be attended (in the hallways, conference rooms, on the phone), issues raised, and isses resolved.

QA

Devise tests that cover the portions of code he's reponsible for and execute those tests. Catalog problems found at the edges of his code, report them to others responsible for them. Find and fix problems in his own code and improve the tests appropriately.

tech support/customer support

Provide assistance to others on the project that need to access the API for the programs he's written. This takes the form of API documentation, error message divination, and possibly demonstrations. If the customer is the actual end-user for the code, when the phone rings and the customer rep wants to know why the particular module that the programmer wrote doesn't work, the programmer should be prepared to give a customer-friendly explanation of why it's not working, work-arounds, and possibly a preliminary estimate of when it will be researched and/or fixed.

Very little useful software is written in a vacuum.

For once I agree with this change in that I believe that programmers should be able to take a problem and deploy his "swiss army knife" of techniques to solve the problem: