So you’re an IT guy who wants to be a developer eh?

A few days ago I was searching for an initial topic to blog about, when an old friend asked me for some pointers on moving from IT to a developer role. I figured this was as good a starting point as any!

First let’s start with the secret the recruiters don’t want you to know – you don’t need to settle for an entry level position nor significant pay cut! You’ve been in IT for a while right? 2yrs? 5yrs? 10yrs? more? I made the move back in 2001 with barely 1 year of ad-hoc on-the-job development experience and went on to become a Lead Developer within 2 years! I can’t guaranteed that everyone will find it this easy, but if you’re passionate and willing to follow a few easy steps, I think you can do it!

So what are these steps? There’s three actually. I call them Immersion, Practice, and Refinement. I’ve used these three steps to do everything from Painting to Music Making to Rock Climbing. I’d say they’re more like “stages” than steps, and you’ll find yourself iterating through them repeatedly as you master a given role or skill.


It all begins with immersion. If you’re looking to change roles, you need to immerse yourself in that new role in order to get a guaranteed drip feed of critical industry lingo and terminology. Now bear with me, you’re probably thinking “gee that’s obvious”. This is all part of avoiding the “car crash interview” and it’s part of surveying the lands and getting an idea of what are the unknown-unknowns. The great part is, you are probably already performing this step without even thinking about it. If so, congrats! You’re already 1 for 3! The key to immersion is to become a part of the environments which developers do. Hang out on industry blogs, find a local meetup or free conference, lurk in a development Slack channel, hangout on the Stack Exchange Software Engineering Channel, or even scan through Reddit’s many developer forums. You want to become familiar and used to the common terminology you’re going to initially encounter. Learning the lingo, even at a surface level, helps to improve your confidence and prime your mind for better understanding when you are ready to engage those topics fully in the future. If I were to say “what sort of interfaces and design patterns might you choose to construct a library book management app”, you don’t want to be looking around like a kid lost in the woods. After immersing yourself it’ll be impossible to not have at least heard these terms several times in passing. You might even know that ‘interfaces are how we define contracts in software’ and ‘design patterns are re-usable software designs for common problems’. You might not be able to answer questions for a “Lead programmer” role, but you’ll know enough to say* “My experience with design patterns is limited but I’d….”*. The key is to get a better understanding of what you do and do not know. Once this becomes clear, you can approach both learning and interviews in a cool an honest way.


Next comes practice. This stage is simple but critical. It’s time to build an app! You’ll want to set yourself up with a fresh GitHub account and create a free, personal code repository.  Think of a task that you perform on your computer, or a common automation task that you perform by other means and let that be the starting point for your initial project. My first serious app was a network scanner which used multi-threading to reach out, ping, and record the responses on a given class C network. Simple. If that sounds difficult, don’t worry,  in a few short weeks of practice and immersion, you’ll be able to write that same app — even if it isn’t perhaps the cleanest and most object oriented code ever.

Having fresh code in your GitHub accomplishes several things. First, it proves you’re serious about wanting to be a developer. Second, it shows that you have at least a basic understanding of the most popular code repository on the planet. Third, it will be your own personal motivation. Ask any coder and they will tell you that starting a new project can be tricky but once it gets going, you’ll end up coding into the wee hours of the morning as you think of new features and ways to optimize, refactor and improve your code. Once that happens (if it hasn’t already), you will have ignited an insatiable desire to develop ever more performant and elegant code — the learning will come as a byproduct.


The last stage is what I like to call refinement and I’ll tell you right now, it goes on indefinitely. This is the constant process by which you’ll take the things you’ve learned while immersing yourself and practicing, and dig deeper. “This SOLID acronym seems to be mentioned a lot, what’s that”? These are the questions you’ll start digging into. Now it’s time to open a book or browser, and learn more about concepts that you may only know by name. If a concept still seems ‘clear as mud’ after reading about it, lay it down, and loop back around to another concept. It takes years to gain full and deep master of all the myriad concepts associated with software development. That being said, within a few weeks of immersion, refinement and practice, you’ll have the skills to talk smartly and demonstrate your knowledge of common software engineering concepts!

Good luck!