tag:timwhite.digital,2013:/posts Tim White 2020-05-18T23:53:54Z Tim White tag:timwhite.digital,2013:Post/1545497 2020-05-19T17:00:00Z 2020-05-18T23:53:54Z Understanding problems

Every six months or so I re-read Paul Graham's "How To Get Startup Ideas". Not only is it always a refreshing read but it's also a great example of a piece of writing that communicates one set of ideas really well.

He writes:

"The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself."

I spend much of my spare time thinking about problems with the intention of turning some of them into side projects but the vast majority don't make it this far. I also find it interesting to talk with friends about how things (business, systems etc) can be better. 

While I think I've become pretty good at analysing problems I can't claim to have any experience building successful businesses, so this article will focus solely on the former, but I'm going to use examples from my Startup School project Swiftdocs which I've written about here before.

The most valuable advice I can offer would first be to ensure the problem you're working on is in fact a problem and not a solution. Many people tell themselves their problem is "the need to automate X". Automation is a solution to several problems, one of which is probably a slow or complicated process. Free your mind of any preconceived ideas about what you think a solution could be before you talk to potential users about their problems.

Most of the time the first problem I think about is not the one I end up with. Usually a problem is caused by another, which might be caused by another and so on, so usually my first priority is to ask, "What's the root cause of this?" For example, Swiftdocs attempted to address the fact that developers didn't like writing technical documentation. While it's true to an extent, the root cause of this problem (that I came to realise only recently) is that capturing information from conversation is hard. Were we better able to capture information from conversation: the thought and discussion preceding a decision or set of actions; there'd be no need to write anything at all.

Some complex problems may be made up of other smaller problems of varying relevance or importance. It's easy to convince yourself that the right solution relies on you building something that addresses every one of these, but my advice would be to pick the most painful of the child problems (and the one that addresses the biggest part of the parent). The problem your customers find most painful is also the one they'll most likely pay for a solution to. On Swiftdocs for example, I'd identified that developers didn't like writing documentation and some of those I'd interviewed said that they didn't feel comfortable writing grammatically correct prose. I could have built something that had grammar checking built-in but this wouldn't have addressed the greatest part of the broader problem.

I think it's important to think about why some problems exist, especially if you're solving one of your own problems that pertains to say, the company you work at. In some businesses, problems merely exist because of the way it chooses to operate and may not exist at others. You must decide whether your problem is one that other people share and the best way to do this is to speak to potential users. You might also look at existing solutions, though it's important to understand that while other products exist they may not capture any of the wealth in the market.

Sometimes, even after rigorously analysing your problem you may find that it doesn't even require a paid solution (if building a profit-making business was your intention). How committed to rectifying your problem you are will determine how far you take it after this point, but know that if you don't do something about it, someone else will. Perhaps you'll even use the knowledge you've acquired to help them do so.
Tim White
tag:timwhite.digital,2013:Post/1545320 2020-05-16T15:00:00Z 2020-05-16T21:33:27Z Stupidity and Malice

After publishing my last post, "Building Software, Sharing Knowledge", I've been thinking more about an idea I touched on:

"Rarely do we just blindly do things without giving them any thought and so it's always best to assume that past decisions were made with some level of consideration."
While we often like to assume that past decisions were stupid, I don't think they're as common as we'd like to think they are.

Invariably, in all aspects of life (including work) there is context to another person's actions, often that we cannot understand. Without this context we may incorrectly perceive their actions as stupid and sometimes even malicious. 

Incidentally, I find that our inclination to see things this way is usually indicative of our general feelings about a person.
Tim White
tag:timwhite.digital,2013:Post/1531639 2020-04-17T18:00:00Z 2020-04-20T12:06:58Z Building software, sharing knowledge

I have a controversial opinion: When developers say something doesn't work, most of the time they simply don't understand how it works or why it was written that way.

Forgive me for sounding cynical. It's perfectly reasonable to say something doesn't work how it should but, all factors considered, I don't think this notion's as common we'd like to think it is. Instead, I think we come to this conclusion because it's easier than struggling to comprehend a piece of work written by someone else. The challenge in attempting to get our heads around a piece of complex code or system feels insurmountable and labelling it as broken gives us more time to attempt to solve the problem at hand (or decide if there is one at all.) We also have a tendency to want to put our own stamp on things, which we wouldn't be able to do if everything was already perfect.

This misunderstanding is usually a disconnect between the person who originally carried out the work and the person who's currently working on it. At some point in time, information was lost. This might include: a description of the original requirements (the problem), an explanation of why certain decisions were made (context) or merely an explanation of the implementation itself.

A project's requirements can be relatively easily documented at its start but something most teams forget is to update these documents as the requirements change, as a product of day-to-day decision-making. It's important that this document or specification is maintained by someone likely to be involved in these decisions going forward and the right people are notified when it changes, which usually can be automated in some way.

Understanding the reasoning behind (why) certain decisions were made is a little different in that it's everybody's responsibility to document it. You'll know it's failed to do this properly if at some point you hear people say "I don't understand why it was built this way", because invariably there's context missing.

The mistake is confusing this with stupidity. Rarely do we just blindly do things without giving them any thought and so it's always best to assume that past decisions were made with some level of consideration. Perhaps the tech lead at the time wanted to use a particular technology, or there were knowledge gaps in the team, or the deadline was too tight for the ideal solution. Perhaps the person who made the decision holds a different opinion to you.

Unfortunately, most teams don't foresee a lack of documentation being an issue until it becomes one, for example when a developer makes a breaking change by deciding to refactor a piece of legacy code. In most instances, refactoring code (with the intention of making it better) is something to be celebrated and yet by trying to do something she thinks is beneficial, but acting on incomplete information, she inadvertently makes things worse. Furthermore, the situation creates a sense of fear around particular parts of the codebase, especially for new team members who introduce new abstractions instead of tackling what's already there head-on. As you can imagine this only exacerbates the situation and when left unaddressed, creates a precedent that it's better to skirt around "ambiguous legacy feature X" than to understand and document it.

As I found while researching the problem of documentation in technical teams last Summer, software developers hate writing documentation. The majority of us don't consider it to be something that should fall under our remit, nor do we think it's our responsibility to write well. The majority of us don't even feel our code should need documenting if it's written in a "clean" way. I've always thought it a little ironic that some developers obsess over the clarity and cleanliness of their code but don't hold written communication in as high a regard.

I suspect that many of us simply don't feel we owe anything to our successors, those taking over the reigns at some point in the distant future. As developers we need only focus on what's happening in the present and the problem we've been tasked to solve now. Any time spent dwelling on something after the matter is time we can spend solving other problems. This thinking is ignorant and short-sighted and probably more often than our successors do we need documentation to understand something we've written ourselves (months or years prior). I once worked with a back-end engineer who one day was searching for the answer to a question on Stack Overflow only to realise he'd written the nominated answer about a year before.

While I appreciate how intimidating the blank page can be, to write something, anything, words on a page, is better than to not write anything at all, as long as the meaning is clear. Managers must do everything to lower the barriers to creating documentation, even if it means removing internal processes, leapfrogging hierarchies etc. There's no place for overzealous GSuite protectors here; Most modern editors have some concept of revision history so there's no risk of anything being "messed up". Furthermore, as important as writing documentation is, ensuring teams have access to and the ability to search for relevant documentation is equally important.

Writing documentation is just one product of a culture that encourages knowledge sharing. A senior developer who spends his time mentoring less experienced team members should have no objection to sharing his reasoning in written form (and probably enjoys it more than you'd think, because who doesn't like talking about their own ideas?) A team that is continually finding opportunities to create and share knowledge is a team that continues to grow.
Tim White
tag:timwhite.digital,2013:Post/1531641 2020-04-15T18:00:00Z 2020-05-16T15:21:14Z The Programmer's Rut

I originally chose to learn PHP because it was the language most of the companies located near me (marketing agencies building websites in WordPress, Drupal, Laravel) used and therefore the language I was most likely to find a job with.

I tend not to engage in conversations online discussing its flaws because, in light of them, I like writing with PHP. It's simple and because of that it's easy to build things with. Of course in the six years I've been writing it there are aspects I've grown to dislike (go fuck yourself fopen) just as there are parts of Javascript I don't like, having written it for just as long.

It's the language I reach for if I have an idea of something I want to build on the server, especially when I want to move quickly and that's because unashamedly it's the language I'm most familiar with. This is self-perpetuating: I'm most familiar with it because I use it the most, including in my day job.

I've had many false-starts learning other languages, like Python for example, which seems to have become the defacto programming language for many London tech startups, probably due to its prevalence in machine learning, while only a small number of companies still use PHP (with a handful of notable exceptions: Facebook, Slack etc.)

I haven't had the need to learn Python as much as I have PHP even though I can appreciate its redeeming qualities; For many of the applications I'm likely to use it for (web apps, APIs etc) there isn't a discernible difference in performance and therefore it feels like a different route to the same outcome. It's because of this that I'm not likely to use it on a regular basis, which makes it considerably harder to learn to a high degree of proficiency.

And so I find myself in somewhat of a rut, where learning and practicing other languages becomes increasingly difficult. While I can't see myself struggling to find work in PHP any time soon, I must ask myself, "Are there problems I'm interested in working on that can't be solved with PHP?"

Tim White
tag:timwhite.digital,2013:Post/1527688 2020-04-09T09:00:00Z 2020-05-17T23:14:40Z Do the Hard Thing First

A piece of personal advice: Given a list of tasks varying in complexity, do the the hardest one first.

You'll be able to quickly figure out how long it takes to finish those easy ones because even from just looking at them for a few seconds you'll understand what's required. Perhaps you'll even trick yourself into thinking you can knock them out of the way, quickly enough that it'll leave you ample amounts of time to address the harder tasks.

But the hard tasks will have unanswered questions. And answering those questions might involve asking new questions. All of this will take time. It may be that at some point during this process you realise you don't have enough time to complete the other tasks at all. That's fine, because you're in a position to do something about it.

And lastly, often solving harder problems leads to a greater payoff, giving you momentum you didn't have when you started and allowing you to finish the easier tasks in less time.

Tim White
tag:timwhite.digital,2013:Post/1523390 2020-03-24T18:00:00Z 2020-04-15T14:07:56Z Criticism and Candor

One of the many great revelations in my career so far has been learning the difference between criticism of work and criticism of an individual. Many developers I've worked with assume that to receive criticism for a piece of work is a comment on their ability, which I can relate to, considering that we tend to take so much personal responsibility for our work.

When an individual understands that criticism (when delivered in a respectful way) is a tool for greater collaboration, clarity and creativity, a team is able to focus solely on producing better work.

In Creativity Inc, Ed Catmull discusses the use of the word 'candor': to be forthright or frank, instead of 'honesty', which carries moral connotations. The Braintrust, an elite group of Pixar's best writers and directors is built on this principle. As Catmull writes,

"...without the critical ingredient that is candor, there can be no trust. And without trust, creative collaboration is not possible."

He goes on to say:

"This principle eludes most people, but it is critical: You are not your idea, and if you identify too closely with your ideas, you will take offense when they are challenged. To set up a healthy feedback system, you must remove power dynamics from the equation - you must enable yourself, in other words, to focus on the problem, not the person."

Tim White
tag:timwhite.digital,2013:Post/1500765 2020-02-24T18:00:00Z 2020-02-25T13:49:48Z Interest and Purpose
I was surprised by how many of the lessons in Angela Duckworth's book "Grit" resonated with me, as though I'd come to loosely understand some of the ideas she writes about in the past, but never had the words to explain them. You may recall that I quoted a Duckworth in a recent blog post I wrote on Grit (having watched her TED Talk) and it's something I've been making a conscious effort to have more of. While her talk gives one a brief sense of the ideas discussed, her book is far more insightful. Years of failed side projects, failed attempts at learning instruments, hobbies I didn't pursue; It's the book I wish I'd been able to read ten years ago.

"Grit...", Duckworth writes, "is about working on something you care about so much that you're willing to stay loyal to it... It's doing what you love, but not just falling in love―staying in love." Fortunately, she reassures us that the tenets of grit (interest, practice, purpose and hope) aren't "You have it or you don't commodities. You can grow grit from the inside out", she writes.

The book's chapters on interest and purpose particularly struck a chord with me because it seems so rare in life that I encounter things I'm both interested in and that have purpose, which Duckworth describes as "the intention to contribute to the well-being of others".

Many of the side projects I've worked for example have had either, but so rarely both. It's interesting to look back and classify each of them: Reportship, an analytics tool I worked on had value to others but wasn't something I was particularly interested in; Squadwipe, a gaming video platform, was interesting to me but nobody else; Postkit, an API prototyping tool was interesting and had some purpose to others, but not to any great extent. It's impossible to understate the importance of building something people want.

In "How To Get Startup Ideas", Paul Graham discusses what he calls the "unsexy filter": choosing not to work on an idea because it doesn't seem interesting, in the face of the value it offers to others. He writes, "[The unsexy filter] keeps you from working on problems you despise rather than ones you fear. We overcame this one to work on Viaweb. There were interesting things about the architecture of our software, but we weren't interested in ecommerce per se. We could see the problem was one that needed to be solved though."

I'm sure there are times when an activity doesn't immediately have purpose to others but instead is acquired over time. Take for example the story of the Javascript library Vue.js of which a documentary was recently made. For its creator Evan You, its initial purpose was to scratch his own itch: to bind Javascript objects to the DOM. As its popularity (and importance to the Javascript community) grew, Evan realised the opportunity to bridge the gap left by established frameworks Angular and React and began to work on the project full-time. In his words, "It's like my gut's telling me, this is the thing you should do."

I think you can apply this idea to many other walks of life, like discovering new hobbies. Cooking is one of the few activities that meets this criteria for me (as I both enjoy doing it and I can cook for others) and I'd imagine that many creative hobbies have the same potential (anything that involves producing something to demonstrate or give to others.) As Duckworth writes however, "...you can't really predict with certainty what will capture your attention and what won't. You can't simply will yourself to like things". Inspired by this I've recently been investing my time in a range of different hobbies, initially focusing on creative ones. I recognise the importance of not trying to do too much at once but also that I may develop interests through several different interactions with a subject, perhaps over the course of months or years.

Subjects that have both our interest and purpose to others are the ones we're most likely to want to work on for a long period of time. In the context of work, this isn't necessarily an indicator for success, but still highly important.
Tim White
tag:timwhite.digital,2013:Post/1501599 2020-02-10T19:00:00Z 2020-04-15T18:01:54Z "Nice" photographs

I often find myself drawn to the same themes in photography: introspection, identity and adolescence but, I particularly like photographers who consider colour and composition in the sequence of their images. The majority of the fine art books I buy are by American artists and include some kind of iconography in their work (Stephen Shore, Mitch Epstein) though this isn't something I intentionally look for, at least not at a conscious level. Often I make a conscious effort to seek out projects that address 'uglier' issues, like for example Leia Abril's "The Epilogue" or James Nachtwey's series on the American opioid crisis.

As a society I think we have a tendency to give praise to nice-looking photographs, to the extent that we ignore other impactful but less aesthetically pleasing work. On Instagram we reward sunsets, pristine-looking landscapes and superficial snaps our friends took at famous landmarks with millions of likes, but the wildfires in Australia continue to rage on and photographs continue to be made there. It's probably indicative of the way we choose what to care about, filling our lives with only content that makes us happy instead of work that focuses on other more pressing issues, or even the media's influence on what we take an interest in.

Though I think it's important not to focus on the process by which photographs are made (as is often the case in the fine art world), it's important that we give credit to photographs that resonate with us emotionally, not merely focusing on their subject matter, but recognising technical or creative merit.

Tim White
tag:timwhite.digital,2013:Post/1502638 2020-02-03T18:00:00Z 2020-04-09T10:26:21Z A network-less world

I've been thinking a lot about our relationship with technology and social media recently (predominantly Facebook, Twitter and Instagram) and its effect on our brains. I suspect this has a lot to do with reading Jorg Colberg's post 'After Social Media', which I recommend you read. Personally, I've never felt more disconnected from society than I do now, despite having infinitely more ways to communicate with others online.

One shift in my own mindset in the last ~year is that I don't feel the blind optimism about big tech I did a few years ago. The privacy scandals and security leaks are no longer barriers to technological progress for me; they're very real issues for everyday folk, who likely don't realise the extent to which their data is being sold, distributed and hacked. It's scary to imagine how easy it is to impersonate someone online using a social media profile or an email address today. As an aside, my father was the victim of an email account hack last year and fortunately we were able to deal with the situation together, but the experience was frightening for someone who only uses the internet to read email and view a handful of websites.

Even moreso however, I reject the idea that social media is bringing us together. If anything, it's doing quite the opposite.

Our use of social media continues to replace daily human interactions with digital ones. Friends at parties glance at Instagram while conversations are taking place in the room. Commuters on the tube scroll through the Facebook statuses of friends they haven't spoken to in years. In waiting rooms, we turn to Twitter for moderate entertainment; heaven forbid that we might have to stop for a moment to think about our lives. Ironically in the face of countless new messaging apps, our ability to communicate with each another is worse than ever.

A lack of face-to-face communication has eroded our ability to empathise or acknowledge others' opinions. In fact, research has even linked the presence of mobile phones to our inability to give help to or smile at others in public, or express emotion. Rare is it that one finds public discussion online that doesn't end in some kind of heated argument; Social networks goad us into sharing polarising opinions, propagating the idea that everyone in our network is aligned in their views and diminishing our ability to respectfully disagree for fear of being disliked.

As a society we've lost the sense of camraderie for our fellow humans we once had; As the boundaries between our real and digital selves merge, we're only obliged to treat strangers with the same level of respect as we do online. When was it no longer considered rude to not make enough room for other pedestrians to pass on the street? When did we stop thanking the bus driver? When did it become okay to barge past others in crowded places?

Often I try to picture the world my parents grew up in and imagine how our lives would be different without mobile phones, instant messaging and social media. How would I know which train to take? How would I let my friend know I was going to be late? What if my bookshop didn't stock the book I wanted? Of course for anyone over ~25, these are trivial problems. I'd ask the conductor which train to catch, meet my friend where we agreed on the phone and ask the bookshop to order in the book I wanted (albeit slower than if ordered online). The apparent problems technology's created are products of its own doing.

If the key to having better relationships is spending more time together, why have social networks at all?

Tim White
tag:timwhite.digital,2013:Post/1504062 2020-01-29T18:00:00Z 2020-01-29T22:05:02Z Distractions

Distractions often have a negative connotation. We say "I want to spend less time watching TV because it distracts me from doing [insert other activity]", but realistically trying to do less of something is hard without self-control.

Instead, finding other hobbies and interests to distract oneself with is a better idea. Ideally this is something you're already at least partly familiar with; placing too much emphasis on something new is a surefire way to lose interest.

I find that if I don't find an activity engaging enough, like for example reading, I simply find books that interest me. If the project I'm working on isn't exciting enough, I find one that is.

Recently I've found my interest for programming waning and spending more time playing video games, but I recognise I could be doing something more meaningful. Where no obvious interest exists (I haven't been able to run as I'm carrying a knee injury) I'm exploring several other hobbies, though I think it's important to have a balance of things I can do at home and those with other people or in public. Failing that, I see what my friends are up to, whom I always have time for.

Tim White
tag:timwhite.digital,2013:Post/1494405 2019-12-31T09:00:00Z 2019-12-31T18:05:16Z 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.

Tim White
tag:timwhite.digital,2013:Post/1474559 2019-11-20T09:00:00Z 2019-11-20T09:00:02Z 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."
Tim White
tag:timwhite.digital,2013:Post/1472906 2019-11-07T15:03:39Z 2019-11-13T09:00:02Z 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.

Tim White
tag:timwhite.digital,2013:Post/1472379 2019-11-06T09:00:02Z 2019-11-07T09:00:03Z 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.
Tim White
tag:timwhite.digital,2013:Post/1471698 2019-10-31T17:00:00Z 2019-11-02T22:02:35Z 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.

Tim White
tag:timwhite.digital,2013:Post/1471690 2019-10-29T23:42:00Z 2019-10-31T18:05:55Z 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.
Tim White
tag:timwhite.digital,2013:Post/1498002 2017-02-25T15:36:00Z 2020-01-11T16:11:54Z Success
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.

Tim White
tag:timwhite.digital,2013:Post/1498003 2017-02-22T15:36:00Z 2020-01-11T16:09:37Z Lessons from side projects
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.

The Problem

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 words are.

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.

The 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 I have.

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.

Tim White
tag:timwhite.digital,2013:Post/880059 2015-07-23T21:55:43Z 2015-07-23T21:56:15Z 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.

Tim White
tag:timwhite.digital,2013:Post/860246 2015-05-24T16:30:28Z 2015-06-18T21:08:09Z 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.

Tim White
tag:timwhite.digital,2013:Post/855641 2015-05-17T17:31:16Z 2015-05-17T22:23:15Z 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.

Tim White
tag:timwhite.digital,2013:Post/843218 2015-05-02T11:20:45Z 2015-05-17T22:18:33Z 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?

Tim White