A few unformed notes on learning to build software

In the middle of December, I left my role as VP Product at Noodle so that I could focus on learning to build things for the web and other communication networks. My words here are deliberate, I don’t think of it as learning how to code; I had done front end development, deployed production code, built internal dashboards, dabbled with Python scripts, and knew how to write SQL to analyze data.

However, I didn’t know how to build things — let alone from scratch. If I had an idea, a prototype was either a painful week(s) away or I had to convince someone else to help me. This skill-set worked, but it had flaws and I felt I’d lose too much to the friction of either approach — how would I carve out the time to work on a prototype or side project ,on top of my own work, or when was it ok to convince someone else to change direction to test out something that I only had conviction about.

I set out to remove this friction and get a deeper understanding of code, software, and where they come from. I’m about a month into spending most my time on this. A few notes and thoughts:

  • I opted to go it on my own and not participate in a coding bootcamp. I wasn’t looking to “learn to code” nor was I looking to learn what it took to put an idea together: I was specifically looking to learn to build something, for the and of the Internet, on my own. There are huge downsides here, I had to design my own curriculum and keep myself accountable.
  • To start, I felt I needed better fundamentals. I have never studied computer science in an academic setting. Object oriented programming was not something I grasped. I’d never written java, objective-c, C, etc. Thus, I started with some Stanford CS courses. This was fun, and valuable, but only for a bit.
  • Originally, my plan was to go through a few OOP courses and also learn Swift so that I could work on iOS. Then I would just pick a few projects to work on. However, I was not engaged with the courses so two weeks ago I dropped the Swift stuff and the java course I was currently in and just started working on something I thought would be interesting. This was critical — yes it was a pain in the ass and my code is terrible and I’m googling things constantly, but I have a clear objective, I’m building for me so the feedback loop is small (unfortunately, quite the opposite on the quality of the software, more on this later), and I’m very excited.
  • I knew going in that once I moved to projects, I shouldn’t treat any as sacred, let alone with much structure. That is, the objective is to learn, not launch anything (at least not yet). So I put my first thing down after a week to jump into another idea (it relies on similar technology: SMS messaging, NLP, chat based UIs (I’m drafting another post about working with these trends)). Next week, I might drop this too for something completely different, maybe finally picking up swift (for most of February, I’ve been working in Python).
  • It’s critical, for me, to have people to guide you and point you in the right direction. Learning to build in a vacuum, which I did for about a week, was painstaking and inefficient. I’m now far enough along where I can bug various people for code reviews and this has catalyzed a whole new chapter of learning. If you don’t have people that can consult like this, try to put yourself in an environment where this may happen by chance.
  • When starting, just pick a language. Probably something forward looking with some flexibility. Python is a good choice, so is JavaScript. So is Java, and there are probably others. The point is not the analyze, but to act (and, on a meta level, for me, this whole period was about learning to value creation over analysis and learn to do both). With regards to a framework, the same holds — just pick one and go through the tutorial and documentation. Work with it until you know why you should try another. People will tell you the merits of each, and they do have positives and negatives, but that’s not the point . Starting, rather than stopping to analyze, is better for your journey. The one caveat here: pick a framework that comes with an easy to use database if you’re not familiar with this stuff.
  • Knowing how to Google, as always, is critical.
  • If you can get your family on board (and this may be harder in certain cases), don’t worry what other people think. Most my friends were pretty confused by what I was doing (and, to be honest, I was at times too). But if you feel like you’re making progress, and can afford the time off, then things are OK.
  • I’m keeping a changelog. I’d seen this mentioned by a number of people that had talked about learning a new thing or building something and I’m convinced it’s invaluable. You get excited to make your changelog entry for a day of work and you can reflect on just how much progress you’re making while collecting your thoughts around next steps.
  • I had to take the time to read documentation and do tutorials. I still find myself going through even basic tutorials, like using APIS in Python via Codecademy, to refresh myself before working on code that plays in these areas. I’m sure there are people out there that can dive right in. I’m not one of them.
  • Rituals are helpful. I got myself out of NYC (where I was living) into the Catskill Mountains. I’d wake up at the same time, have breakfast right away, walk the dog, make coffee, get started. Lunch was at the same time. A workout break was always in the late afternoon. Dinner around 7:30 followed by a couple more hours. If I needed a break ever, I’d go for a walk or check Twitter. This helped me have a rhythm that I kept to as I avoided distractions (albeit there are less when you are by yourself in the middle of the Catskills — as always, environment is key).