Transitioning into software development from a different field can often be intimidating. This is something that I recently experienced when I moved into software from the field of robotics. While the change was exciting, it was not easy. Here are some of the most important lessons I learnt along the way.
Even as a kid, I knew that I wanted to work at the bleeding edge of bionics. With a head full of dreams, I decided to study mechatronics. Everything seemed to be going according to plan and, shortly after graduating, I was offered an unbelievable opportunity to work at South Africa’s hottest robotics startup.
During the first year, I was constantly learning and accepting new responsibilities but thereafter I found that I was stuck in a humdrum position doing the same things. Despite expressing interest, I wasn’t given the opportunity to work on new engineering design projects, which was incredibly frustrating.
I decided I wanted to leave, and I started thinking about what else interested me. Software development was something I’d always had an interest in yet never had the opportunity to really experience it at university or work, apart from a few small side projects. Wanting to challenge myself and work on something innovative, I decided, “Why not make this my focus?”.
So, I left my job and joined Pineapple, a startup that actually does what it says on the box. So far, the experience has been one of inclusivity, encouragement and learning with explicit growth opportunities.
As wonderful as this move has been, transitioning from a semi-corporate hardware-focused environment to a software startup has come with many lessons. My hope is that, by the end of this piece, you’ll not only still be sane but will also have an idea of what it takes to transition into software development. I’ll share some of what I’ve learnt and how you too can stick the landing.
First, you’ll need to pick up some new skills. Fast.
I realised pretty quickly that I was not adequately prepared for this line of work with what I’d learnt at university. I needed to add listable skills to my CV, and fast. I also knew that given my scant knowledge of software I’d be doing a good deal of on the job training and self-teaching. Thankfully, I’d had many inept lecturers to prepare me for this.
Learn through exploration and experimentation
I did some upskilling a few years ago before taking on my first job. At the time, I was considering a pivot into software and took a broad spectrum approach to familiarise myself with as much as possible. Nibbling on a little SQL here, some Javascript there, a healthy helping of Python. Oh, and figuring out what the hell Git is. I did this for several hours a day for just over a month because I was an unemployed graduate with precious little better to do. This is what you might call ‘blind upskilling’.
This bite-sized sampling approach worked for me as I didn’t really have a set direction in mind at the time. The goal was to give myself more market value by adding some bullet points to my CV as well as building a stable enough base so that I would feel comfortable doing technical assessments and interviews. In doing this, I also got a much better understanding of which sub-sectors within the software development industry I might want to explore.
Ultimately, I discovered that familiarity is more important than mastery at entry level. Gaining new skills of your own volition shows initiative and can be a talking point in interviews. What counts most is whether you have a decent head for problem-solving.
How to do this:
You may know whether you’d like to dabble in data analytics and machine learning, or web dev and mobile. It depends entirely on how much you know about what you want, where you want to be working, and what you enjoy.
Regardless of how this process may look or be structured, what matters most isn’t so much what you learn but how you learn it. (Provided you don’t plan on learning the arcane languages in the hopes of necromancing an Apple 2E back to life. Stick to what’s current and popular).
- Hit the tutorials, specifically the type offered by Codecademy which allow you to edit and experiment with code in a safe environment. Treat this like part-time schooling and do some learning after work or even on weekends if, like me, you’d like to justify why you’re an antisocial shut-in.
- Whatever you do, make it routine and scheduled. Put it in your calendar if you have to. I currently have a weekly reminder to sit down to write for three hours every weekend. Google bugging me about whether I’m ready or have already done it is enough of a call to action to get me typing.
- Try to set small goals for yourself so that you don’t become complacent or lazy. This is especially useful with new, daunting concepts or topics. The size and scope of these goals depends on you but make sure they challenge you.
Upskilling at this stage is all about establishing a foundation, building confidence, and creating a few new points on your CV to better market yourself. Anything above and beyond that is a bonus.
Then, take the time to find the right fit
I’ve found that being upfront and transparent with potential employers about what I'm looking for and what I can offer is mutually beneficial in determining whether we’re a good fit for each other. In my experience, this not only told them what I was about but also helped the companies I received offers from know how to structure the terms of my employment.
On top of this, I was upfront about my abilities (or lack thereof) but made it clear that I was eager to learn.
The best companies to work for are the ones who value your ability and potential rather than what you can offer right at this moment. They want someone who is a good fit for the team and is capable of learning quickly. So be yourself.
How to do this:
- The key is honesty – honesty on your CV, in interviews, and with yourself. Don’t inflate your skills and don’t misrepresent yourself.
- Remember that an interview works both ways, even if it isn’t always acknowledged as such. They’re sizing you up but you have the opportunity to size them up too. Find out how they handle and integrate newbies into the team. Ask about whether they can accommodate your skill level and the growth that you’re aiming for. These are arguably just as important as inquiring about salary and benefits.
- Look for a company with a culture that fits you. Part of this tall important fit is a company you’re not just comfortable working for, but are happy to go to every day. A place where you can be yourself. Ideally, anyway.
Think about what you need and want from a company rather than what you don’t want in a company. It’s a subtle but crucial difference of perspective.
Finally, Start Your New Career
So, here we are – against all reason you’ve made it this far (in the article that is). Normally, I only give out perseverance cookies at the 3000 word mark but you’ve been incredibly well-behaved, so take one.
Now the real work begins. You’ve developed new skills, survived the gauntlet that is the interview process and are starting a new chapter of your life at a new company. It’s extremely exciting but can be a teensy bit stressful. You may be inclined to display your competence by figuring things out for yourself, even if that means suffering in silence. DON’T do this.
When you get the job, get acquainted with your new stack
Now that I’m in my new position, I know what tools and languages I’m going to be working with as well as what is expected of me. As a result, I’ve been able to embark on targeted upskilling. Since, in time, I’ll grow to become a front-end dev, I was allowed to take nearly a full week to get to grips with React Native. Similarly, I was given the freedom to take a day to wrap my head around unit testing. Perhaps, these are elementary things to you, but to me, they were completely foreign.
How to do this:
- You should start learning the tools within your new company’s stack and becoming more familiar with the languages it uses. If there are any new tools or tech expected to be incorporated soon, why not take the initiative and run through a few tutorials? Then, when the time comes for features or products to be built using those things, you’ll have a leg up.
- Continue learning and developing skills even when you get comfortable. The learning at this stage comes far more organically since it will likely be driven by what the company needs and what you need to succeed. It’s something that will happen intuitively and doesn’t need to be forced. If you’re driven and want to do well at your new job, you’ll find yourself learning.
- If there were things you really took to during the blind upskilling phase, such as machine learning or web design, then keep working at those in side projects. Not only is it good to keep your skills diversified, but it also keeps you sharp.
You need to make mistakes (correctly)
In my new role, I have been very conscious about owning up to mistakes when I make them so that I can learn from them and hopefully not repeat them. Often it’s worth figuring out why I made the mistake too.
How to do this:
- The engineer in me wants to say that the best way to learn is by breaking things, taking them apart, and inspecting the innards. Thankfully, it’s pretty non-invasive to inspect the innards of software if you’ve access to the codebase. I’d advise against breaking things just to satisfy your curiosity though. Instead, accept that sometimes you’re going to make mistakes (maybe more frequently than “sometimes”) and occasionally you will break things.
- When something breaks or you make a mistake, accept blame and be humble enough to take guidance from your co-workers. Don’t be afraid to make mistakes and ask for advice – what counts is that you don’t repeatedly make the same mistakes but make a concerted effort to improve with each one. You’ll quickly become more conscientious, avoiding the same old mistakes as well as newer ones.
You should ask questions. Ask all the questions
There’s another developer who started at the same time as me, with vastly more experience, who is always asking questions because he wants to be sure he understands what he is doing. It’s both encouraging and reassuring. The fact that he is asking questions makes me feel more comfortable to ask questions even if I think they might be dumb ones.
I sometimes feel like a burden with all my questions but the flipside is spending a day and some of a weekend on an issue that a co-worker helped me resolve within 15 minutes. This happened and I felt like an idiot for not seeking help sooner. So make sure to ask!
Don’t suffer in silence or put on a brave face. It’s inefficient and wastes not only the company’s time, but yours too.
How to do this
- Google exists and will always be your best friend. There’s no shortage of resources and answers to most of your questions so always do a bit of research on your issue before bugging a co-worker.
- If this doesn’t work, ask your co-workers. They have specific experience with their stack and code base so, especially when starting out, you’re likely to run into issues or snags that they’re familiar with.
You need to listen, learn, lepidopterology
I’m a bit of a wallflower and generally a good listener so, especially in a small office environment, I overhear a lot. As a QA engineer, I’m also perfectly positioned to see how my co-workers have solved certain problems or implemented certain features and can learn a great deal from this.
Most of your co-workers will have more experience than you. They’ll know little things, tips and tricks that won’t necessarily be readily apparent (or explained) in online tutorials and other such guides.
Oh, and what’s lepidopterology you might ask? The study of moths and butterflies, of course. It has absolutely no relevance here but it’s a fun word and now you’ve learnt at least one thing.
How to do this
- Let your co-workers teach you both actively and passively. Observe how they do things and ask questions about their processes or why they use certain functions/methods instead of others if they’re amenable to that.
The subtle method of passively learning from other people is an underappreciated one.
Through this approach, you can learn things from those around you that are so minute or inconsequential to them that they may not even be aware of it as impartible knowledge.
Say ‘yes’ and show initiative
It’s understandable to be a little apprehensive about taking on new challenges and potentially biting off more than you can chew.
However, knowing your limits and having a good sense of your boundaries makes it easy to take on just enough to maintain a certain momentum.
If you branched off into software for growth and experience then it goes without saying that those things won’t just come to you, you have to keep yourself open to accept them.
How to do this
- Ask if there’s something in the pipeline you can start laying the groundwork for. Now that you’re in a defined environment with a specific stack, you can dive back into skill development and learning with a more laser focus, especially if the team is looking to implement some new tech or add new features which they’ve never worked with before. Use this as your chance to step up.
- More importantly, say ‘yes’. Don’t take on more than you can handle but don’t be afraid to take on new challenges or imposing tasks either. It may necessitate constantly bugging more senior team members but accomplishing those tasks is how you prove yourself and build confidence.
- If you feel like you’re not being given enough to do, don’t wait for someone to notice. Either speak up or find something you can help with.
After reading this, I hope you have a clearer idea of how to transition from your current field into software and make a success of yourself. It’s hardly an anomalous phenomenon either, plenty of people do it. It happens often enough that many companies have handled at least one transition like this so you won’t be their first or their last. In fact, when another newbie comes wandering in from engineering or commerce, you can be there to guide them.
Resources
There is absolutely no shortage of resources for learning to code, that cater to any area of interest or budget. I’ve specifically been partial to Codecademy for broad spectrum learning but if you’ve got the budget, then Udemy does fantastic courses too.
Of course, many specialised frameworks and languages such as React Native have very comprehensive tutorials on their sites that you’ll find yourself going back to as you get to grips with them. What matters is your approach. Figure out what you need or want to do, break it down into components and find tutorials for each of those. For daily learning or inspiration, hubs such as Medium are excellent.
AG Sonday is a human (mostly) and an engineer (entirely). He currently works as a QA engineer and front-end developer at Pineapple, a multi-award winning insure-tech startup. He believes that learning is a never-ending pursuit which fuels lifelong growth. For more info or to get in touch, you can find him on LinkedIn.
