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.
"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."
"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."
"...one 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."
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.
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.
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.
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%.
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.
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.
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 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.
Our perception of what it means to be successful is wrong. There's no universal standard.
It wasn't a book or article, only finding someone I used to go to
school with on Facebook that prompted me to think about my own
perception of success. The person in question, who initially didn't
perform well in their A Levels, is now a Physics student with some of
the world's best universities under his belt.
It occurred to me that while his achievments are impressive, they're
not mine either, nor do I hope to ever come close to achieving them. On
the face of it, this isn't a particularly difficult idea to get one's
head around. Let's hear this one more time.
Other people's achievments are their own.
On the flip side, if my goal was to study Physics at the
best intitutions in the world, what then? Would I have achieved
'success' if I reached my goal? What would I aspire to do after? The
reality is, nobody knows. I'd have to get there to find out and probaby
take multiple unexpected turns along the way.
As I start to think about where I sit on my own path to success, I
realise there's really no end. As a developer I continue to grow, but
ultimately I decide when I've accomplished something with enough substance to have acquired it.
A recent article I read forced me to think about the way I utilise my
spare time to work on 'side projects' and the lessons I've learned from
(many) failed attempts.
In a recent article,
Australian PhD student Jack Simpson writes 'Even if you dedicate many
hours to a task and it’s 80% of the way there, if you never finish then
no-one will care'. He's right of course - however brutally honest his
The piece really struck a chord with me because so often I find
myself starting new projects that don't go anywhere. Zuckerberg
initially didn't dream of building Facebook, he created a way to connect
with his classmates. I can always say I learned a great deal, but if I
don't have anything to show people I can't say I ever did
anything. I lose interest, or it dawns on me that I'm building
something that already exists, or I've found a solution to a problem
that doesn't exist - whatever. There has to be that middle step between
the grand vision and the smaller tasks like writing lines of code.
Failed project ideas of mine include: an API-driven CRM, a food
ordering system for offices, a chat platform for learning how to code
and a ticket-trading platform for students. I have hundreds of entries
in OneNote titled 'What's missing?'
where I'd look at the past week and come up with solutions to the
problems I'd encountered. Often these are problems only I'd come across
and the scope of the problem was too narrow; Often the problems were of a
scope far too broad to ever be solved by a single solution.
Looking back as I write this article, these aren't inherently bad
ideas - some of the pieces are there, some aren't. I don't think I'm bad
at coming up with ideas or identifying which ones will work or not; the
crux of the problem is actually attempting to do too much with the time
The last couple of weeks I've been working on things that I can build an MVP of in a weekend. I wrote Tweet Thread
in a day and I have a few things on the go right now. I'm still
interested in solving problems and doing cool shit with technology, but
projects should be iterative.
When I began this article about a week ago I started to write about self-doubt and the toxic, intractable effect it's had on my life. In doing so, it morphed into a piece about self evaluation and personal growth.
In the last 6 months I've learned a great deal about when my personal judgements are wide of, or on the mark and this largely informs whether my opinion of myself is accurate or not. I've found it's incredibly useful to be able to take a step back and assess how well you're doing, both personally and professionally and take action on areas that need improvement.
With my 21st birthday tomorrow, marking almost a year of continuous professional development, I wanted to write a few notes about some things I've been thinking about for a while. While much of this may not be new to you, I encourage you to carefully reconsider these points and take as much meaning from them as you can.
1) Criticism doesn't have to be negative.
2) There's huge value in having the ability to spot your weaknesses and learn from them.
5) Don't overanalyse. When I had mental health issues, I had a problematic tendency to overanalyse and criticise myself. In hindsight, the only impact this had was that my reduced self confidence caused me to have more of a reason to do this.
6) A team is only as strong as its weakest member.
Just five minutes ago I was standing beneath New York's flatiron building, but as you've probably guessed, I wasn't there. It's actually 11:10pm, and for the last ten minutes, my neighbours will probably have seen me pointing my iPhone around my bedroom as if filming an indie documentary about ghosts. This is my second VR experience and I feel truly immersed.
It was only last Thursday that my boss challenged me to 'get that Google Cardboard working'. Within 20 minutes I'd installed the NYTimes' Vrse app and had downloaded a 700mb clip, designed to work with the headset. It took 30 seconds for me to realise what I was seeing was unlike anything I'd ever seen before. I passed the device to my colleagues and before I knew it several had gathered round, intrigued by what all the excitement was about. There's no doubt about it, VR is a crowdpleaser.
We've read about how virtual reality is going to take over the world for a while now. Facebook bought Oculus for two billion dollars in July 2014, and is now looking at a 2016 Q1 launch of its 'Rift' headset. Google launched 'Cardboard', a low-tech kit for affordable VR and (it's estimated) has shipped millions of units.
But it's clear the technology still has a long way to go. Last week, it was revealed that operating the Oculus Rift will require a PC with a specification that off-the-shelf might cost "a thousand dollars". Of course the media often inflate stories like these, although there's no doubt powering a headset like the Oculus is going to need some substantial graphics power. 
In the enterprise, there seems to be a trend towards using VR to enhance the roles of the "non-desk workforce", jobs that potentially require a level of foresight or investigation. VR could transform construction/ real-estate/ planning by allowing us to pre-visualise proposed developments within our current environment. Earlier this year Microsoft's Hololens concept trailer alluded to this. We see the device used by mechanics, plumbers, scientists, all non-desk workers.
There'll still be a part of me though that feels like VR is now a missed opportunity in terms of building products. I'm finding Geoffrey Moore's 'Crossing the Chasm' particularly interesting at the moment, and while VR is still probably in the 'innovation' stage of the adoption lifecycle, I can't help but feel the most involvement I can have as a developer is as an early adopter.
When the Rift comes out in 2016 there's a good chance I'll be buying one, but until then it'll be interesting to see how the market unfolds.
 Here lies a potentially huge opportunity - building hardware powerful enough to run such a device. Intel's NUC seems to have lost traction recently, but with Iris integrated graphics now capable of running 4k displays, low energy CPUs could be the way forward.
Edit: At Google I/O this last week, it was reported Google had shipped 'over a million' unit of its 'Cardboard' headset.