Slashdot Mirror
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?"
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.
Watching Cowboy Bebop in my jammies, eating a bowl of Shreddies.
I've done the sysadmin / programming thing... I hate programming although i'm good at it.. most programmers I know hate programming after about 3-4 years...
I honestly don't want to do this the rest of my life... although I have no idea what i want to do. Programming sucks your brains out...
ChiefArcher
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.
My blog
The original poster is correct. Perl teaches terrible programming habits. Have you ever tried code object oriented Perl? You have to struggle just to maintain consistent clean code.
I am more comfortable programming in perl than any other language.
Your statement about "writing a beautiful program" misses the point entirely. The point isn't to write a beautiful program. It's to write a consistent and maintainable program. Perl loses on the consistancy side. There's-more-than-one-way-to-do-it only makes sense when you want to write a one-shot script to accomplish a menial task. Not when other poeple may eventually look at your code.
Keeping
The thing is, you could say the same thing about BASIC programmers, or PHP programmers. And you might often be right, as well. It's a common generalization, a stereotype, if you will.
Perl--like BASIC--gives the programmer a lot of rope to hang himself with. It's quite possible that if that's all you know, you'll have a lot of trouble in a more structured environment. I know I had to learn a lot going from BASIC to Pascal, for example.
However, if you're an experienced programmer, if you learned good habits in the first place, or if you have some sort of bizarre knack for writing structured, well-maintained code in any language, maybe you won't have that many 'bad programming habits'. And after a certain point, a lot of this is subjective, anyhow. One person's bad habits can be another's coding guidelines.
pb Reply or e-mail; don't vaguely moderate.
I started as a sysadmin many years ago and was competent at it but my heart wasn't in it. It felt static to me. I suppose that's what maintenance is in the end, if you're good at it: routine.
I enjoy programming, which I've been doing for about four years, because I get a variety of gratification: short-term: every few days you implement something or fix something that was broken and; long-term: you finish a project or major piece and see a system working as a whole. Neither form of gratification can really replace the other and I found that I didn't get enough of either of these as a sysadmin.
Other than the ways in which the job is rewarding one thing I've really had to learn is to keep expanding my understanding of software and design. If you haven't already you should really look to learning what best practices exist and when/how to apply them; I'm thinking of things like design patterns, analysis patterns (bit dry but good), refactoring, etc.
Good luck!
It sounds like your skills and background are similar to mine. As long as you can show programming experience and skill, whether it is professionally or open software contributions, it is not too hard. However, some companies can be pretty limited in their mind set. A few years ago when I was moving from a sys-admin job to a development job NCAR in Boulder would not even interview me because they thought I had too much sys-admin experience to be a good programmer. they were apparently so limited in their thinking that they did not believe a person could know both fields.
One of my favorite kinds of jobs are the ones that are a cross between sys-admin and development. They require skill in all areas. Higher level sys-admin positions I have been in required a lot of perl, shell script, and even some C programming along with systems/network administration because they have involved developing disaster recovery systems, and writing lots of automation programs, to automate sys-admin, publishing of web pages, etc.
I have seen programmers so handicapped in their skills that they have to call the sys-admin for help just to set permissions on their files. Any company that is worth working for should consider sys-admin skill a plus. So keep looking and don't become discouraged if you encounter closed minded companies. You will be much happier in the long run being choosy about the type of job you accept.
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'.
:-).
:-) (it would impress me!)
:-). So mentoring is a good deal for both parties. Hopefully, you can find a chance like that.
:-).
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
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
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
It's a strange world -- let's keep it that way
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
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
But the department I was in had all kinds of programming needs that weren't being met by the programmers. There were a lot of admin. assistants doing tedious manual work when an Excel spreadsheet or Perl script could do it much faster. So I just started doing little apps for the people I knew and got a reputation as someone who could get stuff done.
Then I found another need -- there was a huge hole in our website (campus map for the university where I worked) that nobody had time to fix. So I made my own webapp for it and started talking to the people who ran the official site about using my version instead.
They hired me about six months later.
So my advice is: find an unmet need and meet it. Another post mentioned open source, which could be a good route. But if you fix something your boss needs, it's much more likely to result in a programming job.
-Esme
I know most people hate testing and see it has a dead end boring job, but if you take the right attitude it can be a good gateway to a future career in development (hey you might even find you like test).
With your skill list, in particular you use of scripting languages, I would say you are ideally placed to join a company as a software tester. While you have no experience as a tester machine maintenance and scripting is always needed, there is usually the opertunity to produce software testing frameworks and "real" code to test your product with.
Do this job for a couple of years, but make sure you build a really good relationship with development during that time, and whenever possible do as much product diagnostic as you can. Once you have proved yourself as a good tester and coder, with good product knowledge, the move into development is easy just talk to the people you know about moving.
This is exactly what I have done, moving from a sys admin role, into software test, and will be moving to developing the product I once tested in a few months time.
Good luck and hope you enjoy it!
If you ever drop your keys into a river of molten lava, let'em go, because, man, they're gone.
See if your current employer has any opportunites. The advantage is that they already know your a good worker (assumption ;) and you may already know some of the managers in the development area and can convince them to take a chance on you. If you have to, offer to keep doing your current system administration duties. This could mean extra work for you, but if you can gain the programming experience you need it will be a win in the end.
My other advice is to keep your system admin skills fresh. I have been doing both sys admin and programming for my entire career (15+ years) and when times are tough, like now, being able to take jobs in either area is a nice advantage to have.
I started programing in BASIC and then BASICA on an old IBM XT with IBM DOS 3.something. I learned by example from BASIC games in the back of Highlights magazine (science version) borrowed from my JrHigh teacher. I now work at a small game developer in southern California making 35,000USD with only a GED.
I give that background to say that this 0.02USD is coming from the other end of the spectrum, I've taken some CS courses at the local Jr College, but of the 3 professors, 1 is a geneous (worked for JPL out of highschool and designed a guitar pedal for Hendrix) and the other 2 are boneheads, after I did all the courses from the good prof. I quit and am now looking at going back to school for a completely job unrelated major (like english).
Anywho, so I really don't know what your CS studies have given you in the way of preparation for the real world of programing, but if say you were going to come work with me, here's what I'd want from you.
1) DOCUMENTATION! DOCUMENTATION! DOCUMENTATION!
I don't know about undergrad level CS, but the 100 to 200 level courses I've been exposed to lacked grotesquely in this aspect.
Remember, when you get paid for code, sure your check depends on if it works or not, but to give your employer their honest moneys worth you should really supply documentation in the form of at least one technical design document and lots of comments in your code. Also (and this is more personal preference than anything) most compilers in most languages can work with pretty long variable names so use the long names and save on comments (I don't mean never use 1 letter variables, 'i' is fine for a loop incremental, but with more importaint or complex things, go big).
Remember, you're probably not going to be at company X forever. So when the time for feature additions or new platform support comes down the line, the code you can be proud of is code they can throw at a Jr programer for the tweaks and not give him/her an ulcer just trying to figure out WTF you were trying to do, let alone where the bug/incompatiblity is. Also, even if you are at company X forever, you may be busy with project Z when they need work done on project Q from when you first started there. So they give the fixes to another programer, imagine how embarrased you could be if they crack open your source and see a big uncommented mess! Maybe project Z will end up being your last.
2) Avoid band-aids!
Note I say avoid and not never use. When there's a problem with the way an object was designed (possibly due to no fault of your own, being a smaller company in the games buisness, publishers love to throw feature changes at us half way through a project because they can get away with it) take the time to rewrite the object if needed. Of course unless it's the day before your milestone and there just isn't time, then it's okay to do a bandaid, but then document the hell out of so that when/if anybody else has to go into your code you don't look like an idiot.
3) Paper first!
Thats something I learned from the 1 good professor at my community college. When I whip up little tools and such (which I imagine is most of the author's experince, making tools to make admin life easier) I just jump right in and code. However, when it's code in the actual product it's worth it to take the time to sit down and draw it all out on paper. Pseudo-code, object diagrams, hierarchy, sure there's visualization programs out there but it's faster on paper.
One of the big advantages of drawing it out on paper is that as a programer (at least as me) you get attached to that object you stayed up until 3AM writing. Then you find a flaw in it and should rewrite it, but it's so much more tempting to just bandaid it. If it had been written out on paper first, you may've caught the design flaw ahead of time and instead of throwing out all that code, all you're looking at is a little scribble here, jot down some new psuedo-code and a little scribble here, there and there to carry the changes to all the depen
DONT PANIC
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:
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:
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