In 2019, I continued to learn

Those close to me know that my motivation above all else is to learn.

It wasn't until at 20, around the time I began to learn to program, that I finally realised this and took the course "Learning How to Learn".

Fortunately, I chose to do something for a living that requires me to constantly learn; whether working on side projects, reading books and articles or taking part in an online course, developers must continuously seek out opportunities to learn.

This year I left my job because I didn't feel I was learning enough and took a 4 month break to learn skills that I could use to apply for other kinds of jobs. I didn't accomplish all of what I set out to, but I did take part in Startup School during which I continued to further my understanding of business and startups including how to validate and test ideas, talk to users and formulate my business pitch. But most importantly, I identified the need for a cofounder should I ever decide to start a company.

Something I hadn't realised when I wrote my original blog post on my experience in Startup School was that it helped me better understand my motivation to work and procrastinate less. Techniques like breaking larger problems into a set of smaller ones or minimising the obstacles to accomplishing a task were helpful in improving my productivity, but most useful was understanding that my desire to work was an average of all my motivations, both personal and professional. In 2020, I focus on discipline.

Reflecting on the months I spent out of full-time employment, I learned humility in the face of being rejected from some of the companies I'd wanted to work for. I learned about the importance of sleep and rest (and the link between sleep and stress) and about maintaining friendships.

This year I improved my fitness by learning how to run, pushing myself harder physically than ever before. I learned how to run over longer distances (taking part in the Bournemouth Half Marathon) by introducing intervals, tempo runs and sprints into my workouts. With fitness in mind, I also moderated my diet.

I was fortunate enough to be able to learn about other cultures through travel abroad. While in Florence I learned about the manufacture of parmiggiano reggiano cheese, making different types of pasta (and cooking other types of Italian food), Renaissance painting, sculpture and architecture (coincidentally I'm reading Walter Isaacson's Leonardo da Vinci biography currently) and winemaking in the Chianti region; In Lisbon with my family I learned about Portuguese food; In Amsterdam with friends I learned about how Heineken beer was made.

And finally, this year I continued to read. The books I most enjoyed this year were Donna Tart's "The Secret History" and "What You Do Is Who You Are" by Ben Horowitz, with "Only the Paranoid Survive" by Andy Grove getting a worthy mention.

In 2020 I hope to read more books, but even moreso I hope to continue to have intellectual curiosity and procure new skills and relationships.


Recently I re-read Sam Altman's "How to Be Successful" which he published earlier this year. It was one of the catalysts for leaving my last job (and taking my "sabbatical") and it's something I'd recommend to all (albeit with a pinch of salt).

Under the subheading "Have almost too much self belief", Altman writes:

"Self-belief is immensely powerful. The most successful people I know believe in themselves almost to the point of delusion.

Self-belief must be balanced with self-awareness. I used to hate criticism of any sort and actively avoided it. Now I try to always listen to it with the assumption that it’s true, and then decide if I want to act on it or not. Truth-seeking is hard and often painful, but it is what separates self-belief from self-delusion."

A quality you often hear entrepreneurs talk about is "grit". Where intelligence is largely determined by predetermined factors (genetics, opportunity etc) grit is one that can be learnt or acquired. The following are quotes from books, essays, talks etc around the theme of grit and self-determination.

In "The Anatomy of Determination", Paul Graham writes:

"Being strong-willed is not enough, however. You also have to be hard on yourself. Someone who was strong-willed but self-indulgent would not be called determined. Determination implies your wilfulness is balanced by discipline."

"[Determination] consists of willfulness balanced with discipline, aimed by ambition. And fortunately at least two of these three qualities can be cultivated. You may be able to increase your strength of will somewhat; you can definitely learn self-discipline; and almost everyone is practically malnourished when it comes to ambition."

In "What Goes Wrong", his wife Jessica Livingston says:
"Even though we usually use one word for it, determination is really two separate things: resilience and drive. Resilience keeps you from being pushed backwards. Drive moves you forwards. 

One reason you need resilience in a startup is that you are going to get rejected a lot. Even the most famous startups had surprising amounts of rejection early on."

In an episode of the "Masters of Scale" podcast, Reid Hoffman says:
"The sort of grit you need to scale a business is less reliant on brute force. It’s actually one part determination, one part ingenuity, and one part laziness... You want to minimise friction and find the most effective, most efficient way forward... So forget the tired cliche of running a marathon. You want to be more like Indiana Jones, somersaulting under blades, racing a few steps ahead of a rolling boulder and swinging your whip until you reach your holy grail."
Conversely, in "Grit: The power of passion and perseverance", Angela Lee Duckworth says:
" characteristic emerged as a significant predictor of success. And it wasn't social intelligence. It wasn't good looks, physical health, and it wasn't IQ. It was grit. Grit is passion and perseverance for very long-term goals. 

Grit is having stamina. Grit is sticking with your future, day in, day out, not just for the week, not just for the month, but for years, and working really hard to make that future a reality. Grit is living life like it's a marathon, not a sprint."
In an address to Stanford School of Business students, Sheryl Sandberg said:
"All the stuff out there on grit and determination and working on things that are challenging is all true...

There’s no substitute for hard work. I have a poster in my office that I got from [Starbucks founder] Howard Schultz of two dirty hands. It says the future belongs to those of us still willing to get our hands dirty. Do something you care about and get your hands dirty doing it. You’ll be able to do anything, I promise."
And lastly, in "The Score Takes Care of Itself", Bill Walsh says:
"All successful leaders know where we want to go, figure out a way we believe will get the organization there, and then move forward with absolute determination. We may falter from time to time, but ultimately we are unswerving in moving toward our goal; we will not quit. There is an inner compulsion - obsession - to get it done the way you want it done."

Recurrence in PHP

Earlier this year I spent many months working on a web app for a client. Without giving too much away, one of the requirements was that the app gave users the ability to create recurring events. These would need to be scheduled weekly, biweekly (with specific dates), monthly, bimonthly and annually.

If you search for "software architecture recurring events" (or something to that effect), you'll most likely come across this Stack Overflow answer. The approach it describes seems like it should work, but it's hard to tell merely from reading the code whether it's a good solution.

Having spent many days trying this solution (and many others) the best method for creating recurring events I could find was to use the iCalendar RRule standard.

The RRule is a written as a semicolon-separated string of key-value pairs that describe different parts of the recurrence pattern. It's especially useful because it allows for irregular intervals and specific dates. For example, the following describes an event that occurs on Monday biweekly.


The following describes an event that occurs on the 12th of every month.

In PHP, I found the When library to be the easiest way to generate a range of dates with RRules. We can restrict our ranges with a start and end date too.

Traditionally when building a calendar application, you'd generate recurring events dynamically and view them on a calendar-like interface so that your events would appear to reoccur indefinitely. In my app however, future events would have associated data and therefore need to be queried against in a database, so as to avoid holding everything in memory.

I chose to design a scheduled daily process that would generate recurring events for up to a year at a time and store them in the database. If an RRule interval occurred on the current day, a new interval row would be added to the database for a year's time.

The purpose of this post was to help others should they ever find themselves in a similar position. Having spent a great deal of time trialling several different ideas, this was the one that allowed me to come closest to a fairly efficient, working solution.


Over the last 12 months I've been able to lose around 80lbs in body weight. For the most part this will have been from exercise, but I also eat reasonably well.

The following is one (very subjective) order of operations for improving your diet.

  1. If it isn't good for you. Don't buy it.
    If I have crappy food in my fridge I will always eat it. I know this because in every instance that I can think of that I've brought something that was bad for me home, I've eaten it in one sitting or the same day.
    To satisfy my sweet-tooth cravings I buy low sugar/low fat yogurts and fruit. I like eating both and I eat only what I like the taste of. If I get bored of a type of fruit or brand, I try a different one.

  2. Exercise first.
    Most cardio equipment at the gym will give you a rough indication of how many calories you've burned. If you enter your body weight, Strava can do the same. When you're conscious of the number of calories you can burn and the time and effort it requires to do so, you'll start to think more about how many you consume from food.
    For example, I can burn 550 calories by running 5km. This might take me 25 minutes and if I try hard I'll want it to be over at the end. A side of fries will bring me close to this and the effort I've put in will have been cancelled out.

  3. Pay attention to serving size.
    Food packaging displays the fat, sugar and salt values for eating a certain quantity of food. Don't assume that a green label means something is empirically "healthy". Ensure that you're content with eating only the amount that the packaging states and if you do eat more, be mindful of how much fat, sugar and salt you're consuming in one day. E.g. a 1/2 pack of fresh pasta is 20% of my daily intake, so a whole pack is 40%.

  4. If you want to eat rubbish food, go ahead.
    It's human to crave something sweet or oily every so often. Suppressing those urges will only make the cravings worse. It's fine to eat unhealthy food once in a while as long as you moderate your intake. Assuming you're also exercising, you won't feel like eating crap all the time anyway.

Reflections on Startup School 2019

This past summer, like many thousands of others, I took part in Y-Combinator's "Startup School". For the un-indoctrinated, it's an online class for early stage startups.

I participated in eight of the ten weeks the class ran for, mostly because changing my focus to applying for jobs meant I couldn't give my full attention to what I was working on. My MVP had also slowed down to the point where just pushing code became a real chore. More on that later.

For context, the problem I'd chosen to work on was that of internal documentation for development teams. It was something I'd identified from years of working in creative agencies (where documentation is usually non-existent). Of the handful of companies working on this problem, I thought I could do better.

The format of the course consisted of weekly lectures, followed by video sessions with other founders. For the video sessions we were asked to describe our companies, the problems we were trying to solve and what we thought our greatest challenges were. At the end of the session we were prompted to share feedback via a form. To participate in the course, companies were also required to submit weekly updates, detailing things like how many users they'd spoken to, what their problems were, what their morale was like.

Many of the companies I spoke to during these video sessions (including mine) were in concept stage and hadn't launched or began trading, but I met some founders who'd sunk their lives and life savings into products that didn't have a market, founders who were about to relocate to Silicon Valley and founders who were entering into accelerators.

The video sessions themselves were fairly beneficial, with the exception of one or two. Quickly I realised I enjoyed discussion other founder's ideas, thinking critically and encouraging others, as much as I did my own. It was insightful to hear about how other founders had settled upon an idea, why they'd made certain assumptions about their market etc. The first session immediately made it clear to me that I needed to think more about how to describe what I was working to others (including the non-technical even though those people weren't my target audience). It even resulted in me changing my name from 'SlimDocs' to 'SwiftDocs'. Feedback from other developers in my first video call was also encouraging.

The first week's lectures particularly resonated with me because they forced me to think about my problem from the perspective of prospective users and investors:

  • How to Talk to Users

  • How to Evaluate Startup Ideas (pt 1)

Following these, I approached some developer friends of mine to conduct user interviews. Though these were supposed to be limited to a few questions, they grew into hour-long conversations. It was clear to me that internal documentation was something developers had strong but varying opinions on and that the people I'd interviewed didn't believe a good solution existed, but it was important to focus on the problem and didn't stray into brainstorming solutions. The "How to Talk to Users" lecture outlined some particularly useful questions to ask. Of the ideas to come out of these discussions, my main takeaways were:

  • Developers didn't feel it was their responsibility to write docs. This was merely a distraction from writing code. Time was the biggest obstacle to writing good documentation.
  • The most value internal documentation provides is WHY certain decisions were made, not simply a description of how something works.
  • Internal documentation can have several different audiences (technical and non-technical).
  • Developers/Companies are willing to invest in products that save them time or provide a tangible benefit. (Who knew?)

It was important that I spend a week thinking about my problem at a granular level, especially who the stakeholders might be in documentation and what their interests were, before ploughing into an MVP. The second week's video session was particularly helpful in allowing me to do this. One particular piece of feedback I had was:

"Think about the people who are required to produce documentation rather than trying to convince people that they should be doing it. Anything that automates a boring task is likely to have customers."

By the time the third week's video session had come around I was better able to describe what SwiftDocs was to other founders. At the suggestion of a founder in week two, I found some stats that helped better explain the problems I was trying to solve. For example:

SwiftDocs is a code editor extension that helps development teams better understand their code. Having been a developer for the last 5 years, my experience is that codebases are typically poorly documented or not documented at all. As a result, it's much harder to bring new developers onto a project.

  • On average it takes 8-12 months for new employees to gain the same proficiency in their role as co-workers.
  • Lost productivity due to training new employees can cost a business up to 2.5% of their total revenue.

It was also around this time that I felt it was right to start working on an MVP. An early concept I'd come up with was a note-taking app that would index your repositories, allowing you to reference files and snippets of code as you typed. This idea seemed simple enough to execute on, but I wasn't comfortable with having to build features that apps like Notion and Confluence already supplied out of the box.

I was interested in the idea of coupling the code repository with the text editor. I thought there was opportunity in an idea that allowed you to write docs as easily as you could write code. The biggest obstacle was that indexing a code repo takes time and a repo could be infinitely large. I was curious as to whether there was a way developers could write explanations of their code within their editor, like code comments, but I thought there was potential to create larger structured "wikis" with grouped comments and tutorials. An unrelated idea I'd had was to simplify the code editor tree around only the areas of functionality you were working on (with monolithic codebases in mind).

I carried out some internet research, including searching on Product Hunt for products that aimed to solve similar problems and came upon CodeStream. Initially I was alarmed because their product was solving a problem close to my own and they were well-established (with several hundred thousand installs on multiple platforms) but from previous experience I knew it was best to ignore the notion that they had a total market share. Upon closer inspection I didn't feel that they'd captured the entire crux of the problem. I reached out to a friend who assured me that he'd used CodeStream and agreed there was more scope.

I decided to start working on a VSCode extension. I chose VSCode because it was the editor I currently use and knew there was already an ecosystem around writing extensions for it. They also had good documentation (hurrah!) To test some initial assumptions I had around the file tree, I wrote a basic extension in Javascript called 'File Tagger' (

In doing this, I found that VSCode's documentation used Typescript exclusively, as did the code examples. I decided to therefore take a few days to learn Typescript and familiarise myself with the different aspects of VSCode's API.

At first, building the functionality I'd set out for my extension seemed relatively straightforward. VSCode gives you an "Extension Development Host" (essentially just a Node server) which you simply refresh whenever you make code changes. On my 5 year old Macbook Air, this process was a memory hog and quite slow to work with.

One issue I ran into was how to structure my project. The documentation wasn't particularly clear on this, nor did I get a sense of best extension development practices.

As I moved on from the Tree View to working on the "Webview" part of the extension where most of my UI would exist (a Webview is essentially an Iframed HTML page), I also introduced React into the project. While composing my views was now much more manageable, it also required me to create a webpack config that handled two environments for both the front and back end. I chose to keep all my Webview functionality in a separate directory and compile my scripts into a Webview-specific file.

Another issue that arose from using React was how to manage state. I didn't want to introduce greater complexity with something like Redux, but whenever a Webview is "de-focussed" in VSCode, the client-side state would be cleared. Extensions can have their own internal memory to persist data, but this required me to call the vscode.setState method on componentDidUpdate, which wasn't super clean. Also, to send data to the server I would need to send an event with vscode.postMessage. I created a MessageBus class to encapsulate this functionality and create event listeners for these events within my application.

During week five's video session, I expressed doubts to the other founders about completing my MVP within a reasonable timeframe. Even were I to cut functionality from the extension, I still had a back end service to build. Something a non-technical founder suggested was to release my extension for free as open source. Initially I brushed the idea aside questioning how I was to possibly generate any revenue with a free product but in reality it made releasing a first version a little easier. I'd have to think about how I'd replace the backend functionality I'd planned to build and the idea of storing code snippets/annotations in a version-controlled JSON file seemed like a fairly robust approach.

It was frustrating to have to keep pushing back my launch. I wanted to adopt the YC ethos of "launch early", but I felt so constrained by time.

I attended week six and seven's video sessions and had to rethink how to describe what I was working on, now that it was going to be free. I received some morale-lifting feedback from other technical founders and was motivated to push on. Week seven's session was memorable because another founder (who was notably late and had poor audio quality because he was attending the session from a public cafe) thought it was appropriate to try to discredit my understanding of Javascript and we awkwardly bickered in front of the others. I don't think anyone really cared, but it soured the tone a little.

I admit that my interest in the video lectures had began to wane around this point and I got the same impression from other founders I'd spoken to. I did however enjoy "How to Evaluate Startup Ideas (pt 2)"

By week 8 I'd almost completely lost interest in continuing to work on my project and not surprisingly it was around this time I started to focus on finding another job, which naturally became a huge distraction from writing code. I would have loved to have finished building SwiftDocs, but it's currently in a private Bitbucket repo and about 75% complete. If you're reading this and think it's something you'd like to work on, message me and I'll get a public repo going. SwiftDocs now exists on Github and I'll be committing to the repo there. Please contribute!

My biggest takeaway from Startup School would be to find a cofounder. Someone to share some of the workload and offer a little encouragement from time to time. Though I have no immediate plans to start a company, it continues to be an interest of mine. Perhaps I'll go back to one of the ideas I did finish, like Postkit.