From System Administrator to Developer? 81
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?"
It's no big deal (Score:5, Insightful)
Re:It's no big deal (Score:3, Insightful)
Ah, but there's more to programming than 'know[ing] how computers work'. There are the fundamental design philosophies, object-orientation, project management, team development, debugging, releases - the whole gamut of Software Engineering courses. Not to say that it's some exclusive field, but just because you're a good systems admin doesn't mean you're a good programmer automatically, or vice-versa.
--Dan
Re:It's no big deal (Score:1)
As for courses, When I went to college computer still meant mainframe and I studied beer.
Re:It's no big deal (Score:3, Insightful)
Some of the skills transfer, but I have noticed in myself and others sometimes the personality does not. System administration involves a wide variety of small tasks, each of which has "closure". There is a beginning and an end to system administration tasks, even if they're routine, like starting a rollout of a patch, then it being complete. You need t
Programming.... bleh! (Score:4, Insightful)
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
Re:Programming.... bleh! (Score:3, Interesting)
I know many people including myself who has burnt out on computers. We are looking for other work in other fields but in the meantime computers pay the bills. One guy I knew went off to medical school, another teaches day care. They are both much happier now than at the point they quit from computer programming.
I wonder what the burnout rate is among programmers. What is the average industry lifespan?
Re:Programming.... bleh! (Score:2)
Re:Programming.... bleh! (Score:3)
Re:Programming.... bleh! (Score:2)
Re:Programming.... bleh! (Score:1)
it seems to me that there are many people who want to be proficient programmers and be able to write any tool they need BUT they dont want to write tools that someone else needs over and over, they might be better suited for a job as a sysadmin. occasionally have to write a tool for themselves, etc.
Re:Programming.... bleh! (Score:2)
Several things happened around that time, so any one of them or a combination of them could have been the cause.
- I started taking a perscription for social anxiety, and started to do more with my life socially, and a lot of new interests opened up to me that were not related to technology.
- I had my first serious relationship, and shortly after, my first serious breakup. I think I might h
Re:Programming.... bleh! (Score:3, Insightful)
I've felt that at times. For me, it was always about the work and the work environment.
Years ago, I was a sysadmin, mainly because that was the work available. But in working 70-hour weeks for a couple of financial companies, I completely burned out on it. Even now, if I have to do more than a couple of hours of it, I get immensely surly.
So I switched to full-time development, which was what I preferred. For
Re:Programming.... bleh! (Score:5, Insightful)
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.
Re:Programming.... bleh! (Score:1, Insightful)
Then I became a manager and it just got worse. Now the customers want their projects finished yesterday and by the way our license to perform certain engineering runs out tomorrow so you'd better stay late and wrap that up as soon as you can. And customers don't want
Re:Programming.... bleh! (Score:3, Insightful)
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--plenty of famous authors, artists, etc have completely burned out from the amount of effort and spirit they put into their work. Champollion from his efforts suffered a nervous breakdown at an extremely young age and burned himself out. Goethe, Poe, and many many others "burned out"... I would consider them artists ;) Not
Not just artists... (Score:2)
Re:Programming.... bleh! (Score:1)
That's sort of what happened to Poe, right?
Handling burn out in the programming field (Score:2)
Move up in responsiblity.
As you take on more responsiblity you get farther away from coding and more into a larger scheme of things, technical design, managing people, moving numbers around in budgetting.
Its a whole different set of skills, whole different world and you are leveraging the base/low-level knowledge you have from programming.
Looks good on a resume, its good money and you can always return back when you feel like you are getting "burn-out" from the higher level stuff.
Depends on the environment (Score:2)
Re:Programming.... bleh! (Score:1)
I have done several jobs with and without programming. I have done (somewhat chronologically) :
My experience teaches me this about myself and programming : I like t
Re:Programming.... bleh! (Score:1)
I think it depends on exactly what you're doing. My first job I hated after only a short time, but my second job was great and I'd have been happy doing that forever. Amazingly, I'm only on my third job in that time. It's not what I want to do for the rest of my life, though.
As to what else could I do, probably a lot of things, but the current job mark
Well.. (Score:1)
Re:Well.. (Score:2)
but good programs will cost you at least 36000 dimes a dozen (do the math).
Re:Well.. (Score:2)
But problem domain experts are not. This is why interviewing for a programming position can be so frustrating. It is also hard to get past the severe biases present among programmers and the companies that hire programmers (e.g., "We use Struts. Struts is like manna from the gods, because we read about it in Java Slut magazine." or "Ant is better than make...because it's Java and XML and is the latest craze among us teenie-boppers"). System administrators are not immun
wrong topic (Score:1, Informative)
Prove Yourself (Score:5, Interesting)
(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 (Score:4, Insightful)
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.
Re:Prove Yourself (Score:4, Insightful)
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.
Re:Prove Yourself (Score:2)
I'm currently writing one big multi-threaded perl program to distribute tasks among networked computer and to tell you the truth writing it as if it were batch program is much easier than trying write it in object oriented fashion.
Re:Prove Yourself (Score:1)
The biggest problem of Perl compared to other popular languages like
Re:Prove Yourself (Score:3, Funny)
since when did perl need any more obfuscation?
Re:Prove Yourself (Score:1)
"Review" of Stunnix Perl-Obfus (Score:2)
Re:Prove Yourself (Score:2)
I'm currently debugging some Ada code at work that was written by a primarily-C programmer. And believe me, this sticks out like a sore thumb in his code and makes it hard to read even though I am "fluent" in both Ada and C.
Perl doesn't teach bad programming habits. Perl just allows bad programming habits to a somewhat higher degree than other languages. There
true, but... (Score:3, Insightful)
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 habit
Re:true, but... (Score:3, Insightful)
For example, I hate spaces used for tabs in programming, mostly because I prefer 4 spaces for myself while many others prefer 2. If I'm looking at code, I do *not* want to see half of one and half of the other even if I prefer one to the other.
Most things that I dislike are tolerable if consistant. Inconsistancy is the great sin.
blah. (Score:1)
Sometimes inconsistency is worth it; it all depends on the situation. Remember, "foolish consistency is the hobgoblin of little minds".
Re:blah. (Score:1)
Re:blah. (Score:2)
The point is that it wasn't correctly formated in the first place. "A sloppy mind makes for sloppy code."
>Sometimes inconsistency is worth it; it all depends on the situation.
Could you tell me when inconsistency is worth it when it comes to formating? I really can't see a business rule or difficult programming situation where it would be acceptable. Being lazy or the fact that I am limited to 80x40 characters on the screen is not an acceptable reason.
Re:Prove Yourself (Score:3, Interesting)
Have you ever heard the expression "A fortran programmer can write fortran in any language"? Knowledge of a language encourages certain ways of thinking and expressing problems. Visual Basic teaches people to organize programs based on primary UI screens, Java teaches people to organize programs based on their understanding of what is being mo
Why bother? (Score:4, Funny)
Re:Why bother? (Score:2)
I think that it's probably a bad career path for anyone in the US or Europe to get into software development right now. You'll need an exit strategy much sooner than you'd think.
Re:Why bother? (Score:2)
-DVK
Re:Why bother? (Score:2)
Contrast that to development, where there's _no_ need for a single local person.
Really, they're both screwed professions, but SAs are less screwed.
Welcome to the brotherhood... ;) (Score:3, Insightful)
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!
Re:Welcome to the brotherhood... ;) (Score:2)
It all depends on where you work. I was a programmer for a year and a half, and realized that the programming I was doing was static and routine, and moreover, there was no way spice it up due to constraints imposed by higher-ups outside of the institution (for the lack of a better word). The job became mundane to me,
Closed mindedness of some companies (Score:3, Insightful)
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.
Re:Closed mindedness of some companies (Score:2, Interesting)
Re:Closed mindedness of some companies (Score:2)
There is a difference between being a sysadmin and a programmer.
For one, a sysadmin does not have to care about understand how to translate an end users business requirements into extendable and robust code.
If you have lots of experience as a dentist, does that make you a good doctor? Would you hire a dentist when what you want is a doctor and they are available?
Re:Closed mindedness of some companies (Score:2)
and if i was nasty, i'd suggest that programmers do not have to care about support. But i'm not nasty, so i'll just point out that it's 11:00 Am on a sunday and i'm installing patches on a production system - just to business requirements (24x7 employee self service for a global corp).
Re:Closed mindedness of some companies (Score:1)
Of course not, but that's not the point. To use your scenario, If somebody has all the qualifications of a doctor, does the fact that they have been a dentist before make them a bad doctor? If you think so, then that i
Entirely possible (Score:5, Insightful)
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
Re:Entirely possible (Score:2)
Not to the same extent. I'm not saying that Perl is a bad language, but it is one of a family of languages including TCL and shell that are best used for small, throw-away programs that just do one thing. Example: if you want to manipulate
Just ignore the narrow minded companies (Score:1)
Sysadmins and Software Engineers (Score:5, Insightful)
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 [egbok.com] about it. The software it describes is at http://egbok.com/sudoscript [egbok.com]
Re:Sysadmins and Software Engineers (Score:1)
Find An Unmet Need (Score:4, Insightful)
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
My experience (Score:2, Interesting)
I found a project that interested me (KDE) and started trying to write my own program for it. I tried to made a graphical version of videogen, which is an XFree86 modeline generator. My version made it a little easier to play with combinations of the various parameters, and therefore scratched my personal itch. IIRC I announced it on freshmeat and got a few emails from people who wanted assistance or to request features.
Now that I had a li
Irony is .. (Score:1)
I'm suprised at the direction of the change..
I grew up with computers, my first being a ZX Spectrum [worldofspectrum.org], then graduating through bigger machines until I landed in PC-land.
I fought for a job with a local company a few years back and managed to become a java programmer despite minimal knowledge. Since then I've worked for about four years as a Java/C++ programmer - utilising other skills such as perl, x86 assembly, etc.
After that much time though I realised I actually hated programming for other people - it t
Done it both ways. (Score:1)
II. Everything becomes boring after some time
III. Next career step might be training
IV.
V.
Enjoy ! :-)
Go via Testing. (Score:3, Insightful)
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!
Re:Go via Testing. (Score:2)
Does software testing pay? I've seen postings for software testers but am skeptical that those positions could pay as well as system administration or software engineering. I'd love for my skepticism to be proven unfounded, however.
Re:Go via Testing. (Score:2)
Re:Go via Testing. (Score:1, Insightful)
Keep in mind that there's tons of shite programmers out there who think "it compiles - now you tell me if it works". Especially with, um, foreign contract shops, QA gets pretty heavy investment sometimes.
During boomtimes, these guys were gettin
BDFH (Score:1, Offtopic)
He makes programs that will surely crash or give false results, thus freaking out the luser.
Rumor says some BDFHs work in Microsoft.
some obvious materials youll need (Score:2)
Programmers Program (Score:3)
Try your current employer (Score:2, Insightful)
My other advice is to keep your system admin skills fresh. I have b
The converse of this question is valid, too. (Score:2)
One problem I percieve is that employers currently have a surplus of canidates and have a luxury of being very choosy. So, for example, I have a stacked resume but not much system-administration-specific work experience, so I am already at a disadvantage relative to someone with even one solid year of sysadmin work under their belt.
It feels as if making any career change, right now, is an uphill battle.
Hey (Score:1)
From someone that's made this leap before, (Score:2)
my case. A large part of the admin work I've had
in the past involved task automation. I worked for
a very 'frugal' employer that wasn't interested in
spending money for anything. Over time, the projects
I spent time on got increasingly complex. What
started out in the early years as mostly writing
simple perl glue code to make product A talk to
product B snowballed into writing full shopping cart
programs in C. I made the jump to developer when I
was tasked to write
Here's my 0.02USD (Score:3, Insightful)
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
I am considering the opposite (Score:2)
I am noticing that it annoys me less and less to spend the day dealing with IT issues instead of writing code. It's also a lot of hands-on experience I was not getting before. I
It's possible - but be aware of the differences (Score:5, Insightful)
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
Terrific post... some questions... (Score:2)
sysadmin/programmers (Score:1)
this skill combination makes you qualified to work on large projects and gives you the deep admin skills needed to implement/make production ready the app you've developed.
my observation has always been that sysadmins as a group have fewer people skills than developers or people who work closer to the user.