Software Engineering Recruiter to a Software Engineer: failing my way into a new career
TLDR AT THE BOTTOM
whoami
I, Benjamin Collingwood, am a Software Engineer. This is surreal for me to write. Software Engineering is my second career. I have spent the last eight years or so working my way through the three states of being for a Recruiter: recruitment consultancy within a modest tech focused recruitment business; an internal/corporate recruiter within a financial services business and self-employed as a day rated internal recruiter/organisational designer.
Now… I’m a Software Engineer! (Yep, it’s still bizarre.)
The journey of Ben Collingwood, Recruiter becoming Ben Collingwood, Software Engineer is a story of failing, failing, failing, and then, as if by magic… success!
The intended audience for this post is:
First, to give advice to anyone about to embark or considering starting on a similar path mine. Some of the experiences and techniques I used to get here are specific to development, however many of them are transferable to anyone considering embarking on a career change. This is guide retrospectively about what I would do if I had to do this all over again.
Second, for anyone that is passionate about continued learning. I hope that my openness and honesty regarding the frustrations of learning something, anything, new will give you some comfort that you are not alone. I will also include some practical techniques that I practised along the way. I hope these will provide value but, at the very least, spark a conversation about how they can be improved to add value to others.
Let’s get started with the hardest step I took… the first one.
Start with Why
Those of you familiar with the work of Simon Sinek will be familiar with this concept. However, even though I had read Simon’s book (Start with Why) the initial failure in my journey was the first step. I started with not really understanding why I wanted to do it. Throughout my recruitment career I said things like “Oh if I had my time again, I’d be a software engineer.” Which, in retrospect, seems like an odd thing for a twenty-something-year-old to say. However, I’d never got it clear in my mind why I maintained a desire to perform this as a career.
Why start with why?
I’m not going to lie; this journey is laborious, long and, at times, frustrating. Over that last eight years I had dozens of false starts on this journey, rationalising to myself that “It just wasn’t the right time” or “I don’t have the time to focus on this right now.” Your why is your motivation, your drive, it’s your reason for taking that next step. For sitting at your computer and coding instead of watching TV, playing that new game or whatever. So, my advice, for what it’s worth, is to do some deep introspection about why you want to achieve this.
My why
I hesitated to write about the reasons I was motivated to learn to code. I don’t want you to think these are the only reasons or motivations for it. Your “Why” maybe completely different but make sure you are honest about it with yourself.
Majority Positive
In recruitment, I enjoyed deep diving into a hiring managers recruitment problem and coming up with potential solutions then building a plan to execute that solution however, I had neutral feelings towards the grunt work of calling, messaging, reading of CVs, etc. Note I say neutral feelings, neither positive nor negative. Breaking that down I realised I spent 10% of my time enjoying what I did, 85% feeling pretty meh and 5% of my not enjoying what I was doing. Net positive, but not overwhelmingly positive. So, I started thinking about what it is I really liked about that 10% which can be summed up as: problem solving and creative output.
Problem solving is pretty self-explanatory, but it’s important to note I enjoy the activity of solving problems, not just the end result. Sure, the payoff once it’s solved is great, but I love getting lost in a problem.
Creative output is more nebulous. I’d summarise it as making something that adds value or is valued by others. This is critical to me. Once more, I actively enjoy the activity in the moment of contributing and leaving a positive mark on something.
I realised that these two areas were concentrated in the work of a software engineer. I’m only two months into my new career and I can feel my thirst for problem solving and creative output being quenched.
Pride/Status
This is the thing that cringe at. I like thinking of myself as independent and rational about all things but I’m not. If I’m really honest with myself, I want people to be impressed by me. I wanted to have pride when I told people what I did for a living. Now I’m not naive enough to believe that when I say I’m a Software Engineer everyone is going to think “Wow how interesting!” but within my family and my friendship group software engineering is a high-status job. That’s why I have been enormously proud of my journey so far, and I think it’s essential to be honest with yourself about these things.
Validate
Right, first step complete, you possess your “why”.
Now it’s time to validate that your why matches the reality of where it is you are aiming to be. I didn’t do this at the time and there was an underlying subconscious concern about the assumptions that I made about a software engineering career. If I had to do this again, I would reach out to many people that work in software engineering and ask some pointed questions, such as:
“I really enjoy solving problems, how much time as a percentage would you say you spend solving problems?”
This inspires confidence that you are making the right decision and will bolster your motivation in the hard journey ahead.
Learning Plan
So, you have decided to do this! I thoroughly recommend making a learning plan. Don’t fritter away too much time on this step. Keep it rough, loose and easily changeable. During my learning journey I constantly felt that every course I took was like pushing open a door to a room with a hundred more doors. I wanted to understand everything behind those doors, but it can become overwhelming. A loose learning plan allows you to focus on a goal without being overloaded by the differing routes to follow. Alternatively, being too focused and can mean you miss out on directions that would be better for you to go.
A Rough Heading
Most importantly you need a rough learning aim. I had an overall aim: get a job as a software engineer. However, that cat can be skinned in many ways. If you try to be strong everywhere, you end up being weak everywhere and other pithy phrases of the sort. The advice I was offered at the time that has served me very well is this:
Get to the point you can make something useful as fast as possible.
This was important for me given my why. It would allow me to combat problems, get my creative output fix and add to a portfolio of work as quickly as possible. This, therefore, was the undercurrent of what I learnt and how I assimilated it.
With this in mind I started learning JavaScript. With Node and a framework, I could make something recognisable not only to technical people but also my friends and family.
Atomic Learning
As I mentioned, I experienced many false starts in learning to code. The primary reason I kept failing is I set out to learn a language. If you are saying to yourself “Ben that’s kind of the point! Learning to code!” I agree with you completely but conceptualising learning a whole language in one go is like climbing Everest in a day. I needed to divide it into smaller parts. This will give you small easily achievable goals that you can complete every day.
Following the trend of appropriating ideas from books that I read and enjoyed, this is plagiarised from Brad Frost’s Atomic Design. Atomic design includes three categories or gradations for elements of a website or product: Atoms, Molecules and Organisms. To not go too deep on atomic design what you need to grasp is that:
Atoms make Molecules that make Organisms.
How I used these categories in my learning journey is creating a learning chart and breaking down my goals into these categories. I used my note app on Mac for this at first then changed this to a wipe board.
Starting with the Organism of JavaScript I separated that in into molecules:
- Vanilla (basic JavaScript)
- A Framework (I picked React pretty much at random.)
- Node (Backend JavaScript)
From the Molecule of Vanilla, I broke that down into Atoms:
- Variables
- Datatypes
- Functions
- …
Every time something was mentioned that I didn’t know I’d add it as an Atom. If I realised that subject was had multiple components that I couldn’t understand in a day I would reclassify upwards to a molecule or even an Organism. I did this with React; it was an Organism it led to me to the molecule of Redux, Redux turned about to be a beast, so I reclassified as an Organism and added Reducers, Store etc. as Atoms. Once I achieved a level of understanding of something I’d tick it off the list.
Validate
I regularly validated my learning plan with people in the industry. Dropped people a message along the lines of “What do I need to learn to get a job as a software engineer?” or “I’m going learning X what you think?” and often I’d get a “Learn X first” or something or a look into this course, resource or medium post.
Time Commitment
This is likely the most valuable advice I can offer:
Commit to learning every day.
This is something that did from the beginning that really helped. Every morning I would set a time that I was committed to start and finish some focused learning. At the start, I did an hour and half after work and one full morning at the weekend. As I got more and more interested and confident, I increased that but, I coded every day.
Aim to get 1% better every day. I recommend James Clear on this https://jamesclear.com/continuous-improvement and his book Atomic Habits (There are those atoms again.)
Tell Others
Make sure you can keep your learning time as distraction free as possible by letting those you live with what you are doing and why.
Enough with the theory!
When starting to learn to code you are typically faced with two options, coding bootcamps or self-taught. I’m a huge advocate for coding bootcamps. I recruited apprentices from them when I was in recruitment and think they are a great entry to the market. However, I set out on this journey in March of 2020. Given the situation at the time the local bootcamps pressed pause on their intakes.
Consequently, I was going it alone.
Code Courses
Online coding courses are great. I reached out to loads of people and asked for their opinions on what courses to buy. When first starting out my advice is to seek courses that match the Organisms in your learning plan. These courses are usually vast (many are 40–50 hours of lectures.) I was initially intimidated by the length of these and started with smaller more targeted courses or videos. This was a grave mistake. I discovered myself having to stop and add more and more Atoms to the list as that video required knowledge that I didn’t have. I was wasting my learning time searching for small videos rather than actually learning concepts and coding. Here are the pros and cons of longer video courses:
Pros:
- Someone else has curated the learning journey stopping you wasting time doing it.
- You don’t have to constantly go over old ground.
- You don’t know what you don’t know. The course will introduce you to things in a logical order.
- Projects! I do not understand a concept until you have put it into practice myself.
- Good projects are pre-Atomised making it easier to add to your Learning chart.
Cons:
- They cost money.
- If you don’t like the teaching style, you have to switch onto another course.
With that being said, here’s my learning journey in courses:
- Wes Bos — Beginner JavaScript — https://beginnerjavascript.com/
- Andrew Mead — The Complete Node.js Developer Course — Udemy
- Maximilian Schwarzmüller— React — The Complete Guide — Udemy
- Maximilian Schwarzmüller — Redux — LinkedIn Learning
After you have completed a course, you will have what I dubbed course fatigue. I utilised my learning time to actually build something practising the skills I had gained in the course. With these courses being broken down into sections and lectures, it made it easy to revisit a subject to help with my project. These personal projects also constitute your portfolio, evidence that you grasp the subject when you come to applying and interviewing for roles.
Next, speak to engineers in the industry about your projects. I’d ask them how I could improve it. “What areas am I missing?” “How would you improve it?” This will provide to you a guide of what course to pick next, what Atoms or molecules are missing from the course that you need to focus on. In my case, after the React course people mentioned Redux and Testing. Consequently, I added them both as Materials to my learning chart and started courses on them.
EOF
That’s it! I hope you enjoyed or have taken something from this post. I’m really interested in hearing about your learning journeys or ways of improving my learning techniques. I’m still committed to being at least 1% better every day. If you have questions or suggestions or just want a chat, please drop me a message I’d love to hear from you!
TLDR
- I was a Tech Recruiter that became a Software Engineer in less than a year
- How I would do it if I had to do it over again:
- Be clear on why I wanted to do it
- Create a learning plan
- Have a learning goal
- Validate what you are learning will land you a job.
- Break down your goal into really small chunks.
- Learning time needs to be undistracted, focused on a small topic and done every day.
