Moving into software development from another field can be quite a daunting quest. Here's how I created my own somewhat unconventional path from Business Analysis to full-time software development.
I started out in the working world as a business analyst. I thought I would enjoy being someone who bridges business requirements with technical teams but quickly realised it wasn't for me. I wanted to actually create something instead of only being a part of the process.
The draw of software engineering: Learning a craft
What was it about writing code that was so appealing to me? At the time I may not have been able to articulate this but I definitely felt a lack of creative expression as a business analyst. I was also missing any sense of craftsmanship in my job.
To me, software development is positioned at the intersection of creativity and logic. A developer has the ability to create something that did not previously exist and to solve real world problems with a combination of abstract concepts and physical hardware.
At the same time, they continuously improve their own ability and broaden their perspective to be able to solve and create more in the future. I felt drawn to the idea of having a tangible skill that I can nurture and improve.
I feel like there are some common traits shared by most software developers. We:
- Enjoy solving problems,
- Love to create,
- Continuously learn.
I've always shared those traits and have been drawn to hobbies and activities with a high skill ceiling, such as learning musical instruments, playing competitive multiplayer computer games and taking part in difficult physical activities. Software development is quite similar:
You can never truly learn it all, you can always improve. There is no skill ceiling and the more time and effort you put into the craft, the better a craftsperson you will become. This was the biggest draw for me.
Starting out can be quite scary. When researching what you need to learn to become a web developer, you will stumble across some pretty daunting roadmap diagrams and forum posts.
Choosing full-time employment
Despite that, defining my educational direction was incredibly important. Software development is a broad field and I needed to decide where to start and ultimately, where I wanted to end up. I knew a developer could work in the following dynamics:
- Freelancer / Indie hacker: Someone that is self-employed and not bound to any one employer but instead free to manage and market themselves. Amongst freelancers, **indie hackers **are the ones that spend their time developing their own products and services as opposed to working directly with clients in a services engagement.
- Full time employee: Someone who is bound to a particular employer and spends their time writing code to further the business objectives of the organisation by whom they are employed.
I knew that, as a junior developer, I would need experienced mentors and guidance to progress in my craft. Having a support system would be crucial to my growth as a new developer. I'd need quite a lot more experience, solid relationships and a more holistic view of the industry to freelance and build profitable businesses - neither of which I yet had.
While taking any opportunity seriously, I knew that finding a full-time position would benefit me, especially as a new developer, the most.
Choosing web development
Next, I needed to decide what software I wanted to build. The field is broad and there are many different learning paths, concepts and technologies specific to each segment of the software development environment. After doing some research, browsing reddit threads and chatting to my developer friends, I chose to pursue web development:
- The barrier to entry seemed lower and there were plenty of jobs available at a junior level.
- I could learn almost any backend language I'd like, I wouldn't be bound to a specific tech stack that may have been more difficult for me to learn at the time.
- I had a network of web developer friends I could ask questions and lean on for advice.
- Web development had started to cross over into other areas as hybrid development platforms matured and allowed web developers to build native mobile & desktop applications using familiar web technologies.
Once I had made this decision, I needed to decide on how I would build up the skills and expertise to make myself hireable. I knew learning to code was not going to be all sunshine and semicolons, I had to get stuck in.
Choosing Ruby as my first language
To start, I needed to pick a backend language to learn. It is so super hard to pick as an enthusiastic but naive new developer. Which languages are great for beginners but have a high skill ceiling? Which would enable me to build out my project ideas? Which was high in demand?
After spending a bunch of time surfing the web and going through the first couple of chapters of different introductory books, I chose Ruby, because it seemed to:
- Have an awesome community behind it,
- Have job opportunities; both local and remote,
- Be easy to learn but difficult to master and
- Be, as a language itself, beautiful to me.
Of course I could have chosen a number of other languages with similar qualities, but I had a feeling of craftsmanship working with Ruby. Its web framework - Ruby on Rails:
- Enforced a strict set of conventions on the developer which is fantastic for new developers to learn best practices and not fall into bad habits,
- Has clean and readable syntax and, most importantly at the time,
- Emphasises developer productivity and happiness through it's readable & elegant syntax and it's foundation in being an intuitive language
I would encourage others to go through a similar analysis but not to overemphasize your choice in programming language when learning to code. There is opportunity to land yourself in a state of real decision fatigue and you'll find yourself spending more time making these kind of decisions than actually learning. The development ecosystem is growing daily and releases new flavours-of-the-month-frameworks and technologies at a faster rate than ever before.
Find something you enjoy and start creating. You'll quickly learn that most programming concepts are transferable across languages and frameworks - the importance lies in grasping and mastering the fundamentals.
Taking a just-in-time-approach to your learning
At the early stages of learning to code, take a just-in-time instead of a just-in-case approach to your education:
Once you have grasped the fundamentals, start creating something. Learn on the go, learn things as you need them - you'll avoid educational overload.
I have always been one to enjoy different learning media and decided I would mix up my learning resources to keep myself engaged and excited to learn:
- I spent time going through the free MIT Opencourseware. This was a fantastic way for me to learn some computer science fundamentals - something I was definitely lacking coming from a business analysis background.
- Amongst others, I completed an in-depth Udemy course during which I created a basic blog application, an Instagram clone and a stock tracker app. I integrated with services such as Stripe and Yahoo finance, learned how to write tests and deployed my applications to an infrastructure as a service provider. All the while learning and making use of git source control!
_Tip: Diversifying your learning media can be an effective strategy for many. When starting out, you will be absorbing a lot of information in a short period of time. Often times, going through the same concept multiple times across multiple learning media will solidify the concept in your mind. _
Also: Don't forget to put what you've learned into practice!! Build something with what you've learned and you'll understand so much more once you actually create something.
Finding your first developer position
Just under a year of working through these resources, after building various projects and having a competent understanding of web development concepts - I still felt like I was not good enough to apply for my first developer position. Perhaps I was experiencing what I now know to be
The Imposter Syndrome (Arrie wrote a fantastic article on his experience fighting through the Imposter Syndrome right here on Offerzen's Blog).
At this stage I thought I would need to prove myself somehow. Perhaps by building a software product that people actually enjoyed using and something that could either sustain me financially or to use as a way to prove my competence when applying for jobs.
I started immediately. I had a list of cool software product ideas that I thought were worth building. I picked the one I thought had the highest chance of success and started building it. One evening in particular, I was hacking away on my side project and was wondering if there were anyone like me in Jozi - working on side projects with Ruby on Rails that I could bounce ideas off or even partner with.
I came across a Ruby meetup, went, exchanged particulars and a few days later I was on my way to my first developer interview:
- The first step in the interview process was a culture fit day where I spent time integrating into the team and pair programming with other developers. This was great and gave me a chance to experience what working at the company would be like before I actually decided to join
- Next came a take home project. I had to integrate with an API they had put together to assess potential candidates. This was pretty scary because the feeling of being exposed as a novice crept in but I ended up really enjoying it. I felt it was the most fair and fun way to be assessed as a developer.
- Next came a face-to-face "traditional" interview with the business owner. The fact that I had made it this far was a real confidence boost and the interview went really well. He got a sense that I was lacking in experience in certain areas but appreciated the fresh perspective I could bring to the development team and decided to offer me the position.
About six long and hard months after deciding to make the transition I had just landed my first professional software development position and I couldn't of been happier.
Lessons from transitioning into software development
It was a surreal feeling having finally and officially transitioned into a professional software developer. Some things I learned throughout the interview process and my first few months as a junior developer include:
- Networking and spending time learning from others is never a waste of time. Meetups and developer events are a great way to get integrated into the software development community and learn awesome new things. I got my first developer job after attending a meetup which goes to show how powerful spending some time networking can be!
- Companies are willing to take a chance on someone passionate about their craft and those whom are excited to learn - regardless of possible rough edges or the lack of a formal computer science background.
- Companies require technical competency but also appreciate fresh perspective. Coming from a business analysis background I had developed great communication and collaborative skills. I had leadership and client relations experience which would prove valuable - especially to a services/consultancy such as the company I was interviewing at. Don't discredit your past experience if coming from another profession.
- Find a company that will mentor and actively grow you as a new developer. Having more established, senior developers guide you and help develop your skills is so important as a junior developer. Do your best to find a company that fosters this environment.
For someone coming from a different career, moving into software development can be quite a daunting path. I hope through sharing my story and findings I am able to help others looking to make a similar transition. I've included some of the learning resources I used while skilling up below and hope they help someone out there!
- https://ocw.mit.edu/courses/intro-programming/ - MIT (one of the best computer science schools in the world) has opened up their introduction to programming course. A great resource for those wanting to learn some computer science 101 fundamentals.
- https://www.udemy.com/the-complete-ruby-on-rails-developer-course/learn/v4/ - The Ruby on Rails course I completed. This course is excellently presented and is a perfect blend of practical and lecture based learning.
- https://www.railstutorial.org/book - A book I read in parallel to completing the above course. Has become a well known book for new Ruby/Rails developers.
- https://www.manning.com/books/the-well-grounded-rubyist-second-edition - A Ruby book that takes a deep dive into the language
- https://www.freecodecamp.org/ - Freecodecamp have incentivised people to learn to code by building projects to assist non-profits and at the end of their courses, award freecodecampers with their self-branded proficiency certifications. This is a fantastic interactive resource when learning front-end skills in particular.
- https://www.w3schools.com/ - A concise overview of front-end web technologies and a great reference point when learning to build web interfaces.
- https://www.codecademy.com/ - An interactive online coding platform that attempts to gamify the learning process. Can be a nice escape from other learning mediums.
Matthew is a Team lead and software engineer at Fusebox. He spends way too much time in front of his laptop but also enjoys weekend football, making music and a good coffee. He also runs the community newsletter DevByte so if you enjoyed this post, head over there and subscribe.