Getting Started

I’ve been asked by friends and ex-colleagues of mine, about how I made the transition into tech. Specifically, software engineering, when my background isn’t in computer science, it’s in architecture.

The leap between the two fields has caused some confusion before! The architects think I’ve moved into structural engineering, and the software engineers thing I’ve come from software architecture. I know very little about both! And this genuinely happened at the beginning of a job interview. Thankfully it got a few laughs.

I want to go back a bit to before my undergraduate degree. I was always very interested in tech - my friends will attest to this - and I had already built a Hackintosh (a Mac from standard PC components) and a little bit of iOS coding back when it was Objective-C. It was an app I’d built for my friends to play on our shared Minecraft Server back in the day, which was hosted on an old iMac I’d moved downstairs to plug into the router.

Looking back, I’m glad I’ve not taken a computer science route. I was very fortunate to be able to take architecture and I learnt a lot from the experience. It ultimately led me to my first tech role at a startup. It was the first time I’d seen an architecture practice really lean into technology. The company had built their own customer management system (CRM) and project management software, and communication platform all rolled into one. I’m still in awe of it today!

During the interview process, I made it a point to see the CTO at the time. I wasn’t going to be offered a tech role straight away, but I thought it was a good start to appear on their radar. At the time, I was still very interested in the built environment and what it could teach me.

During these two years, I made sure to join what interdisciplinary meetings I could get into around my regular workload. Thankfully the tech team made the rounds between departments to solicit feedback from business users and via. us, our clients. What was working and what wasn’t, any bugs, pain points or process changes. It forced me to look at things through the eyes of who I was designing for as someone who delivered a product (architectural drawings) who also used our product (a tech platform) to deliver them.

Architecture is a portfolio-based interview process. So is software engineering! I needed to demonstrate I could code. And code something coherent. I had past knowledge of Objective-C. Which surprisingly did help a bit with the startup’s codebase. They used Ruby. Both Ruby and Objective-C are object-oriented languages. And iOS app wasn’t going to get me far here. So, I remember asking what software they used so I could have some time to build a project with similar things they used. Kindly, they gave my their Gemfile. The Gemfile in the Ruby ecosystem is really just a slightly fancy text file which lists all the third-part libraries they use. Objective-C had a Pods file which, I now realise is very similar under-the-hood. If you want to check it out, I ended up building <a href=”https://nihongo.life”>https://nihongo.life</a> with my Japanese tutor. I realise this is a huge project, and it took years of extra time on evenings and weekends.

There’s already some parallels to the languages I’d used before.

I realise that’s also skipping over a huge chunk. How the heck did I go about leaning my first programming language?

It’s because I had a problem. I wanted to check in on my gaming server when I was at school; when I had no laptop available.

This led me to a series of choices. The iPhone had just come out and apps were new! I downloaded a copy of Xcode. Created a default app. Plugged in my iPod Touch. And ran the project. It worked! I had a white screen. Not the most exciting. But from there, I learnt how to add a button, how to add another page (called a View), how to pass data between views, how to get data from a website. I’ve found generally, that breaking down tasks into about 2 hour chunks seems to strike the right balance to achieve something small. It might take a few more than 2 hours to get the first bit. Ticking off little milestones and seeing the progress was amazing. The feedback cycle is also so, so much faster than in architecture, where it can take weeks to revise drawings. Not to mention decades to build some buildings.

Taking advantage of pen and paper is useful in projects. It helps you to plan components in your build and how they might look on a screen. It’s a helpful way to capture what data you want to show or message you want to convey.

Then my company started hiring for more software engineers. I took some time to make sure my projects were working, and at least any bits that weren’t finished were hidden away. By the time I came to apply, I had been in my role for two years so I had the opportunity not just to know the CTO but my future teammates. I wrote a very custom cover letter addressed to them all and tailored my CV to explain how my projects were laid out. I found this type of résumé very helpful in the beginning as it was project based. Instead of listing out my work experience in software engineering (which was zero) it was more useful to list out some projects I’d built and add some screenshots. An additional advantage you have as an internal candidate - I had experience of the platform I was going to build for. I’d used it every day for my own work in architecture. I had ideas how to make it even better. Even if I didn’t have the skills to make that happen.

If someone is reading this, I realise you are unlikely working in a tech startup already. I believe the advice for project-based CVs and resumes still holds. After speaking with a few recruiters (much, much later) it’s surprising how many candidates they get across their desks do not have any built projects to show employers. I was a grad student. I get it. Uni is really stressful, and you’re already working on projects. It’s really hard to squeeze in some more. During my Masters’ I was able to polish off one of my module’s project work and put it on my CV. That is much easier than trying to also build something from scratch.

I didn’t go on a code bootcamp. I didn’t have the ability to take off time from work to dive into tech. Bootcamps are great places to build projects and teach you the foundations. The startup I was with liked Le Wagon alumni. The CTO however suggested I at least make my way through CodeCademy’s free Ruby track. It’s about 20 hours of programming (at the time of writing) which was more my speed since I could (sort-of) bash a project together and just needed to know the new syntax of the language.

Writing this does feel like I’m giving away the winning lotto ticket as I’ve cashed it in.

You’ll see a common theme with lots of ‘productivity porn’ posts. I’ve been through burnout and pushing yourself to complete your job, and extra projects on top is not something everyone can do. Or should want to do or strive to do. After talking with my managers, it feels like what they’ve appreciated is a leaning mindset. Understanding that you don’t know something and that you have the courage to ask for help. It’s a bit scary when you start out in a job, or ask in an interview. Usually the person interviewing will be a future colleague, they’ll have seen your work, understand that you’re new to it and help you out. Its a whole thing in software engineering called pair programming. I used to be terrified but now I find it really enjoyable.