tag:notoriousbfg.com,2013:/posts Tim's Blog 2021-01-11T13:08:17Z Tim White tag:notoriousbfg.com,2013:Post/1637164 2021-01-07T18:00:00Z 2021-01-11T13:08:17Z Code and Context

Last week I wrote a post called "Code Age vs Time to Recall" that briefly graced the front page of Hacker News. I'd recommend you read it before this one. Ironically it's one of the few posts I've written that didn't call for at least one redraft; at the time of writing it's been viewed nearly 4000 times (my most-viewed post by far.) In summary, I spoke about the way old code is often perceived to be bad in development teams because it takes longer to recall. How can we reduce this "time to recall" by writing code that's easy to remember? And to what extent are we responsible for sharing the context around our decisions with others?

Remembering things plays such an important role in our work as developers: strands of conversations, Slack messages, Trello cards, spec documents. All of these different sources only increase our cognitive load; at some point we're bound to forget something. I think if we're able to parse and condense a complex set of requirements into code form, we owe a courtesy to our colleagues (and future selves) to explain the context to our decisions, to help them understand why we did things a certain way.

While it would be futile to attempt to commit to memory code we didn't interact with very often, we can speed up the process of recall by writing code that's easy to understand. Doing so might involve using certain build tools or linters or ensuring the formatting of our files is correct; as one HN commenter said, "Painful now, pleasurable later, hopefully."

Where a few years ago I might have scoffed at the idea of a temporary variable, variable names can themselves convey meaning (assuming creating one isn't detrimental to performance) and the same applies to class and function names (language permitting) which serve to structure and expound the code they encapsulate. We often talk about names being too verbose (wordy) but sometimes verbosity is a superpower. Much better is it, in my opinion, to overcommunicate what something does and why it is, than to risk its purpose being unclear in a month or year's time.

Git commit messages are extremely valuable sources of context. An underappreciated feature of Sourcetree is that you can search for past commits by message (and file change.) A well written commit message should both describe what changed and why, for example, "Replace duplicate Task markup with CommentList component". If I can understand the context to a decision merely by reading a commit message, my time to recall is significantly reduced. Alternatively there is some context to be found in the date of the commit and the branch name, which might also tie in with a pull request. As an aside, I've always written my commit messages as imperatives (so they can be read in order as a list of instructions) but I'm sure there are other conventions for this.

Some of the comments on last week's HN post spoke of automated testing, which itself serves as a form of "functional documentation". Tests are the link between a set of requirements (potentially a non-technical document) and code. Again, if we're able to understand the requirements surrounding code, the time to recall is lessened. In many ways, tests also provide a kind of "entrenchment" in that they prevent unnecessary changes being made later on. If a test fails as a result of a refactor, the code no longer meets the requirement.

Not only do we often make decisions in code as individuals, but often we make decisions with other developers in pull requests. Not only is the clarity of what you say important to the developer making the changes but the more information you can supply (references to files by name, line numbers etc), the more easily you or one of your colleagues will find what they need at some point in the distant future. I'd go as far to say that you should write your PR comments with the assumption that they'll be read again by someone else at a later time.

Whether formally acknowledged or not, I think all developers are responsible to some extent for reducing the "time to recall" the context surrounding our code. We owe it to ourselves and our colleagues to share as much of this context as possible, in code, in commit messages, in tests and in pull requests so that old code can be understood just as well as the new.

Tim White
tag:notoriousbfg.com,2013:Post/1635774 2021-01-04T18:00:00Z 2021-01-05T00:08:37Z Tell people something new

A conversational technique I learned recently (not that I think about all the things I say with such intention) is to tell people something they don't already know.

We're much hungrier for new information (even mistruths) than we are for truths that we already understand. Take for example the fake news headlines that seem to circulate on social media; we'll often choose to read and share something we suspect is probably only partly true over something that we think is true but widely known.

I suppose telling your audience something new is just one tenet of good storytelling, which all humans are drawn to. The experience we have of reading an immersive novel or a fascinating biography for the first time we can never have again, even if we experience if differently on reads two and three.

When talking about oneself, it's also more impressive to tell others something new. For example, friends and family will be far more interested and impressed when you tell them about the skydive you did, rather than the one you're thinking about doing.

Tim White
tag:notoriousbfg.com,2013:Post/1635170 2021-01-03T13:00:00Z 2021-01-06T00:31:51Z Code Age vs Time to Recall

A colleague of mine has repeatedly called for some of the controllers in our project to be refactored. He says they're messy, but what I think he means is that they're hard to understand. At first glance they do seem complex yes but upon closer inspection:

  • There are step-by-step instructions in the comments explaining what's going on.
  • Variable and method names are descriptive but not overly verbose.
  • The code is spaced, formatted and indented correctly.

I can see why my colleague might see the code this way; it does have multiple concerns, but it came to be this way iteratively over the course of two years. Everything it does relates to a previously-defined requirement i.e. it does what it's supposed to. We also haven't made any changes to it for several months because it hasn't caused any bugs nor are there any major performance bottlenecks.

One common developer bias is that old code is bad. You've never heard anyone say the phrase "legacy code" without contempt in their tone. I can appreciate that sometimes old code doesn't conform to newer practices agreed on by a team. For example, legacy PHP code might use the now-deprecated PSR-2 standard, but the tech lead might want everyone to write PSR-12. But is this really a good enough reason to potentially jeopardise a piece of working functionality?

I think the reason old code is often seen this way is because it takes longer to remember. Developers yearn for clarity but if they're not immediately able to recall under what circumstances some code was written (in a few seconds or less), they only see ambiguity.

Even when we talk about code, when we're able to recall previous conversations/decisions/motivations quickly, we can talk about it confidently and convey to others that we understand it well. Unfortunately saying, "I need five to ten minutes to refresh my memory of this" doesn't convey the same sense of confidence. Always prepare.

Part of the solution to reducing this "time to recall" is through better internal documentation. We use a tool like Codestream but I'll admit that context is not always captured; sometimes it's the "why" not the "what" that's relevant. In my opinion, good old-fashioned comments work best; I try to write mine like a numbered set of instructions. Of course you can also convey meaning with your git commit message.

The other part of the solution is to agree as a team under what circumstances code should be refactored. If your team collectively agrees that stable, well-documented code should be refactored, run.

Tim White
tag:notoriousbfg.com,2013:Post/1633738 2020-12-30T15:36:14Z 2020-12-30T15:36:15Z Side Project Zen

I haven't written anything here for a while. I think it's because I haven't had as much focus. An article I read recently spoke about covergent and divergent modes of thought and I've been exploring lots of different things as opposed to focussing on a few. The Christmas break is a great time to reflect, blocking out other creative stimuli, something songwriter St Vincent calls "Nun mode".

Tim White
tag:notoriousbfg.com,2013:Post/1600390 2020-10-04T10:43:28Z 2020-10-04T10:43:28Z The illusion of technology
Google is advertising its new Pixel 4a as the "cash saving phone" which seems totally ironic to me because buying it would leave me £350 out of pocket. Google will also recuperate a lot of value in the sale of my data.

We're convinced to buy new devices by the prospect of the changes they'll bring for us in our lives: productivity, social connection, creativity, but invariably they don't do anything like that for us at all. Modern mobile phones aren't designed for doing or creating anything they couldn't for us ten years ago (sending messages and sending & receiving phone calls.) Your next phone won't make friends for you like the ones in the adverts; it won't help you get fitter or be twice as productive; it certainly won't make you more relaxed. Those are all problems a device can't solve for you.

No, these devices are designed for mass consumption. Consumption of social media, video, games and web content. Every aspect of the iOS or Android interface is geared towards giving you immediate unfettered access to content so you can consume energy, bandwidth, data, time and... advertising!

Perhaps underneath our lust for new technology we all know this? And we simply buy new devices to stave off the reality that the problems in our lives can't be solved without effort.

I think there are much better things to spend the £350 (or even the £1k Apple seems to think is appropriate to charge for a device that costs £20 to make) on. If you want to be more productive, take the advice of notoriously productive people. If you want more friends join a club, or perhaps even send a message to your current ones (especially during this pandemic while they're probably alone.) If you want to be more creative, take painting lessons. You already know this; you just didn't want to believe it.

Tim White
tag:notoriousbfg.com,2013:Post/1593697 2020-09-13T12:15:07Z 2020-09-13T12:18:39Z Success is Relative (updated)

In 2017, on a previous version of this blog, I wrote Success. Certainly at the time the conclusion I'd come to was revelatory for me. For years I'd help up these absolute examples of what I thought success was: starting a successful business; having a novel published; winning a prestigious sporting event. If you hadn't accomplished things in this order of magnitude, you weren't successful. In fact, I'd thought only a small proportion of people could truly consider themselves successful.

The realisation I came to at the time was that all forms of success are relative. There isn't one definition or "threshold" one must surpass to be successful; success pertains to the individual. Of course we can say that Usain Bolt is a successful athlete for breaking the world 100m record or that Warren Buffet is a successful businessman but these accomplishments are beyond the reach of the vast majority of mortals.

A couple of weeks ago on Hacker News I asked the question: "Is it possible to be objectively good at something?" I was really pleased with the range of really quite thoughtful responses I got back (and my question even touched the front page for a brief moment) but my favourite answer was this one from AnimalMuppet:

"Objectively" means that someone should be able to unambiguously tell, without having to apply any judgment.

And yes, it's possible. Am I objectively good at calculus? I passed the AP test. That's an objective measure.

But it's not that simple, for at least two reasons. First, it's always possible to question the "objective measure". Is the AP test a good test of whether someone is good at calculus? AP says so, but that's not actually any help. College admissions departments think so, too. But grad school admissions people don't think so at all, and neither do math department hiring committees. This shows the problem: There is a measure that can objectively be met or failed, but is it the right measure? How can you tell? Not objectively.

Second, in many fields, there is no analog to the AP test. Is Tolkein a good writer? Is the Mona Lisa a good painting? There is no clearly objective measure. The only measure is that many people think so; more people than think, say, my daughter's watercolor is a good painting. That's subjective, but at least it has the merit of being subjectively shared by many people. And with something like Mona Lisa, it's shared by many people across many years - it's not just today's fad. That's still subjective, but it's at least a subjectivity that has widespread agreement to it.

It's a very comforting response because while they acknowledge that "there is no clearly objective measure", no test that can measure how "good" something or someone is (or that cannot be questioned), they also recognise that to be "good" is totally subjective. The closest thing to any kind of definitive measure of how good something we have is "the merit of being subjectively shared by many people."

I think it's very important to focus on the subjectivity of what is good. It would be dangerous of me here to confuse being "good" at something with success, to say that an individual's success depends on the number of people to have shared and agreed that what they've done is good, especially in this current age we live in. It's perfectly possible to be good at something but not be considered "successful". Take the footballer Phil Jones for example. Despite having one of the best clean sheet records in the Premier League, most fans would not consider Jones to be a success.

No, if success is subjective then it's an internal matter and hopefully this is the last time I'll ever need to write about it again.

Tim White
tag:notoriousbfg.com,2013:Post/1574912 2020-08-16T12:15:42Z 2020-08-16T12:17:39Z Leonardo da Vinci, master of "Fake it 'til you make it"

At aged thirty Leonardo Da Vinci wrote a letter to the Duke of Milan, Ludovico Sforza explaining why he should be given a job in the court there. It read as follows:

Most Illustrious Lord, Having now sufficiently considered the specimens of all those who proclaim themselves skilled contrivers of instruments of war, and that the invention and operation of the said instruments are nothing different from those in common use: I shall endeavor, without prejudice to any one else, to explain myself to your Excellency, showing your Lordship my secret, and then offering them to your best pleasure and approbation to work with effect at opportune moments on all those things which, in part, shall be briefly noted below.

1. I have a sort of extremely light and strong bridges, adapted to be most easily carried, and with them you may pursue, and at any time flee from the enemy; and others, secure and indestructible by fire and battle, easy and convenient to lift and place. Also methods of burning and destroying those of the enemy.

2. I know how, when a place is besieged, to take the water out of the trenches, and make endless variety of bridges, and covered ways and ladders, and other machines pertaining to such expeditions.

3. If, by reason of the height of the banks, or the strength of the place and its position, it is impossible, when besieging a place, to avail oneself of the plan of bombardment, I have methods for destroying every rock or other fortress, even if it were founded on a rock, etc.

4. Again, I have kinds of mortars; most convenient and easy to carry; and with these I can fling small stones almost resembling a storm; and with the smoke of these cause great terror to the enemy, to his great detriment and confusion.

5. And if the fight should be at sea I have kinds of many machines most efficient for offense and defense; and vessels which will resist the attack of the largest guns and powder and fumes.

6. I have means by secret and tortuous mines and ways, made without noise, to reach a designated spot, even if it were needed to pass under a trench or a river.

7. I will make covered chariots, safe and unattackable, which, entering among the enemy with their artillery, there is no body of men so great but they would break them. And behind these, infantry could follow quite unhurt and without any hindrance.

8. In case of need I will make big guns, mortars, and light ordnance of fine and useful forms, out of the common type.

9. Where the operation of bombardment might fail, I would contrive catapults, mangonels, trabocchi, and other machines of marvellous efficacy and not in common use. And in short, according to the variety of cases, I can contrive various and endless means of offense and defense.

10. In times of peace I believe I can give perfect satisfaction and to the equal of any other in architecture and the composition of buildings public and private; and in guiding water from one place to another.

11. I can carry out sculpture in marble, bronze, or clay, and also I can do in painting whatever may be done, as well as any other, be he who he may.

Again, the bronze horse may be taken in hand, which is to be to the immortal glory and eternal honor of the prince your father of happy memory, and of the illustrious house of Sforza.

And if any of the above-named things seem to anyone to be impossible or not feasible, I am most ready to make the experiment in your park, or in whatever place may please your Excellency – to whom I comment myself with the utmost humility, etc.

At this point in time Leonardo had only a handful of unfinished painting commissions to his name but there's no evidence to suggest he had any demonstrable experience building "big guns, mortars, and light ordnance" or "catapults, mangonels, trabocchi, and other machines of marvellous efficacy." In fact, only does he mention his ability to paint and sculpt in the final point.

In his mind Leonardo was more than just an artist. With limited schooling he taught himself about anatomy, fossils, the flight of birds, the heart, optics, botany, geology, water flows and weaponry. He would use his understanding of painting and light to further his understanding of science, making discoveries that wouldn't be documented until centuries later.

But it was his almost limitless self-belief and his indulgence in fantasy that would allow Leonardo to envision flying machines, giant crossbows and his "ideal city". He didn't need qualifications or to belong to a guild to have evidence, in his mind, that he was capable of building such things. If he said he could do it, he could.

Tim White
tag:notoriousbfg.com,2013:Post/1546736 2020-07-19T15:00:00Z 2020-09-13T11:20:01Z The Impact of Culture

We're often told a business' culture is secondary to its other functions (growth, profit, survival etc.) I imagine that many companies facing the threat of recession don't consider their culture to be of immediate concern; understandably it will be irrelevant if they cease to exist. But as I explain in this article, it has the potential to become a strong force.

What do I mean by culture?

It's the way a company behaves. I think the following extract from Ben Horowitz's book "What You Do Is Who You Are" most succintly describes this:

The right answers for your company depend on what your company is, what it does, and what it wants to be. In fact, how your employees answer these questions is your culture. Because your culture is how your employees make decisions when you're not there. It's the set of assumptions your employees use to resolve the problems they face every day. It's how they behave when no one is looking.

Culture is both the product of a company's behaviour (the collective behaviours of its employees) and an indicator of the organisation's relationship with its people.

Culture is not a set of values

I think the confusion between "values" and culture is why so many businesses seem to get it wrong. Values are aspirational; they describe what a business wants to be but may not have any correlation with how it actually behaves and operates. Unless used to guide decision-making, values do not indicate culture. Culture cannot be merely decided on or chosen, but guided and nurtured.

Why bad cultures lead to failure

In order to survive, a business must continually generate and implement new ideas. There are many external and competitive forces (commonly known as Michael Porter's "Five Forces") that shape how a company operates. Its ability to articulate and implement ideas so that it may adapt to these forces is what will determine whether it succeeds or dies.

Where a poor culture is present, a business cannot hope to thrive: It may not reach its sales targets, it might have a high staff turnover or the quality of work may deteriorate.

The conditions for growth

If a Biologist creates the conditions for a cell culture to grow, a business leader must carefully cultivate the conditions in which their employees' behaviours evolve. While some behaviours can be encouraged and rewarded, others may emerge of their own accord. While a manager assigns and delegates work, a healthy culture is the mark of good leadership.

The actions of leaders

The actions of leaders are just one of the ways a business's culture can be influenced. Whether consciously or not, a leader may "normalise" certain behaviours in his or her executive team. For example, if a leader is particularly critical of a manager's ideas, managers are also likely to be more selective of their own team's ideas. Simply rewarding undesirable types of behaviour, like for example awarding a promotion to an employee not on merit alone may send the wrong kind of message to others. As Ben Horowitz explains in "The Hard Thing About Hard Things", this can have far-reaching consequencues:

When you are CEO, senior employees will come to you from time to time and ask for an increase in compensation. They may suggest that you are paying them far less than their current market value. They may even have a competitive offer in hand...

You might even give the employee a raise. This may sound innocent, but you have just created a strong incentive for political behaviour. Specifically, you will be rewarding behaviour that has nothing to do with advancing your business...

The object lesson for your staff and the company will be that the squeaky wheel gets the grease, and that the most politically astute employees get the raises. Get ready for a whole lot of squeaky wheels.

As L. David Marquet suggests in "Turn the Ship Around", one way a leader can reinforce desired behaviours is through immediate recognition, in other words recognising and rewarding good behaviours quickly and publicly. He writes, "Immediate recognition can be used as a mechanism for clarity."


A team's trust that their manager believes in and supports their ideas will hugely influence how they perceive the organisation's culture. A team that doesn't feel comfortable offering suggestions and sharing ideas stagnates. The following excerpt from "Turn the Ship Around" explains this:

Trust means this: When you report that we should position the ship in a certain position, you believe we should position the ship as you indicated. Not trusting you would mean that I thought you might be saying one thing while actually believing something else. Trust is purely a characteristic of the human relationship.

To establish trust, leaders must ultimately tell the truth. While sometimes this isn't as easy as it sounds, as Ben Horowitz explains in WYDIWYA, leaders can attach their own meaning to reality. He writes:

Imagine the reality you have to assign meaning to is a layoff... if you assign meaning to the layoff before anyone else, and you do so candidly and convincingly, your interpretation has a decent chance of being the one that everyone remembers.

Trust can also apply the other way. A manager must trust his or her team to carry out their work to the best of their ability. A team that isn't motivated to work hard usually has an ineffective culture, but a manager must also incentivise their staff to work hard by seeing that their suggestions are implemented. As Andy Grove says in "High Output Management":

...management has to develop and nurture the common set of values, objectives, and methods essential for the existence of trust. How do we do that? One is by articulation, by spelling out these values, objectives, and methods. The other, even more important, way is by example. If our behaviour at work will be regarded as in line with the values we profess, that fosters the development of a group culture.

Trust is paramount to any kind of healthy working relationship, but organisations that don't have some degree of trust cannot collaborate.


Business leaders must find ways for their employees to actively participate in decision-making at all levels of the organisation. Merely being told what to do by a superior is not motivating, especially when you may not agree with the reasoning behind doing the work in the first place. Empowerment involves giving employees the opportunity to influence how their work turns out; so that they can see the direct link between their efforts and the outcome.

One strategy L. David Marquet suggests, to empower subordinates and increase proactivity, is by changing the language an organisation uses. He writes:

Here is a short list of "disempowered phrases" that passive followers use:
- Request permission to...
- I would like to...
- What should I do about...

Here is a short list of "empowered phrases" that active doers use:
- I intend to...
- I plan to...
- I will...

...Eventually we turned everything upside down. Instead of one captain giving orders to 134 men, we would have 135 independent, energetic, emotionally committed and engaged men thinking about what we needed to do and ways to do it right. This process turned them into active leaders as opposed to passive followers.


How a business reacts to and learns from failure goes hand-in-hand with its attitude to trust and empowerment. A team that uses failure as an opportunity to learn is usually one that's empowered. But only teams with a degree of trust are able to learn from their mistakes. The alternative is an organisation in which employees are blamed for mistakes, creating a culture of fear. Fear is not conducive to trust. In "Creativity Inc.", Ed Catmull writes:

Ask yourself what happens when an error is discovered. Do people shut down and turn inward, instead of coming together to untangle the causes of the problems that might be avoided going forward? Is the question being asked: Whose fault was this? If so, your culture is one that vilifies failure...

If you create a fearless culture (or as fearless as human nature will allow), people will be much less hesitant to explore new areas, identifying uncharted pathways and then charging down them.

While often it's important to recognise failure, especially failure that's expensive or damaging, leaders may inadvertently create ineffective cultures by finding scapegoats. But a culture of fear is toxic and contageous. Instead leaders, must use failure to find opportunities for their teams to grow.

The benefits of an effective culture

Different organisations will have different understandings of what a healthy culture includes and the behaviours they want to encourage but ultimately the mark of all good cultures is a productive (and hopefully happy) workforce.

It's important to note that a perfect culture will never be attainable but the value of a workforce that enjoys its work versus one that doesn't cannot be underestimated.

Tim White
tag:notoriousbfg.com,2013:Post/1574284 2020-07-16T22:30:00Z 2020-08-15T16:43:27Z Substance in an increasingly superficial world

It's been several months since I left social media for good, though I decided to hang on to Twitter in the end, anticipating that I might need it for professional reasons (but LinkedIn rather ironically had to go.)

I haven't necessarily seen the quality of my real-life relationships improve as I suggested they might in my post in February, but I do have a clarity of mind I don't think would have been possible with it; I can't imagine being constantly reminded of coronavirus would have been enjoyable.

It took a while before I stopped framing my life through the lens of Instagram, imagining what the caption for the image I was going to post was going to be, instead of experiencing the moment itself. So I'd certainly say that my ability to experience the present has improved: using my eyes to look at beautiful scenery not my camera; using my ears to hear live music not my microphone. Reading Alan Watts' "The Wisdom of Insecurity" also helped me to realise this.

Something I've come to appreciate in this time without social media is our need, as a society, to "present" everything we do. Even in a non-virtual sense, it's as though unless we overemphasise the things we're interested in, they're not important. It's not acceptable to merely say "I went kayaking the other day and enjoyed it". I must declare my eternal love to the sport of kayaking or it's not of any interest to anyone. And it seems as though everyone needs to have some kind personal "brand" (and some sort of social "proof".)

I think social media's probably responsible for this. Just as we package and present our lives in a certain way online, we feel the need to do so in real-life to make ourselves seem more interesting, because "more likes in the virtual world translate to more popularity in the real world". My generation was the first to grow up with social media so it's interesting to see all these biases finally emerge from our subconsciouses.

What's more important is how I think we define our own personal value. If we're to remove others from the equation, do our interests make us happy because of the way they make us feel?

That's all that really matters.

Tim White
tag:notoriousbfg.com,2013:Post/1568808 2020-07-05T14:00:00Z 2020-07-05T15:16:52Z The Last of Us: Part II

Today's post is a little different from the kind of thing I usually write about. I wanted to write about a game I recently played for no other reason that that it resonated with me. We seem to live in an age where everything requires some sort of justification but I'm not going to try to convince you why you need to play this game. It was meaningful to me and you're reading my blog.

I remember playing the first Last of Us game four or five years ago (this was long after it had been released) and feeling a great deal of conflict about the story, but also a sense that I'd been very lucky to experience it. While I sometimes feel torn about spending my time playing games these days, I don't feel any regret having played this.

It's disappointing to see this instalment receive so much negative comment online, especially the reviews by fans on Metacritic etc, because having played both games in the series I can also say, as a fan, that I thought the story was totally mesmerising. I think it's one thing to say that you didn't like a story but another entirely to say the story didn't have any merit; but anyway I digress. It's a story that made me feel so many different emotions as a player: love and compassion, contrasted by hate and fear. Its characters are unequivocally flawed and while at times we're forced to do things that make us feel uncomfortable, at others we feel determined and self-assured. In saying this, the central theme of this story is perspective; seeing both sides.

I haven't played a better-looking game than The Last of Us: Part II. The visuals are breathtakingly realistic but also highly stylised, something I imagine that's only possible with very clear creative direction (especially considering the number of people to have worked on the game and the time it took to make). In fact, the breadth of detail and artistry is apparent in every environment you find yourself in, enhanced by extraordinarily crisp sound design and Gustavo Santaolalla's haunting score.

What's most apparent is the way the environment accentuates the story, not merely complement it. Clear intentions are punctuated by blue skies, anger and sorrow by storms and rain, uncertainty by darkness and fog. And when we're fed up of it all, our characters are returned to warmth and comfort.

I can't remember the last time a game (or any piece of mainstream media for that matter) made me feel so insignificant in a world; a feeling of genuine fear for my characters and their outcome. As players, we can only hope our characters make the right decisions for us, which in this story I feel they do.

Tim White
tag:notoriousbfg.com,2013:Post/1567275 2020-06-30T17:00:00Z 2020-07-05T15:17:43Z Does more choice make software development easier?

Lately I've been thinking more about maintaining code, our relationship as developers with the projects we maintain and the attitudes that define our work.

Perhaps echoing some of the ideas of a previous article "The Programmer's Rant Rut", I've been thinking about the way software dev has evolved such that we now have an ever growing number of technological choices (more programming languages, frameworks, libraries and methodologies.)

I imagine that most of us advocate "the right tool for the right job" approach. While in some decision areas there are technologies that seem most appropriate for the job at hand, in others a single choice of technology is not so obvious.

If I'm trying to say, choose a programming language with which to build a simple REST API, I have many viable options (so many it's not worth listing them out.) But for this simple use case there's a lot of crossover. How then, can I argue that any one language is "best"?

Removing "personal preference"

On several occasions in my career I've heard something to the effect of, "we decided to use X because it's what the Lead Dev liked at the time." Understandably in most situations it makes sense to play to our strengths. We choose languages and libraries we're most familiar with so that we can deliver a better outcome, faster.

But were we to remove personal preference from the decision-making process, on what other grounds would we decide which languages to use?

How to choose a programming language

Most programming languages exist to solve a particular problem not addressed by another.

Golang for example, is widely regarded for its speed and concurrency built-in. R is used for data analysis because of its efficiency in handling data and its extensibility.

I haven't used either of these languages well enough to be able to tell you whether these statements are correct or not; this is just what I found on a number of forums, Reddit, Quora etc. And herein lies part of the problem: Without experience using a particular language for a particular use case, how can I even be confident that the basis on which I'm choosing a language is correct?

Unfortunately I think the internet is responsible for many of the mistruths that are propagated online about programming languages and for that matter, technology. It's too easy to make it seem like you have relevant experience to someone who doesn't.

"PHP is ugly."

"Java is outdated and slow."

"Language X that came out yesterday is the best thing ever."

How important is a language's syntax to our decision? Python is widely considered to be elegant to read and write. Is Python more popular because of the way it "feels" to write? What's more "elegant" about Python than say, Javascript?

Factors like the available talent pool will come into play for businesses when choosing which language to use. In my surrounding area, the prevailing language is PHP, probably because the marketing agencies that do most of the hiring make websites in PHP-based CMS'. In London however, the situation is quite different. Variety in the available work means variety in process.

A universal language

To end, I leave you with a mental picture.

A single programming language exists with all the features of the most popular languages today. It's concurrent. It's fast. It has X, Y, Z features and a bunch of others in the pipeline. It has a massive community; the biggest of all. It's used by the biggest tech companies in the world and it's well documented.

What's unrealistic about this? What are the obstacles to a universal language existing and why wouldn't it make our lives easier?

If you think you know, leave a comment below. I'd love to hear what you think.

Tim White
tag:notoriousbfg.com,2013:Post/1565612 2020-06-26T10:00:00Z 2020-06-30T22:30:08Z Marketing must be measurable

Recently on LinkedIn (of which I'm no longer a member), a previous MD of mine wrote a post objecting to another marketer's claim that marketing needed to be measurable. His argument was that the brand impact of companies like Rolex and McDonald's was immeasurable and that the value their marketing creates extends beyond sales. It's an idea I've heard others propagate during my experience in marketing agencies and one that frankly I've never understood.

Why would any profit-making company spend money on an exercise designed to generate sales, that didn't? This seems even more pertinent to the current economic situation, with businesses forced to slash their marketing budgets in an attempt to save costs.

I can understand that for some large consumer brands, one aspect of their marketing might seek to create associations in customer's minds (e.g. McDonald's with needing a quick meal, Rolex with a wealthy lifestyle). However the rules that apply to these organisations simply don't apply to the vast majority of businesses.

How could anyone argue (for the vast majority of businesses) that marketing didn't need to represent some kind of measurable improvement? If not sales, then engagement, leads, enquiries etc. Businesses that don't see a measurable increase in these metrics are (generally) ones that don't survive. The brands aforementioned exist because people buy their products.

Tim White
tag:notoriousbfg.com,2013:Post/1554792 2020-06-05T18:05:14Z 2020-06-29T21:40:58Z Things I've tried to combat my game addiction
This is the kind of post I would have shared on Twitter if I still used it. I hope that my advice, while subjective, may be of use to whoever's reading this.

About a year ago I knew I had a problem with not just the amount of time I spent playing video games, but also the adverse impact it was having on my social life and my stress levels. Often I'd find myself ducking out of invites to socialise with friends in person because I didn't want to miss out on a session with my gaming friends (a group of people I rarely see, if at all, in person.) What's more, regularly I'd find myself more frustrated after playing than had I not played at all. Aren't video games supposed to be enjoyable?

The following are a few things I tried that have worked well:

Stop playing the games you find most addictive but don't stop playing all games altogether.

For me this was FIFA 20, which I stopped playing in October 2019, having previously played 16-19. More recently I stopped playing Call of Duty: Modern Warfare. In both instances, the source of my addiction came from the feeling that I'd be missing out if I didn't join my friends online (FOMO), but I ultimately realised my friends would have played without me anyway. It's important that you uninstall the game and in doing so are reminded why you had to stop playing it (as there will be times you're tempted to reinstall it.) Not playing these games didn't necessarily mean I had stop playing video games altogether; I found many enjoyable single player games to play in their stead.

Install a plug timer to prevent you playing past a certain time.

This strategy worked really well because I could no longer play late into the evening and consequently my sleep improved. Having a physical timer on the power outlet also means that to even change the settings you need to remove the plug, which is a huge inconvenience if you're in a game. Hopefully, in going to do this, you're once again reminded why it's there in the first place.

Find distractions.

Something I've written about here before; I wouldn't have been able to spend less time playing games had I not found other things to fill that time with. This year I've already read more books than I had in the previous three.

Tim White
tag:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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:notoriousbfg.com,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