Note: This file has moved to notablog.
Map of the Career Field
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:
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 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 at 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 like this, 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 handle
most of the dirty work for you.
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 develops software to provide a service
to end users, either other companies or the public.
6) working for a company that develops shrink-wrapped off-the-shelf
applications for sale to the public.
7) working for a company that developes 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 wtih fundamentally different
stuff.
12) 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, narrowly-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.
----------