Why I learnt to code, and so should you

From Architect to Builder — a former VC, second time startup founder finally starts coding

I thought I was pretty technical… After finishing a degree in Astrophysics I’ve spent my career on the “business” side. During this time I’ve advised companies on product roadmaps, technology trends and managed a team to integrate a banking platform into M-PESA (a mobile payment project). All without knowing how to code.

After this I worked for a great VC fund founded by entrepreneurs, sourcing and doing due diligence on early stage technology companies. I was asking PhD computer scientist founders about their blah algorithms (the blah is for confidentiality and not meant to trivialise… I saw some great tech). I could hold my own in some pretty tech-ie discussions but I’d never written a line of code in my life (things had moved on from the BASIC I learnt as a child).

I think being just technical enough was both a blessing and a curse — I could understand architectural / algorithm discussions because of my analytical background but had never been ‘on the ground’ to see the challenges and practicalities of implementing.

Then a few years ago I co-founded a tech start-up and theory was turning into practice. I was lucky in that I had a great technical co-founder who was very commercial. He was going to manage the tech build and I was going to do “everything else”. Here I started to learn how to write SQL queries as my technical co-founder got fed up of me asking for analytics data. The ability to get information out of the system was the beginning of my enlightenment. But I still couldn’t directly change the product I was building.

Coding distributes responsibility and speeds up innovation

I’d always wanted to learn to code and after a few false starts I’ve managed to make some time to do it… more importantly, I’m fortunately in a role where I could put theory into practice. After just a few months I think anyone involved in early stage tech start-ups should do some level of coding… Here’s why:

• Startup employees / founders need to be generalists with an area of focus i.e. a designer who can code front end or a marketing person who can edit some HTML. Specialising is ok for large companies where there is scale but there are too many roles and not enough heads in a startup to specialise
• Distracting developers is frustrating for both parties. Simple things like copy changes or minor visual bugs are annoying when you find them… and (usually) easily fixable. Fixing it when you find it means you don’t have to distract someone else and everyone can own the product
• Iteration speed slows down. If everything has to be logged and passed to developers there is an overhead added to the innovation process
• Empathy and team work. If you’ve never written code, then you don’t understand what some of your team members actually do… this can make it hard to understand how long things take. It also means collaboration and communication can be more difficult between technical and non-technical team members. This also works the other way — technical team members should also have an understanding of non-technical roles such as marketing.

Now for the practical bit

The last couple of times I tried to learnt to code I was given a link to w3.org reference site and a book. This ‘read-only’ process for education / learning I think is quite difficult from a standing start. It’s better for building on experience. Fortunately things had moved on since then and online learning platforms and Massive Open Online Courses (MOOCs) had become more popular. Established educational institutions such as Stanford and new platforms such as Cousera had opened up education — online video and interactive tutorials mimicked the classroom interaction much better. Small chunks of information, with quizzes to test progress and online forums to interact with peers.

Here’s a summary of the courses I took at during weekends and evenings:

• Udacity — Computer Science. Great intro to concepts and Python. I started here as I had CS friends at Uni and everyone talks about CS grads… It laid a great foundation
• Coursera — Startup engineering. This was a really good course covering all the bases from startup ideas through to Git version control, command line, HMTL and cloud computing. This had a tight schedule that I couldn’t stick with but the material is online after the course officially finished
• Codeacademy — Javascript, HTML, CSS, jQuery. There were great simple courses for front-end development. Doing the Udacity course made these quite easy but has probably been the most practical course with it’s interactive tutorials. This didn’t use video but the game like mechanics kept with very engaging.

Practice makes better (not perfect)

As soon as you’ve got a basic bit of knowledge start putting it into practice. A lot of people try building their own projects, which is one approach. However, I found a blank piece of paper is quite hard to start with. I’d recommend going to someone in your tech team to see if you can get access to parts of the code — you’ll learn a lot by reading other peoples code, and as it’ll be for a product you should know so you can piece it together more easily. Once you’re ready you can start making small changes — your team should have processes in place to mean it’s quite difficult to break anything, but check first. One of the easiest things to do is make copy and layout changes — this might even just be for an email newsletter.

I’ve found practicing with a live product to be much more effective, and hopefully before too long you will be able to help your technical team reduce their workload. Working on a live product will also introduce you to best practices that are hard to learn in tutorials…

What now?

I’ve now written code in three projects focussing mainly on front-end HTML, CSS and Javascript — but with AngularJS this has meant real ‘functionality’. I’m never going to be full time developer but going through this process has been extremely satisfying and hopefully helpful to my team! I’m definitely going to keep it up — even if it sometimes spending hours debugging CSS! My advice to anyone learning is to find a mentor and get started today!

Thanks to @lpsoltys for his patience and @glennawalker for allowing me to ruin his designs!