From System Administrator to Developer?

ma11achy asks: "Recently, I have been looking at making a career change from Unix Systems Administrator to programming/software development. I have a CS degree recently obtained through distance education and have been working in the field of Unix Systems Admin for roughly seven years now (in my early thirties). I have reasonable knowledge of C, good knowledge of Perl and excellent knowledge of shell scripting. Is, is there anyone out there that has made the change and could they provide any insights into what it was like for them? Am I just barking up the wrong source tree?"

Comments

It's no big deal

[puckhead]

I went from programming to system administration and back again several times. If you know how computers work, it's not much of a leap to programming them.

Prove Yourself

[Markus Registrada]

Join a Free Software project. Participate in bug fixing, at first, and then cleanup, and then implementing new features. After you develop some confidence and design judgment, implement something substantial by yourself. Then, do whatever it takes (meaning, really listen to more experienced people) to get it accepted, and maintain it and refine it according to qualified criticism and user whims.

(Don't go start a new project. That's the last thing the world needs, another abortive project run by a newbie.)

If programming turns out to be not your thing, you'll find out soon enough, and before you've got yourself mired in. One thing: as a Perl expert, you've most likely picked up habits that would make you an awful programmer. You will have to work hard to unlearn those.

When you go looking for professional programming work, you can point to your substantial contributions, and they will speak for you. Choose your project wisely.

Re:Prove Yourself

[jmt9581]

One thing: as a Perl expert, you've most likely picked up habits that would make you an awful programmer. You will have to work hard to unlearn those.

Since when did being an expert at Perl make someone an awful programmer? Isn't Perl a programming language? It's possible to write terrible programs in Java and it's also possible to write beautiful programs in Perl. Who is more likely to write a beautiful program in Perl, the expert C++ programmer who is just learning Perl, or a Perl expert?

I may be a little over the top, but I take offense to the idea that being an expert in a programming language makes you likely to pick up bad programming habits.

Why bother?

[Anonymous Coward]

Either way, your job is going to get shipped off to India.

Entirely possible

[msuzio]

I think making the move is entirely possible for you; you know computers fairly well, have a unique perspective on things that many programmers lack, and are used to being 'in the field'.

Pish-posh to the idiots who say being a Perl programmer somehow taints you. Please. Bad programming habits can occur in any language... the mere fact that you actually *want* to be a developer probably means you would be willing to listen to constructive criticism on how to improve your code. So, regardless of background, you probably could *become* a great programmer if you have any aptitude whatsoever. Enthusiasm is the core attribute most shitty programmers lack, they do it just for the paycheck. Good programmers do it because they dig solving problems :-).

Here are the key things you'll need:

1) Code examples. You need a couple really good examples of problem solving and at least *decent* code. If Perl is your best language syntax-wise, then pick up "Programming Perl", read it over a weekend, observe the good programming habits in the code examples. Download a couple of Perl modules and read those too... that should show you how to write a Perl program while avoiding really nasty habits. Then write a program in that style to solve a personal itch. Get a couple of those that you can show some enthusiasm for, and you will do well in an interview where you get to talk to actual programmers :-) (it would impress me!)

2) Look for a job where you can join a small-to-medium size team. Ideally, one organized into senior/junior developers. See, you want to learn from senior guys who are actively mentoring juniors. I know I do that, because the more I teach my team members how to most effectively program, the more I can delegate coding efforts to them and know they will do it mostly the way I would do it if I had time :-). So mentoring is a good deal for both parties. Hopefully, you can find a chance like that.

3) If you get a job in a larger group, don't be discouraged. You might be shitty tasks parsed out to you, or you might get overwhelmed with tougher things you don't feel ready to tackle. Either way, forge onwards -- you're a programmer now! Read more good texts on programming (on company time) if you're under-utilized -- I'd hardly fauly anyone on my team who did that! If you're swamped, admit it -- and try to draw others on the team into that mentoring/sharing experience you want. Who knows, you might encourage better teamwork overall... some of the shittiest programming jobs got that way just because the team as a whole lost spirit -- as the new guy, you're the best equipped to cut through that crap (before you get sucked into it too ).

I'd say give it a shot. You'll certainly learn something. In a pinch, you've got a lot of skills to fall back on. I mean, if you were under-utilized as a programmer, maybe you can fill out your time by offering sysadmin advice or picking up all those loose 'admin' tasks the IT department isn't handling :-).

Re:Programming.... bleh!

[hawkstone]

Scary. Not just your comment, but a bunch of responses to it. I feel the need to respond if only to give a differing opinion.

I started programming when I was 7 years old. Atari 1200XL. Moved onto a Commodore 64. Then an Amiga. Then an IBM PC (8086/8088). Then more modern 386/486. An itty bitty bit of Macs. Went to college (BSCS), did the whole Sun/IRIX/HPUX thing for four years. Got a job at a National Laboratory programming. Did that for a couple years. Now back in grad school in CS (MS) while working. I've done BASIC, C, C++, Java, Python, Perl, and several others I'm embarrased to mention (though they end in -TRAN and -BOL). Programming in school and programming at work. When I have free time, I often write programs for fun or for utility. It's been twenty years. I will never get burnt out on it. Many of the people in CS in grad school I know are the same way.

I hate to make the analogy because it sounds presumptuous, but for me it's fun and creative, kind of like art. I know there are many people out there who chose programming because it was a good living. But they couldn't have enjoyed it too much to begin with. If I hear someone say they're burnt out, I wonder if they fall into this category. Can you imagine an artist say "That's it. I'm burnt out. I've painted for three years professionally, and now I hate it."? If so, then maybe they never really were an artist.

Sure, there are some tedious parts like debugging, but even that can be rewarding. And certain projects can suck your brains out; imagine working on a huge mural with 10 other artists for several years. Certain projects can get old. But while you're doing that project, you aren't necessarily thinking that you hate art (programming), but maybe instead that you're still itching to paint (code) something you want to work on instead of the project you're sick of.

If you've programmed some, and said to yourself, "Hey, this is slick! Look at this code I brought to life!", you might have it in you. If you wrote something and said "Glad that's over, now gimme my paycheck/diploma", then you might want to reconsider.

Sysadmins and Software Engineers

[hbo]

I've been a sysadmin for 17 years. I do a lot of programming in my work, mainly in OO perl, so I have a perspective on the two disciplines that might be helpful. Warning: the following statements are generalizations. Not every sysadmin or software engineer will fit neatly into the boxes I describe here.

One of the things that attracts me about sysadmin is the variety of tasks required to do the job well. You have to be good with computer systems, of course. But your computer knowledge has to be broader than average, because solving systems problems frequently requires understanding the system at several different levels at once (Here I use "system" to include multiple computers connected with a network.) You also have to worry about hardware, and may find yourself elbow deep in a rack or under someone's desk. In addition to the technical aspects of the job, you also need to interact with people an awful lot, often under under difficult circumstances.

Computer programming requires a different skill set. Here, intense concentration on a single subject is a key skill. Your knowledge needs to be very deep in the particlar area you are working in. There's less of a premium on people skills. I don't have a college degree, and I've noticed that such degrees are less common among sysadmins than among software engineers. This could just reflect hiring bias, but I suspect it actually means something. Academic training in Computer Science, particularly in algorithms, is probably more useful for a software engineer than for a sysadmin.

For myself, the coding I do is another of the whole suite of tasks I am called upon to address as a sysadmin. I enjoy the intense concentration, but I'm glad I don't have to keep it up year after year. Instead I can jump from task to task, often having several going at once. Or I can learn some new technology that has popped up in the workplace. My jobs have been anything but boring, and boredom is my number one bummer thing.

Shameless plug: It's ironic that people who appear so similar on the surface can be so dissimilar at a deep level. (I've written a whole paper about it. The software it describes is at http://egbok.com/sudoscript

It's possible - but be aware of the differences

[phamlen]

(Just a note on my background: I've been a programmer for 10+ years and a sysadmin for 4+ years. I've also managed software development teams and Operations (sysadmin) groups.)

Tip #1: Be aware that system administration and programming are different things. Understand the differences - in some cases, your sysadmin background will be invaluable. In other cases, your background will be useless. The rest of this comment is a description of some of the differences.

Tip #2: Software development is largely about solving business problems.
While system administration is largely about keeping machines/networks/infrastructures running, programming is all about building a product for a customer (even if the "customer" is really an internal user and the "product" is just a program). Thus, when you switch over to programming, you focus on building what your [customers|users|product development team] wants. You need more people skils, more UI skills, more "analysis" skills.

Tip #3: Programming is different from "sysadmin scripting".
Other posters have definitely mentioned this, but understand that programming is very different from scripting. Admittedly, some system administration scripting is really programming but most of it isn't. Some of the key differences:

• Usually, you work on a component of a system. Thus, other people will use your work and may require a specific interface/design. You have to understand what the users of your program need it to do.
• Programming usually requires more discipline. Your code may be reused in other systems - thus, it has to be more strict about checking for errors, needs to be error-free even when used differently than you imagined, needs to have some level of documentation, etc.
• The design of the code matters - not just that it gets the right result.
• The "process" matters a lot. People care whether you are writing code that meets the right requirements, whether it's testable, whether you're sticking to the schedule, etc.
• There's a lot more - see some of the references below to read more on this subject.

Tip #4: Software development is a team-effort. You'll need to conform.
Software development (in all but the smallest efforts) involves a team. Thus, you'll find:

• Other people become dependent on what you write. If you're late or your code doesn't work (or there are bugs in it), it usually affects someone else - who usually gets upset.
• You have to get along with the rest of the team - including accepting their design instead of yours, picking up work that other people haven't gotten to, etc.
• You'll have deliver to a schedule, warn when you miss it, and sit in innumerable meetings to discuss whether everyone is going to make the schedule (hint: they aren't. :)
• You'll have to conform: you'll need to use the same editor/development environment as everyone else. You'll need to conform to coding standards, etc.

Tip #5: Good system design/architecture skills are very different from system administration skills.
System design/architecture is complicated - and involves a completely different set of skills than system administration. Don't assume you can build systems just because you can administer them. Luckily, you don't need these skills when you begin - just be aware that system design is very different than programming.

Tip #6: Most programmers haven't a clue about system administration - use this to your advantage!
I apologize to all the great programmers who I'm offending, but most programmers/architects tend to ignore the system administration issues surrounding a system. For example, do they have a rollout/rollback procedure for releasing components? Do they have an interface for stopping/restarting components - or do they just expect the sysadmins to 'know how to do it'? This is one area where