Change of Plans: Self-teaching my Way from Architecture to an IT Career

Ever since I decided to pursue an IT career, my life has been plagued by a single question: why not Architecture? Having had to answer this question more times than I could stand, I grew to embrace the fact that it's a part of my life. And even get to write an article about it!

But before I start, I would like to make a distinction: when I say Architecture, I refer to the actual stuff of buildings, those that are made of concrete and/or brick,  not to be confused with Software (or Hardware) architecture.

architecture

noun

ar·chi·tec·ture | \ˈär-kə-ˌtek-chər\

1

: the art or science of building specifically : the art or practice of designing and building structures and especially habitable ones

Source: Merriam-Webster Online Dictionary

Here is what I am going to address:

1. Why (not) Architecture?
2. Architecture vs. Software development
3. It's a journey
4. My 7 steps to becoming a self-taught programmer
5. Destination reached
6. Let's talk resumés
7. Recap (includes links to all resources mentioned in the article)

Why (not) Architecture?

First of all, why did I choose Architecture in the first place?

1. I was fairly skilled at drawing and the admission contest at any Architecture college in Romania is a drawing exam.
2. I was advised by my peers and professors to pursue a career in Architecture with promises of social reputation and financial benefits.

As I was going to find out later, these were all just hollow promises that stem from the lack of understanding of what is the role of an architect in our modern society and the answer is just as elusive.

In spite of spending six years for a degree I am currently not building on, I still acquired an invaluable skill: learning and (re)searching by myself. This came in particularly handy on my path as an Architecture graduate turned self-taught programmer (not that this is breaking news, but being able to constantly learn is the most important skill to have in today's software development landscape, as this article will also tell you).

Architecture vs Software development

If you started reading about Software development (as I did in my early stages of exploring my switch to an IT career), you would get overwhelmed very easily and very fast. But let me show you how Software development is not such a daunting concept to grasp. Let's dive into a bit of visualisation that involves Architecture.

Imagine four simple orthogonal walls, a floor and a roof (basically a box). Can I call this object a room, in the traditional sense? Actually, no, because there is no door, thus no person can enter it and use it. Now, after we've added a door to our box, I am gonna pose another question: can I call it a kitchen? Obviously, I can not. Why? Because a person would not be able to cook in such a space. In other words, just like the type of a room is defined by its functional necessities¹, software can also be defined by the function it fulfils² (e.g. if it works like a shop, it is an e-commerce app).

I believe that is why they are so similar: the main concern of both of these areas of expertise is transposing a flow of information/data/actions into something that a person can interact with.

Also, both have complex infrastructures that need to support the visible part of the project.

I could even suggest that they have similar degrees of complexity.

I would love to continue talking about the differences and similarities between Architecture and Software, but this is not the time, nor the medium. If you wish to engage in a discussion about this topic, I am always glad to talk about it. My email address is alexandru.voica@around25.com

It's a journey

What was clear to me from the beginning was that this endeavor of changing my career was going to be a journey. There were going to be:

• ups and downs;
• steps that I need to take;
• moments of disappointment;
• also moments of joy.

Thus, I set out with few expectations, no deadline and no hard commitments (which I highly encourage you to do as well).

Right as I was starting to scour the Internet for places to learn from, I stumbled upon a huge morale boost from this Stackoverflow report about the state of the software developer community in 2018. This is how I learned that a significant portion of the developers who answered are self-taught. I believe this is an important piece of information for any person willing to undertake a similar journey to mine in this dynamic environment that is the Software development landscape.

This was all the information I needed to transform my anxieties into excitement: I was ready to start! And as you surely know, every journey starts with a first step...

My 7 steps to becoming a self-taught programmer

Step 1: Get down to basics

So, with no plan in mind I set out to explore the vast Internet for a source to start acquiring the necessary knowledge to become a Software developer. As with any kind of research that I do, I start with the very theoretical basics, and thus I found CS50, an introductory (video recorded) course into Computer Science from Harvard. I cannot emphasise enough the richness of this course.

Then there was David Malan's course covering multiple programming languages (C, Python, Javascript etc.) and multiple programming concepts (memory allocation, sorting algorithms etc.), in a method that is friendly to grasshoppers (a.k.a. newbies), like myself at the time.

Step 2: Start coding

All while grasping the theoretical aspects of Computer Science, I started learning some hard technical skills using freeCodeCamp.

This is a solid source for step-by-step tutorials and it makes learning much comfortable for a complete beginner. The range of subjects covered is of considerable size, covering everything Frontend to everything Backend. Plus, they are neatly organised into certifications (or paths, in layman's terms).

The only caveat is that the entire curriculum is Javascript only, so that means you only get accustomed to a single programming language. I also need to add that this resource has been updated constantly and suffered a major restructuring over the last year, which means that in the future it may even be expanded to incorporate other programming languages as well.

Step 3: Push ahead

Next up: Udacity.

There are two ways you can use this resource:

1. Going through any of the free courses they offer. I personally enjoyed them because they are a mixture of video lessons, input exercises and freeform projects ³ and the range of subjects is pretty wide.
2. Using Udacity to receive a scholarship: each year around November they put out an offer for a free two-phase scholarship in partnership with Google. Anybody can sign up to exploit this offer, but there is a limited number of people that they actually accept, albeit large for the first phase (20 000 students). With this scholarship, they offer access to some paid-entry courses and projects, organised into a much cleaner path.

I had the chance to get a Udacity scholarship and completing half of it (I did not get into the second phase) made me realise I appreciate working on the Frontend much more, because of its dialogue between technical and visual, which blended nicely with my previous training in Architecture.

Step 4: Now stick to it

After finishing the CS50 lessons, completing a chunk of the freeCodeCamp courses and exhausting the Udacity scholarship material, I was feeling excited about increasing the amount of coding I did every day. Thus I found the #100DaysOfCode challenge, which is aimed at people that were undertaking the same journey as I was: trying to get (even more) comfortable with coding.

The gist of the challenge is getting to know code versioning tools (like Git) and enforcing yourself to making one commit per day. Don't worry if you don't understand what you just read there, I promise you will eventually.

Step 5: Don't get stuck

Believe me when I say you will never feel ready, you will never feel like you know enough, no matter how many courses or tutorials you complete. This feeling will make you believe you have to complete tutorial after tutorial. That is also known, in colloquial terms, as the tutorial limbo. If you find yourself stuck in this way, you need to acknowledge it and break the cycle.

And this leads us to the next step I took: applying for internships.

Step 6: Put yourself out there...

In spite of all those pesky feelings like anxiety and uncertainty ("Oh, I'm not ready", "Oh, what if I do a blunder?" and so on), I still tried to apply for internships wherever I could. I was filtering the ads from different companies only by programming language, being on the lookout for the Javascript-based ones. I was determined on focusing on Web Frontend.

And this is the best moment to talk about an irksome aspect of internship hunting: you need to send them a resumé. Believe me, nobody likes to be reduced to a few pages of text, but in this day and age of speed, it is a necessity. What I want to mention here is the importance of owning that resumé.

Ok, so you've sent an application to every mildly-interesting internship offer out there. Now what?

• One possibility is being called for an interview.
• The other more common possibility is being rejected.

... and remember: rejection is your best friend

I need to emphasise here that rejection is normal. Acknowledging this is possibly the best mental defence you can have. Getting discouraged at this point is going to help nobody, especially yourself. So, keep your chin up and carry on my wayward son .

In my case, I got rejected on more than several occasions. I was surprised I sometimes got to the technical interview because of my different background (yes, I was outright rejected more than once because my lack of a computer science degree).

The important takeaway here is that applying for internships lets you get a pulse of what is the market moving towards. For example, in 2018 the most sought-after tech job was related to big data. In 2019, it's all about cybersecurity.

Extra: Practice, practice, practice

While waiting for those calls that land you an interview, I recommend learning some more and practicing even more.

During an application process I was participating in for an internship, I had to solve some algorithm exercises in a certain amount of time, thus I was introduced to Leetcode, where such exercises are abundant and are sorted by multiple criteria, including difficulty.

The coolest feature is that you have the option of giving a solution in a programming language that you prefer. The list includes all the major popular ones like Javascript, Python, C and even Ruby, Go and Rust!

At some point, you are going to realise how the finished courses have begun piling up and how comfortable you feel coding right in this moment. In other words, you will get into this fuzzy and warm state where getting better is the most important objective for you and you barely notice agreeing to a technical interview amidst the frenetic acquiring of knowledge.

And then... it hits you!

Step 7: The actual stuff...

Fast-forward a few days later and you find yourself in the interview room with a few people that you have never seen before, but you know they are judging you. No, no, I'm just kidding.

There is no point in giving you a step-by-step recipe on what to do during the interview, because:

1. You can find a myriad of resources on this topic out there, to the point of nausea, in my opinion.
2. Every company has their own way of conducting these interviews, thus there is no point in being given universal advice.

The only thing I feel I need to emphasise here is this:

Don't be scared. You have no reason to. You have nothing to lose.

... and the actual internship

Let me just say from the beginning: it's not going to be easy.

You might be inclined to think that the internship is just a learning process akin to the one you've been doing up until this point.

Let me stop you right there. It will not.

It is going to be gruesome, brutal and painful. But also enlightening, relieving and, possibly, even fun.

That's how I would describe the internship I had at Around25. No, wait, I actually did.

No matter what kind of expletives you are going to use to describe your experience later, if you stick with it, you are going to finish it anyway.

Now what?

IT Career. Destination reached (?)

I am going to be blunt with you: there is no destination. Well, technically speaking, the undertaking you've committed yourself to might have come to a conclusion (you finishing the internship) akin to reaching a destination, but the actual journey will never be over.

You might find yourself in the position of being offered a job because of your hard work up until this point and you might think you've finally made it, but this is just the beginning of yet another journey.

One that we'll maybe talk about in another piece...

Bye. 👋

Recap

Pfew. Now that was a lot of information and I'm sure you're probably slightly overwhelmed. Before moving on, let me try to organize all of the resources I mentioned in a neat list so you don't have to.

You're welcome.

And as I mentioned somewhere above, I can be found via mail for any questions, rants or further recommendations.

Hope you find your way to the IT career you deserve.

1. The hypothesis that a room should be defined by its function is just one architectural theory. I did not go into further detail, because this is not the proper time or medium to start an architectural theory crash course. I chose to base my thought experiment around this theory because it is the most popular and easy to understand.
2. I am aware that there is a lot of grey area here that can be explored.
3. A freeform project is one in which the student is given a set of requirements or problems with a much broader scope, that they need to solve. This is opposed to the step-by-step tutorial projects, where requirements/problems are defined as atomically as possible. This type is more widespread, but less valuable in terms of learning.