Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Education

From System Administrator to Developer? 81

Posted by Cliff from the making-a-change dept.
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?"
This discussion has been archived. No new comments can be posted.

From System Administrator to Developer? More

From System Administrator to Developer?

Comments Filter:

  • It's no big deal (Score:5, Insightful)

    by puckhead ( 241973 ) on Thursday June 19, 2003 @11:55PM (#6250638) Homepage Journal
    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.

    • Re:It's no big deal (Score:3, Insightful)

      by Sentry21 ( 8183 )
      If you know how computers work, it's not much of a leap to programming them.

      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
      • I'll grant that there are a different set of tools. I've not had much trouble adapting to them. I know several people who work both sides of the fence effectively.

        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)

      by sql*kitten ( 1359 )
      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.

      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)

    by ChiefArcher ( 1753 ) * on Thursday June 19, 2003 @11:59PM (#6250664) Homepage Journal
    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
    • I wonder how common it is that programmers come to hate programming or even computers in general.

      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?
      • I haven't even been programming (professionally) for a year now, and I'm already burnt out. I used to PLAY with computers... in school, I'd write programs for fun, do neat things, just play with things. But since I started doing this for real, I never do that anymore... I still have ideas of things I'd like to do, programs I'd like to write, but I come home after a day of programming (lately, working with COM... aah! EVIL!) and I'll be just tired, and with no motivation to do anything with computers (other
      • I've been in the software development profession for almost 3 years now and I'm not burned yet. Every project i work on I am practically learning something new, but there are times when I'm bored to death. Some weeks things are so slow (waiting on other people) I end up maybe doing maybe 15 hours of actual work. Of course there are times where 12 hour days are necessary. All in all, I can't see myself doing something else. Well, maybe teach, but that doesn't pay. I got bills baby and my monthly expenses are
        • I think a lot of the wrong people go into programming because they love computers but the straight sit and code isnt right for them. The parent is one of hte people for which the job works.

          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.

      • I've been programming for about 9 years now and over the past two years or so I've really been starting to burn out.

        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
      • I wonder how common it is that programmers come to hate programming or even computers in general.

        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)

      by hawkstone ( 233083 ) on Friday June 20, 2003 @01:24AM (#6251082)
      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.

      • Re:Programming.... bleh! (Score:1, Insightful)

        by Anonymous Coward
        It isn't so much the computers and programming so much that cause burnout. It's more a factor of the shortened schedules, insufficient resources, and general lack of consideration for the programmers that is the seed of the eventual burnout.

        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

      • 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

        • The same burnout effect can happen to professional atheletes, as well. Ever heard of Alexandre Daigle? He was a first overall NHL draft pick, and was expected to be a superstar. He only played about 5 years and just quit. He said he was bored, and effectively burnt out, after playing hockey since he was a small child. Eventually he admitted that the main reason he played was because he was good at it, not necessarily because he loved to play.

        • Does putting "burned out" in quotes mean we're not making a distinction between losing passion/interest and going insane from being hunched over putting out lines of literature for years?
          That's sort of what happened to Poe, right?

        • 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. :)
      • If you've been stuck in a job where you've got several projects on the go, possibly all in different languages (plus databases), and with upcoming deadlines: chances are you will at some time face burnout. It's nice in that case to be able to have something to drop back onto. Sysadminning is a decent switch as you still have some coding but are often away from the hardcore coding. In the same aspect, coding can be a nice switch after being a sysadmin where users are screaming at you because their end-of-yea

    • I have done several jobs with and without programming. I have done (somewhat chronologically) :

      1. computer installations
      2. programming with Clipper
      3. programming with FoxPro
      4. programming with C
      5. tested trains electrically and functionally for Bombardier
      6. been unemployed
      7. followed a course in automation (hydr., pneu., PLC)
      8. automated a 400 ton alu press through PLC
      9. learnt and programmed COBOL for 4.5 years
      10. been in software configuration management

      My experience teaches me this about myself and programming : I like t

    • I tried explaining to my wife that I don't want to program any more (after 6 years) and she I shouldn't even think such a thing, as what else could I do?

      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
  • I'm actually doing the same thing as you. I'm not a big fan of programming, so I don't know why you would want to do that. I would suggest studying finance as an alternative and not trying to make the switch over. Programmers are a dime a dozen ;)
    • <Programmers are a dime a dozen >

      but good programs will cost you at least 36000 dimes a dozen (do the math).
    • Programmers are a dime a dozen ;)

      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

  • Prove Yourself (Score:5, Interesting)

    by Markus Registrada ( 642224 ) on Friday June 20, 2003 @12:17AM (#6250763)
    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 (Score:4, Insightful)

      by jmt9581 ( 554192 ) on Friday June 20, 2003 @12:30AM (#6250831) Homepage
      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.

      • Re:Prove Yourself (Score:4, Insightful)

        by grammar nazi ( 197303 ) on Friday June 20, 2003 @12:39AM (#6250886) Journal
        jmt9581,


        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.

        • Perl programs are typically like batch programs. They usually lack object oriented structure. And writing object oriented perl program isn't exactly as easy as writing an object oriented C++.

          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.
        • Perl teaches bad programming habbits if one didn't study it in full. One hust needs to read all manuals and better code produced by professionals. The problem of OO in perl is that there are no dedicated keywords for it in syntax (like "class" or so) since OO is supported by a "special handling" in Perl, so people who just study language by glancing on the syntax are missing it. So Perl somehow may be indeed imperfect for bad programmers.

          The biggest problem of Perl compared to other popular languages like

        • I hate to tell you, but there's-more-than-one-way-to-do-it in almost every programming language out there, as far as readability and style goes.

          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)

        by pb ( 1020 )
        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 habit

        • Re:true, but... (Score:3, Insightful)

          by Eneff ( 96967 )
          No, there's a big difference.

          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)

            by pb ( 1020 )
            That's why God created expand and unexpand; all you have to do is figure out how to use them once, and then you can make all your tabs/spaces problems go away forever.

            Sometimes inconsistency is worth it; it all depends on the situation. Remember, "foolish consistency is the hobgoblin of little minds".
            • Exactly - just use the tools to fit other code to your habbits.
            • >That's why God created

              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)

        by jbolden ( 176878 )
        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.

        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)

    by Anonymous Coward on Friday June 20, 2003 @12:28AM (#6250824)
    Either way, your job is going to get shipped off to India.

    • Actually, it's probably less likely that a sysadmin job will be shipped off to India, since there will always be hardware here in the states, and there will always be a need for _someone_ to manage it.

      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.
      • Depends on the scale of your company. A big one (mine is an example), would ship off SAs/DBAs first.

        -DVK
        • Most, maybe, but not all....

          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)

    by jkakar ( 259880 ) on Friday June 20, 2003 @12:54AM (#6250958)
    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!
    • 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.

      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)

    by vince1 ( 660035 ) on Friday June 20, 2003 @01:00AM (#6250980)
    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.
    • One of the concerns I hit at work is the gulf between the sysadmins and the programmers. Too few sysadmins are good at programming and too few programmers know anything about keeping the system maintainable. We just went through a bunch of sysadmin resumes and those that got attention included programming. If you are a sysadmin who can program it looks great in the interview and can build your niche as you transition. If you are considering this as a transition path, go for it! You'll put yourself ahead of

    • 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?
      • For one, a sysadmin does not have to care about understand how to translate an end users business requirements into extendable and robust code.

        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).

      • 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?

        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)

    by msuzio ( 3104 ) on Friday June 20, 2003 @01:04AM (#6250999) Homepage
    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 :-).
    • Pish-posh to the idiots who say being a Perl programmer somehow taints you. Please. Bad programming habits can occur in any language...

      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 /etc/passwd how would you do it? Most perl programmers would read it and split() on :. I've done the same myself if I just want to do
  • 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

  • Sysadmins and Software Engineers (Score:5, Insightful)

    by hbo ( 62590 ) * on Friday June 20, 2003 @02:40AM (#6251374) Homepage
    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 [egbok.com] about it. The software it describes is at http://egbok.com/sudoscript [egbok.com]

  • Find An Unmet Need (Score:4, Insightful)

    by esme ( 17526 ) on Friday June 20, 2003 @03:01AM (#6251454) Homepage
    I started out at a small (~15 people) company, and I mostly did desktop publishing stuff. I was also into Linux, so when the guy who had been running the office server left, I got that, too. I later left and got a job as a sysadmin.

    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)

    by rikkus-x ( 526844 )
    I followed the same route, here's a brief rundown of what happened.

    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

  • 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

  • I. You can always go back
    II. Everything becomes boring after some time
    III. Next career step might be training
    IV. ...or management
    V. ...or management of networks, not people.

    Enjoy ! :-)

  • Go via Testing. (Score:3, Insightful)

    by Manic Miner ( 81246 ) on Friday June 20, 2003 @06:06AM (#6251936) Homepage

    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!

    • 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).

      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.
      • As a tester I earn either the same, or in some cases slightly more, than people of similar experience / age who work for development within the same company.

      • Re:Go via Testing. (Score:1, Insightful)

        by Anonymous Coward
        High-end testers are basically a combination of programmer and sysadmin. They need to understand configuration management as well as write scripts for WinRunner (etc) or even things like unit tests. A lot of them end up managing builds, reading debugger output, etc.

        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)

    by Lord Sauron ( 551055 )
    Behold the Bastard Developer From Hell.

    He makes programs that will surely crash or give false results, thus freaking out the luser.

    Rumor says some BDFHs work in Microsoft.
  • the Knuths! the Knuths! the Knuths are on fi-ah!

  • Programmers Program (Score:3)

    by Dunkirk ( 238653 ) <david&davidkrider,com> on Friday June 20, 2003 @08:22AM (#6252373) Homepage
    There are some really good comments here, but I haven't seen this one yet. I came to understand it because I've had several young people ask me to teach them to program. I'm of a strong opinion that programming can't be taught. At least, not useful, elegant, maintainable, and thrifty coding. I quite agree that coding is an art, and, as such, the old adage "writer's write" is key. I've heard this told to aspiring writers, and it simply means that if you have a future in writing, you will already be, say, keeping a journal, or submitting stories to the local paper, or, these days, keeping a blog. The point is that when someone is at the point you're at (asking if they should go into a field), you can predict their success based on what they're already doing. The bottom line is that if, as a sysadmin, you don't find that you're already writing a lot of programs to help you do your job, then you're probably not really a programmer. Can you do it anyway? Sure. Anyone can do anything they have the talent for given enough determination, but it will just be a job, and that tends to wear thin. I guess I'm in the camp that believes that a being able to write really good code is more of a gift than a talent, and finding your purpose in life is about finding your gifts. If you have that gift, you'll enjoy it. But if you do, you're probably already doing it.
  • 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 b
  • What about moving from programming to system administration?

    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.
  • ...wanna switch?
  • I think it happened because it was supposed to in
    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)

    by x00101010x ( 631764 ) on Friday June 20, 2003 @11:43AM (#6254358) Homepage
    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
  • I am a web developer but since I am the only technical person in the company (15 employees, ceo and president are a married couple) I end up taking care of all IT. In my previous job IT meant 99.99% Microsoft stuff. Here it is two windows servers, two windows desktops and at least 15 mac desktops. Oh yes, and a freeBSD mail server.

    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)

    by phamlen ( 304054 ) <phamlen.mail@com> on Sunday June 22, 2003 @09:29PM (#6270353) Homepage
    (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

    • Thank you. What do you find more rewarding? I've done a mix of sysad and ops management, with programming/dev only at the academic level. I found many aspects of management enjoyable and challenging, but am now back to infrastructure management because I worried I strayed too far from the hands-on work that got me to management to begin with. I'm wondering if my future in infotech management will suffer because I don't have professional program development in my resume.
  • this is a great idea. I'm a dba (a flavor of syadmin) and a developer. Not a "wears two hats, expert at neither" that you see in small shops or MS shops. Got several years of doing each intensely.

    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.

Slashdot Top Deals

Make sure your code does nothing gracefully.

Close