Map of the Career Field

by Steven J. Owens (unless otherwise attributed)

Someday I want to make a poster, a sort of topological map of all of the different kinds of jobs you can get as a programmer. Except that not all of them are really programmer jobs. Maybe a more accurate term would be "technologist", though that that's a bit too general, since it includes a lotta hardware too.

The terrain splits up along two dimensions; the kind of work you do day to day, and the context in which you do it. The context is simpler, I guess, since most technologists tend to do more than one kind of work at once, or to drift around.

This is, of course, a generalization, and not necessarily in any order. I do a lot of rambling as I try to explore the topic. I don't intend for the order used below to have any "better or worse" implications, though on some reflection a major factor seems to be how much emphasis a given situation puts on the programming itself, as opposed to on the problem the programmer is trying to solve.

Typically the job situation you could end up in will be in:

0) working for the IT department of a company where IT is just part of the background. Almost all companies these days have some degree of IT needs. If this is where you are, get out. This is the precisely the sort of job that will go away as soon as there's enough economic incentive to improve the design of the software and hardware involved. Redesigns that remove the makework imposed by poor software design, or the introduction of information appliances in the market will either vaporize your job or transform the way your industry does business -- and such transformations will usually upset the apple cart and vaporize a big chunk of your industry, not to mention obsoleting enough jobs to make your job obsolete too.

1) working for the IT department of a company that does something else, where IT is a necessary part of what the company does but is not the central focus of the company. You spend your time maintaining systems and supporting business user needs, very little time developing new software. The most traditional example of this would be a fairly narrow company that mostly uses IT for order processing, inventory control, accounting, payroll, etc.

2) working for the IT department of a company that deals a lot in information and hence needs a lot of IT support (e.g. a bank, or a very large corporation with diverse needs). You spend more time extending existing systems and do some application development. But most of the application development is required to interoperate with existing systems, or to be developed using the same technologies as existing systems. Most often, those technologies are "4GL" environments, e.g. databases, spreadsheets, or specialized application languages.

3) working for a company that develops vertical applications for deployment at companies like 1) and 2). Sometimes working on more general application kits that will be further customized by people at 1) and 2), but most of the time the customization will be done by consultants from your company (or in the case of sufficiently large companies of this nature, the work will be done by remora-like consulting companies that exist to fill this niche). Most of the time you'll still be working with specialized application environments that insulate you from the underlying technology.

4) working for consulting companies and contracting companies that hire you out to 1), 2) and 3). These vary widely and wildly in quality of life, and the amount of good they'll do your career. Overall I must strongly encourage anybody going into this area to be very proactive in managing both your career and your relationship with companies you deal with. See my other comments on Job Shop Life.

From here on, much of the time this is where the programming changes over from using specialized application languages to using what I'll call here "system programming languages", like C, C++, Java, etc. This is not at all to say that these languages and others aren't used all over the place, nor that the people in all of the situations described aren't serious programmers. However, I think you'll find more use of these languages and more of the serious programmers at the following. Also, note that all of these categories are quite ambiguous and you may find some of many at the same company.

5) working for a company that sells a software-based service to the public. Most of the time this sort of software is developed in-house.

6) working for a company that develops shrink-wrapped off-the-shelf applications for sale to the public.

7) working for a company that develops the application environments for companies like 3), 2) and 1). Much of the time, the people doing the actual development know little to nothing about the end users, or more importantly, the developers and administrators serving the end users.

8) working for a company that develops tools for the application programmers, either specialized applications for the programming disciplines or sometimes components, libraries, or specialized environments.

9) working for a company that develops the fabric of the the technology itself, operating systems, device drivers, etc.

10) working for an organization that develops fundamental tools or environments, for example at Sun developing Java, or at Lucid developing their flavor of Lisp. I'm not sure where to put a company like Microsoft, since they make several very important development environments (much like Borland did, when it was still around) but are not necessarily breaking new ground with fundamentally different stuff.

11) working for/at an organization doing completely "out there" work on new concepts, but usually with an end goal of implementation in mind. This is often either a research organization like Bell Labs (now Lucent), or an educational institute.

12) for completeness' sake, working in the upper stratosphere of the "science" part of computer science, which is often more math or seemingly metaphysics than programming. I guess we could also include people doing educational and research work into topics like software engineering and softer topics like cognitive design, here.

Now we come (briefly, maybe I'll be able to flesh this out later) to the second dimension, the kind of work you do. I'll keep it simple for now, in saying that typically you're either a programmer or a system administrator (I would just say administrator, but that sounds too managerial).

Administrators come in several flavors - pure system administrators (maybe you could call them operating system administrators, though most also deal with applications a lot, at least in so far as the application has to be installed on and configured for a given system), network administrators, database administrators. Many if not most administrators have a fair amount of down-and-dirty-with-the-hardware experience as well. Most administrators have to know at least a little programming, to automate administration tasks and sometimes programming-like skills, for example composing firewall rules (systematic rules that define what kinds of traffic is allowed through to where).

I wouldn't at all be surprised to find an adminstrator who used to be a full-time programmer, or vice versa. The topics and domains are much the same. The key difference seems to be an emphasis on certain kinds of activity and knowledge. System adminstrators like to get into the intricacies of a system and solve problems, tweaking it until they get it running right. They also like designing system and network architectures, figuring out how the pieces need to go together.

Programmers certainly come in as much variety. I started to write here that they come in more variety, but I realized that's just my own skewed perspective. There's certainly as much variety in hardware/operating systems as there is in programming languages. So for now let's stick to the more fundamental differences.

Some of these are covered above - the programmers who work in 4GLs as opposed to programmers who work in system programming languages.

Also there's a distinction between software engineers and the more traditional craftsmen programmers who take a less structured approach (I'll avoid the debate over which is better - certainly both have advantages approaching different problems), not to mention actual computer scientists (there's a difference between a scientist and an engineer).

There's also a difference in the level of coding, between people who take a vague situation and develop first a clear definition of the problem and then a solution, on the one hand, and on the other hand people who tackle more surgical, precisely-defined problems. A distinction between people whose knowledge is broad and shallow and those whose knowledge is narrow and deep. And then again there are often quite sharp individuals whose knowledge is both broad and deep, but there just aren't enough hours in the day or days in the year for them to apply that knowledge everywhere. They usually have to stake out a territory and develop it.

I don't have any inspiring conclusions to put here yet.


See original (unformatted) article

Feedback

Verification Image:
Subject:
Your Email Address:
Confirm Address:
Please Post:
Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator.
Message Content: