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 a little about both! And this confusion 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 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 directly.

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. Architects are typically generalists and the course teaches lots of things which I think suits my learning style more than learning one thing very specifically.

Architecture 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 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 Nihongo Life with my Japanese tutor. I realise this is a huge project, and it took (2-ish) years of extra time on evenings and weekends.

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 (I later learned called a View and conventions be dammed. I didn't learn the Model View Controller architecture until way, way later.), 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.

Soon, 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. 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. Likewise, 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, and the CTO obviously knew this so I couldn't fib) 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. Yet.

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. The module was about digital design in architecture. I made it my own and coded a prototype app while my classmates did grasshopper. It's much easier than trying to also build something from scratch if you can roll an existing project into your bag.

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 10 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 on top of their lives. After talking with my managers, it feels like what they've appreciated is a leaning mindset, and I've asked what they think was useful in order to get me there. 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. It's a whole thing in software engineering called pair programming.