Ask Slashdot: How Does an IT Generalist Get Back Into Programming?

CanadianSchism writes "I've been in the public sector for the past 6 years. I started off doing my work study in web design and a bit of support, eventually going through the interview process to fill in a data processing technician post, and getting the job. The first four years of my work life were spent in various schools, fixing computers, implementing new hardware, rolling out updates/ghosting labs, troubleshooting basic network and printer problems, etc. I was eventually asked to work on the administrative information systems with an analyst, which I've been doing for the past 2 years. That's consisted of program support, installing updates to the pay/financial/purchasing/tax/energy systems, taking backups on SQL servers, etc. I've never had the opportunity to take time for myself, and jump back into my first love: programming. I've picked up Powershell books (have two here at the office), but haven't gotten anything down yet, as there are always other projects that come up and whittle my attention to learning a language down to zilch. This new year will see a change in that, however. I'll be setting aside an hour every day to devote to learning a new language, in the eventual hope that I can leave this company (take a sabbatical) and hop into the private sector for a few years. My question to you all is, what language should I start with, to learn and get back into the principles of programming, that will help me build a personal portfolio, but will also lend to learning other languages? At this point, I'm not sure if I'd like to make/maintain custom applications, or if back-end web programming would be more interesting, or any of the other niches out there."

Comments

Re:simple

[19thNervousBreakdown]

Yep. Ain't no other way. Write stuff.

Even better, write stuff that's hard. Read stuff. Read really complicated stuff, and try to make it do other stuff. Nothing will teach you good programming practices like knowing why you follow them, and nothing will tell you why like seeing the hell that comes of not following them, which any large project is almost guaranteed to contain plenty of examples of. From misnamed or misused variable/functions, to multiple (and therefore slowly diverging) implementations of the same logic, to spending weeks reinventing something already solved in your programming language's standard library because they didn't like the order of arguments on a function, to bringing in a massive overcomplicated framework to solve a simple problem due to a too-strong avoidance of NIH (not that you shouldn't beware of NIH, you just shouldn't let it lead you into trying to pound a space shuttle into a square hole), you'll see it all.

Fix some bugs for a large FOSS project. Pick things that are just slightly over your head, and then pretend someone's breathing down your neck to get it done yesterday. Pick a project where you don't just get to commit changes, find something where your code is reviewed before it's accepted. You'll find a lot of honesty in people that aren't getting paid and don't give a shit about alienating you, and if you can handle a bruised ego you'll learn a lot.

One thing I wouldn't suggest doing is writing code for other people on your own, not right away. It's not that you shouldn't do that eventually, just don't do it when you care more about accomplishing your goal than you do about learning until you've got some good habits firmly established. Otherwise, your bad habits will just become reinforced, since they're usually easier especially when you're only looking at your own code, and to to be honest, you probably don't know the difference between a good habit and a bad habit until you've worked on a large project with a lot of people.

The best thing about working on FOSS projects is, you'll actually be able to demonstrate work to future employers. That goes a long way in an interview or on a resume.