Grit

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:
"...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."

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.

FREQ=WEEKLY;BYDAY=MO;INTERVAL=2

The following describes an event that occurs on the 12th of every month.
FREQ=MONTHLY;BYMONTHDAY=12;INTERVAL=1

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.

Diet

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' (https://github.com/mrtrwhite/vscode-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.

Running

The best way to improve at running is to not get injured. Injuries stop you running for long periods, during which you'll see the biggest improvement.

Ways to not get injured (in no particular order) include:

  • Buying shoes that fit.
  • Not overdoing it. Taking rest days. Giving small injuries time to heal.
  • Running on the middle to front part of your feet. Not overextending your leg.
  • Stretching/warming up. Cooling down.
  • Not running fast on uneven ground or in the dark. Not falling.
  • Straightening out your body at the start of the run to not get a stitch.
  • Strengthening your core muscles with bodyweight exercises.
  • Stretching your leg muscles with a foam roller.

A few notes before turning 21

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.

3) There's no ego in self evaluation.

4) A failure is always a learning experience. Don't worry about getting things wrong. You won't do it again.

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.

7) You can't win an argument.

8) If you're wrong, admit it.

My first VR experience

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. 

Dozens of new startups are popping up, like InsiteVR (YC W15). Andreessen Horowitz named VR as one its '16 things' it was interested in investing in, and Y Combinator has updated its 'Request for Startups' to include Virtual Reality.

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. [1]

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. 

[1] 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.

One week with NYTimes: Paying out of appreciation

I subscribed to The New York Times' digital plan last week. I'd come to the realisation that I often find myself reading their articles and should therefore pay for something I find valuable. As with many newspapers, NYT has a limit of 10 articles a month for non-paying users. Of course this can be easily bypassed with Chrome's incognito mode, but I wanted no restrictions. I've been thinking about this idea of paying for services we don't strictly need to over the last few days, and asked the Hacker News community with not much of a response.

Upon first logging into the Times website at my desktop I was amazed at the vast wealth of content. This wasn't clear to me as a non-paying user, and NYT should do more to make this apparent to prospective subscribers. As you'd expect there are the general News sections, 'Business', and 'Opinion'. I love that 'Technology' and 'Science' are separate entities, and 'Health' often piques my interest. I dip into 'Art', 'Travel', 'The Upshot' and 'The Magazine' for longer, slower reads.

What I hadn't expected, was how brilliant the Times' mobile app would be. It has all of the same content as above, only in a neat, easily navigable package. Content loads quickly; images render as sharply on my iPhone as they do on my home monitor, and I have no problem playing back some of the engaging video NYT manufactures.

I don't think I've had this kind of experience with a media platform before, except maybe National Geographic who also produce brilliant content and take great care in ensuring it looks fantastic online. (Take for instance an article published last year on the Palaeolithic diet, which I read in both print and online.) There's definitely a sense that a lot of effort has gone into making using the Times' site and app as effortless for me as possible, but on top of that, making it something I love and want to use.

Despite now paying for a subscription to the content I love, Facebook recently announced their intent to host articles from NYT and National Geographic, among others. For mobile users, some articles will launch inside the Facebook app, instead of in a new browser window; the ultimate goal here is speed. According to a statement made by Facebook, this should allow articles to load up to 10x faster. Product Manager at Facebook, Chris Cox said, “We’re starting with something that we think is going to work for some publishers for some articles and for some business models... We’re not trying to go, like, suck in and devour everything.”
My instant reaction was that Facebook had created something truly innovative, but then I began to question how this might affect subscription rates. From what I've read, I don't get the impression the publishers are concerned, but will use this tool to compliment their online presence.

I've been reading Dale Carnegie's 'How to Win Friends and Influence People' and have taken much from it, most notably Chapter 3 which concludes with the message, 'Arouse in the other person an eager want'. Only the best marketers can do this. The reason I subscribe to the Times isn't because their articles limit makes it marginally less convenient for me to read the content I like, but because it's a service that I want to use and deem worthy of payment. The same goes for the movies I watch. Of course I could download a pirated copy of the latest Mad Max film, and cover any trace of me having done so, but I want to pay to see it in the cinema as a token of my appreciation for the hard work that went into its making. (One might argue that a major benefit of seeing a film in the cinema is the sound and picture quality, which is virtually impossible to replicate in one's own home.)

Many software companies have free tiers for their products, which come with limited features or usage caps. Atlassian's Bitbucket free tier and pricing model has worked well, but Slack seems to have found a strong balance. I don't get the impression that Butterfield is concerned that the product won't sufficiently monetise, especially when a subscription costs just $7 per month per user.
That said, I'm sure many companies will abstain from payment despite the productivity and efficiency gains they'll undoubtedly experience.

For consumers, it comes down to whether you think the product is worth paying for, but for businesses the stakes are a little higher, and the motivations are probably a bit different. With a product like Slack, other than time saved, I can see how small to mid-level businesses might struggle to judge what gains in productivity are doing to their revenue, or whether these gains are even attributable to the product itself. Enterprise applications therefore need to better show their customers what the benefits of using their products are, both before and during use. It astonishes me that Slack doesn't generate a summary of group usage data, or have any kind of management dashboard with usage and performance metrics for its non-paying business users.

All kinds of companies have the ability to make me want to use their product, but so often choose to employ some devious marketing scheme to pressure me into buying. Undoubtedly the best products are the ones that don't convince or persuade, but prove to me that I'd benefit from using them, and as a customer that's the best way to make me want them.

Finding purpose in side projects

I'd be lying if I didn't say founding, or at least working for, a SaaS startup was a long term aspiration of mine. 

I'm currently in the 'learn everything I possibly can' part of my career. I spend a great deal of time reading about not only startups but other things that interest me, like conservation, technology, business, journalism and current affairs, often in the belief that I'll be forced to question the world around me, and therefore identify problems to which I can invent effective solutions.

A large part of web development is identifying these problems, and designing apps and websites to best solve them. I guess that's why so many developers work on side projects: because they're an opportunity tackle real problems [1]. It's no secret that some of the world's largest technology companies (Google, Facebook, Microsoft) began as 'side projects'.

Unfortunately, so many side projects I see online operate under the guise of 'research' and while they may be impressive from a technical point of view, have few real-world applications. I personally struggle to find meaningful projects to work on, ones that might actually make an impact on somebody, somewhere.

It often seems like a struggle. You commit your time to something, only to realise you've been looking in entirely the wrong place, or that the idea that seemed so original actually already exists. Paul Graham's essay 'How to Get Startup Ideas' explains how often the ideas that are most successful are the ones that occur 'organically' [2], where a founder identifies an opportunity out of an experience of their own. The best approach to coming up with project ideas therefore is to 'not "think up" but "notice"', in other words, put oneself in a situation in which they're more likely to identify real world problems.

A thread on Hacker News highlights a general consensus that is, if you want to come up with lots of ideas, read a lot. Immerse yourself in subject areas that you might not have thought would interest you. Personally, I try to read at least 4-5 articles a day on any number of things. In print, I'm an avid subscriber to National Geographic, but I sometimes dip into New Scientist, and of course I always read the weekend papers, which so often turn out to be waffle. Online, HN often points me towards articles I like to read. I frequent the Verge, Wired and New York Times websites for technology updates, and I can sometimes rely on my cultivated Twitter feed to send me in interesting directions.

Of course many of the opportunities that I do identify will lose traction, and I make a note of those and put them in a draw for a rainy day. I came across a site online, similar to an idea I had 6 months or so ago, that was a sort of food recommendation engine. My project had conservation in mind, but this one was built more around baking. I guess in a sense I dodged a bullet [3], but it's interesting to see someone have a similar idea and run with it. Often I look back on ideas from as recent as weeks ago, and as writers do, ask myself, 'How could I ever have thought that was a good idea?'

I think therefore, to come up with meaningful side project and startup ideas, it's so important to question, 'Does anyone really want this?', and these ideas must come from actual problems people face. Do they have to be world-changing to be meaningful? Perhaps not, but the best startups are, and came from side projects that may not have seemed like they were.

[1] And learn in the process.

[2] "At YC we call ideas that grow naturally out of the founders' own experiences 'organic' startup ideas. The most successful startups almost all begin this way." - Paul Graham, 'How to Get Startup Ideas'.

[3] Or missed an opportunity. Who knows?