Observations from the Summit of my First Development Project

Christmas 2017, I made a bold decision to part ways with my nonsense about not having enough time to pursue my interest in programming.

I had previously dabbled in different development languages, without really committing to any kind of progression or journey. That joyous sense of personal fulfilment upon learning a new skill was subsequently absent from most of my experience to date.

Learning to code is in part learning delayed gratification. In this sense defining goals and targets is important. Without something to aim for, programming can feel like an infinite iterative loop. A tangible output feels necessary to the learning process. Similarly it provides a critical framework in which we can review future iterations of the same type of work.

Defining mygoal

Of the three goals I defined for myself in 2018, learning to code was the one I struggled to create milestones for. It’s very difficult to create goals within a discipline you haven’t enough prerequisite knowledge to fully understand yet.

After some debate and consultation with others embarking on the same journey, I decided to create a simple static personal web portfolio using HTML, CSS and some JS. The end goal wasn’t to have a beautiful portfolio but rather a vessel I could channel the skills I was learning. A way I could apply what I had learnt to a real world problem.

Ideally the project would be finished by the end of Q1.

Spoiler alert: I missed this deadline by 2 months.

Getting started

For a beginner, programming can seem overwhelming. The more you learn, the more you realise how little you know but without ever really knowing what it is you’re yet to know. You just have a haunting sense that you’re missing a huge piece of logic that everyone else just gets. The fear of not knowing something that might be vital to succeed is very, very real.

So much so, I began with the familiar. I designed and prototyped my portfolio using a combination of Sketch and Marvel. I really enjoyed getting creative, and went through many iterations of colour combinations, layouts and content. By the time I emerged I’d almost forgotten my end goal but had experienced a harsh moment of personal clarity. I am not a designer.

But I am a perfectionist. I believe in taking pride in all work I do and this immediately became a problem for me. I had to wrestle to lower my own expectations so I would have a chance of succeeding.

To mentally move past this, I stripped the design down to a simple one pager — it was to have a header with my name, a tagline, a sub-tagline and some icons in the footer.

Simple one-pagedesign

The next step was to markup in HTML and style in CSS. I had a bit of experience with both languages from about 10 years ago so the concepts were fairly familiar but the syntax certainly needed some refreshing. Years of academic rigor and the love of constant learning meant that I embarked on this programming journey believing I already knew how I learnt best.

I therefore chose a mixture of Codecademy, w3schools and lots of reverse engineering in silence and solitude. I learnt early on that I needed to break what I had created, in order to really understand what I was doing. Naturally I spent a lot of time debugging and lurking on Stack Overflow threads. I also found it was this very activity that made programming so enjoyable!

Whilst solo learning is still vital if I am to make hefty strides forward in any subject matter, I can’t underplay the role initiatives like Codebar have had on some aspects of my learning and the importance they could have if attended regularly.

By attending a regular workshop, you create habit and pace. Throughout the project I have struggled with momentum. And in hindsight I think it’s key. I could have shipped the whole project within a month and probably deepened my knowledge significantly if only I had worked on the code regularly. Instead I spent 3 or 4 solo days spread out across 3 months, each session I had to untangle logic I’d made too long ago to remember my reasoning behind. Along with meetups/workshops, movements such as #100daysofcode are excellent to counteract this. They force you to keep the impetus going, even if you only find room to do a small amount each day.

To ship, or not toship

Initially I had wanted to deploy the static web page to a domain, and this is something I still might do in the future. But in the spirit of finishing the project, being scrappy over strategic, being able to write this blog post and being able to move on to learn something new, I settled with Github pages.

Github’s knowledge base is excellent, and it was a very smooth process. I am, of course, every developer’s worst nightmare. I committed on every code change, straight to master, without branching to test the code changes first and I didn’t leave comments about the changes I made. Resulting in 33 unknown commits. But hey, I’m still learning and I won’t make this mistake next time.

So without further delay and many iterations on my original design later, here is the finished portfolio.

It’s far from perfect, I will never be happy with the design (it’s like a 2006 pop punk throwback). But I’m pretty proud, not only did I self-teach from scratch but I also battled some personality traits to get this out. My goal was to create something I could channel my learning into, and I think I achieved this.

My process was messy; I reiterated, backtracked, scrapped and started from scratch over and over again. I learnt above and beyond what can be seen in this portfolio, and the biggest physical restriction was not technical understanding as I expected but rather indecision over content to include and overcoming my feelings of Imposter Syndrome. Besides self-promotion is always an uncomfortable subject, right?

In the last month or so, I delayed wrapping up the project. I was always holding out on improvements without taking any real decisive steps to do so. It was time to just release it, and knowing when the time is right on something you can iterate over and over is tricky, but I kept coming back to something a developer once said to me: “if in doubt reduce scope”. So I kept it simple and shipped.

Some afterthoughts

Learning to programme from an arts background is interesting, it’s not only learning a new skill but rather learning a new way of thinking and viewing a problem. If you were to hand me 1000+ complicated contradictory primary and secondary sources on any historic/arts discipline and ask me to produce an 80,000 word thesis, there would be no problem. My brain has been wired for this, it’s undaunting. I’m confident in my own thought processes and my ability to sift through large volumes of information, extract the importance, make thousands of connections and argue succinctly and well across 80k words.

Programming requires a rewire of the brain. You need to think like the code you are writing, in essence, you need to think in logic. The more languages encountered the more you realise logic is shared across them all. Professionally, I began with MySQL. It built upon an existing knowledge of datasets and an unhealthy love of spreadsheets and formulas. This was a great foundation for HTML, CSS and JS, I was already able to think like a developer.

Overall I have really enjoyed seeing the project coming together and learning new skills. So much so, I am eager to move on to my next one. I haven’t quite defined it yet but I suspect it will be around Python and using an API. Throughout the process I have encountered learning curves beyond the technical that I’ll definitely be applying to my next project.

Something that stands out and I wish I’d done more of is being honest about where I am struggling. It’s easy to feel like the questions we have as beginners are ridiculous and that we are wasting the time of busy engineers with questions which have obvious answers. Swallowing your pride and doing so is actually a really positive experience. For example, I was overjoyed to find out that collectively we all think responsiveness is a fiddly nightmare, and that most people hate Flexbox but see it’s value. In all seriousness, a simple conversation on the day I put the portfolio live resolved 2 issues that had plagued me for some time. If only I had done this sooner.

And to any developers who come across this: a concept you understand thoroughly, explained succinctly within the context of the beginner’s project is very powerful and motivational. It may seem small to you, you might not even remember having the conversation but the impact you might have to a starter’s understanding is huge — and trust me — we are all grateful for these moments.

I actually wasn’t sure whether I was going to write a blog post to accompany my first development project as I’ve read countless articles around a similar theme. But decided to go ahead in the hope I might be able to help someone else. I wanted to focus less on practical tricks and hacks related to the code within the project itself but rather place into words the feelings I’m sure are shared between many new programming beginners. I also wanted a way of tracking my learning and analysing in hindsight where I might improve in my next project.

I‘ve come to think of learning to programme as a metaphorical mountain. You really need to persevere with the long steep mental climb if you want to summit and bask in the glow of your own accomplishment. I’ve written a separate short article here, with some steps towards summiting your own personal mountain and reaching your coding goals.

Edit: a week after deploying the portfolio to Github Pages, I decided to go full hog, with a domain and an ssl certificate — https://sophiefitzpatrick.co.uk