Solid Study Habits for Coders

I’ve been working to diversify my skills over the past three years, in particular to grow as a software developer / computer programmer. To that end, I started working my way through the Launch School syllabus a few months back. I’m at an inflection point in the course right now so I thought it worth reflecting on what study habits have served me well as well as which ones I still haven’t quite managed to adopt.

Before I started, I exhaustively read through their forum comments and in-house blog posts to see how I might best approach my study time. They recommend you spend 20+ hours per week working on their course materials. With such a large investment of my time, I wanted to make sure I was getting the best return.

Core principles / Mental Models

• ‘Get Good at the Fundamentals’

This is a bit of a mantra at Launch School and I find it greatly appealing as a principle to drive how I study. It’s also useful as a heuristic to decide whether to dive deep on something, to read an article, to attend a meetup and so on. (See more here.)

• ‘Process, not goals’

I’m not sure I saw this explicitly enunciated somewhere, but given the fact that it can take around two years to work your way through the syllabus it seemed useful to keep in mind. I already have adopted this thanks to Beeminder and a really excellent piece by Scott Adams from 2013. With a somewhat long-term goal, arbitrary goal-focused time deadlines (‘finish the 202 course by May’) are less useful than something where you specify the amount of time you’d like to regularly invest into the study process.

• ‘Finishing is not the goal, mastery is.’

There’s a little bit of fetishising the idea of ‘mastery’ at Launch School, but this principle reminds me not to be in so much of a rush while working through the course. As Chris Lee mentioned in the forums, “if you’re in a rush, my question is: “where are you going?””

• (Find ways to) enjoy what is hard

This one I find quite difficult, lazy and averse to struggling with difficult things as I am. The whole skill/career of coding and wrestling with these abstract concepts in your head is one where you’re constantly upgrading your baseline of difficulty. This is rewarding in that there are always challenging problems to chew down on. This is also frustrating, though, because there’s always somewhere harder / out of reach to work towards. A number of students and TAs on the forums mentioned that having a mindset where you actively seek out those moments as opportunities for growth was a game-changer for them. (Note: strong intersections with Dweck’s growth mindset here).

Mindset

• Abandon artificial timelines

Don’t work to get through a course in x or y number of months ‘just because’. Rather, only advance if you’ve actually mastered the things in that course. This is a freeing perspective to take if you can find a way to adopt it. Society / culture encourages always keeping an eye on the clock, so this is a hard one (for me at least).

• Comparisons are odious

It doesn’t help to compare timelines. Everyone is coming at things with a different background and set of experience behind them. It also doesn’t help to compare competency / progress through the course for the same reason. It adds very little to my ability to grasp a particular topic to know where I lie on the bell curve. The only slight exception to this is knowing that the full core curriculum will take somewhere between 6-24 months to complete; this way if I am still studying it 20 years from now I can maybe recalibrate.

• Lean in to hard problems

I covered this earlier. If I have it as a sort of rubric which reminds me to lean into the difficulty whenever I encounter such a patch, then that’s useful.

• Master the current problem in front of you, right at this moment, without anxiety

Books are written one word at a time. Similarly with logic problems, or broken code or whatever, taking a calm look at something that looks knotted and gnarly is the way to approach it. There’s no need for anxious sudden movements, or huge massive changes. Work your way through things one step at a time.

• Be clear about the ‘why’

For something that isn’t completed quickly (i.e. within a few days), it pays to remember why you’re doing it. This helps with motivation, it helps reorient you to what kinds of choices you have to make, and it (often) helps remind you of some best practices around working towards that mastery.

• (Be specific)

This is sort of a sub-point relating to specifying the reason why you’re doing something. Try to specifically connect with some kind of emotion, visualise the outcome in some kind of image etc; this will help get the most of your reasons why in terms of it translating into motivation and clarity of purpose.

Practice

• Study ‘to depth’

Make sure to study the exercises or problems to their full depth rather than just completing them for the sake of moving on. A useful image to have in your mind is that of squeezing an orange. You don’t want to abandon the orange (i.e. the opportunity to study a particular problem) until you’ve squeezed every last drop out of it. There’s a point at which you’ve spent too much time, of course, but for many / most people you’re likely erring on the side of ‘making progress’ vs getting lost going too deep.

• Do code exercises

There’s lots of options for this. You probably don’t want to start out doing this when you’re still figuring out what a variable is, but fairly soon it pays to get into the habit of doing an exercise or three each day. Think of it almost like your daily workout. You’re building your muscle memory for solving problems, as well as cementing various syntactic and idiomatic phrasings. Of course, Launch School has you doing a mountain of exercises as well, so don’t worry too much about supplementing from outside the course, at least not initially.

• Reinforce concepts / theories using active recall

This is learning meta-methods 101, but always worth reminding oneself to actively test yourself. Don’t just read through notes, but keep a list of higher-level concepts or method names and then take 30 minutes or an hour once a week to type out an example or two using each of those concepts and methods. (More on this later).

• Deliberate practice

This builds on the previous concept of active recall. For me, this often takes the following shape: I’ll complete an exercise or a challenge. Perhaps I’ve solved the problem fine using my own code / approach, but when I finish and look at the ‘official’ solution it differs from mine in some (big or small) way. I’ll take a look, make sure I understand the principles around which it’s organised, then I’ll shut that page / window and try to replicate that approach myself. Sometimes, if a problem was hard enough to solve, I’ll even leave it a few days and just try to work the problem from scratch in any possible way that I can think of. I have enough of a goldfish brain that sometimes this will feel like I’ve never solved the problem in the past.

• Compare solution tradeoffs

Alongside just trying to code it from scratch yourself, it sometimes helps to compare the various approaches (perhaps adding in solutions given by other students) and seeing which might be optimum. Asking ‘why’ at this point is often a useful place to stretch towards, even though the answer to that ‘why’ is often a few modules ahead of where you are. I keep a log of these bigger picture ‘why’ questions.

• Build things

Perhaps slightly controversial amongst those taking Launch School. They don’t encourage a ‘hack and slash’ mentality but rather direct towards a more methodical and deliberate approach. That said, once you’re at a certain point, it can be useful, motivating and just practically beneficial in terms of the reps it gives you, to build something that has meaning for you or for others. At the moment I’m just working on somewhat more pure Ruby code in the terminal / via the command line, but later on I imagine this will become more relevant. (To that end, perhaps keep a list of project ideas).

Taking Notes / ‘Studying’

This is the one that people seem to have the most thoughts about on the Launch School forums. That’s possibly explained by the fact that people will know what works for them — or at least will have some patterns that they feel have worked for them in the past, in somewhat analogous situations.

• Type out all code examples manually

This one is easy to forget. When you’re following along with a video or textbook, make sure to type out the examples, however easy or seemingly comprehensible they seem. Typing not only engages your muscles, giving you an additional hook for memory, but it forces you to slow down and gives an opportunity to question what each character of a code snippet is doing.

• Take notes with pen and paper first time round

This is especially true for things that I’m not fully comfortable with. For something where I have thousands of hours of experience under my belt — the modern political history of Afghanistan, let’s say — I have more of a structure in my head and so can get away with typing notes. For the rest, like all these new things I’m learning about Ruby, pen and paper is pretty unbeatable. There’s a bunch of good science confirming that that’s the case, and it aligns with my experiential sense as well.

Some people in the forums noted how one of their preparatory tasks prior to an assessment was to type up their handwritten notes into a more formal digital reference of the course materials. I’m in two minds as to whether I think that’s going to be useful, mainly because the online documentation exists to serve that purpose. But I’m at the point where I have to decide about that so watch this space…

• Anki for things you need to remember

If I think a particular method / fact / morsel of knowledge is something I’m going to want to actively recall from memory in the future, I’ll add it to Anki. I try to follow the principles outlined in Piotr Wozniak’s essential piece entitled “Twenty rules of formulating knowledge”. (Seriously if you use Anki and you haven’t read it, stop right now and go read it).

I use a mix of cloze-deletion cards and custom templates for coding.

This card is a simple cloze deletion card. I wanted to make sure I was learning the options for file permissions as part of the command line portion of the prep course.

This card tests my ability to produce an example where I’m using the .reduce method. I try to include a bunch of these production cards since they mimic the kinds of situations / circumstances where I’d need to recall this piece of information in real life.

[Even though comparisons are odious (see above), in case it’s of interest to others, I’m just through RB101 and about to begin RB109 and I have 536 cards that I generated during the course of my studies.]

• Ask questions

Ask lots of questions. The advice given by Launch School instructors is to focus on the why questions when asking others. (The how questions are usually a matter of looking something up). I found this was broadly true. I have a reserved set of pages at the end of my notebook where I write down these questions that seem a bit outside my comfort zone.

Some of these get answered in the course of the programme. For example, I see that one of my questions was about why symbols are often preferable to non-symbols when used as hash keys. This was answered (sort of / enough to give me a sense of the answer) a few lessons later. Others are bigger issues for which there probably is no final answer. For example: “doesn’t dynamic typing force us to spend a lot of time validating input? isn’t static typing safer?”

Asking ‘why’ something behaves they way it does allows you to better develop your mental models and can be an effective way to grasp what’s going on.

• Feynman technique

I use a slight variant of this much-lauded technique. It consists of something approximate to the following steps:

1. Write the title of a topic that you want to study / test yourself on
2. Write or map out an explanation of that subject intelligible / appropriate to a non-specialist. Do this from memory.
3. Identify any gaps in your explanation / understanding.
4. Relearn / restudy / interrogate to fill in the gaps.

Part of one of my Feynman reviews that I do on Saturday afternoons

You can use narrative / diagrams to condense and clarify your explanation. For my Launch School studies, I do this once a week on Saturdays. I keep a list of new methods that I’m learning about during the week. Particularly towards the end of RB101 these started to mount up. Then on the weekend, I’d take the list of methods and test myself by writing out (by hand, with pen and paper) code that illustrated how to use each method. If needed, I’d write or say out loud an explanation relating to that method. This is a humbling exercise; you realise that you don’t know the things that you thought you knew.

• Write blog posts to explain anything that feels unclear

My last blog post is an illustration of this. I was having trouble getting what the .zip method could be used for and how it transformed things to which it was applied. So I wrote up some notes to myself in the form of a blog post.

I sometimes worry that too many of these posts — written purely for me to understand something — are alienating for those who subscribe to the blog via something intrusive like the email newsletter. I considered putting my ‘writing for the purposes of understanding’ posts in a separate location. In the end, though, I’m probably overthinking it. Like it or lump it!

• Make mental models of how things work

A lot is made of this, both at Launch School and in the wider world of study techniques. I’m not sure I have too many examples of where I’ve formally had to think through something using a mental model of how it works. I imagine this will start to be more applicable in later courses. Or perhaps it’s just that I already have some mental models for how the code behaves owing to my previous studies in coding. At any rate, I’m keen to get the most out of this but so far haven’t found it to apply too much.

• Make a cheat sheet at the end of a topic

I haven’t done this yet, though I can see how it’d be useful. For my current course and assessment, I think it’s probably hard to do — i.e. condensing the Ruby language to a single sheet of paper. But I’m reserving the right to do this at a later stage.

• Spend time reading the code of others

I tried to do this a little bit while going through the exercises. My hesitation was initially that the code hadn’t been reviewed or formally assessed and I didn’t want to absorb bad patterns from others who — like me — were likely at the beginning of their journey and who couldn’t be expected to know if they were writing something that should be emulated or not.

In the end, I think it’s still useful to read the code of others. It’ll usually be somewhat clear or not whether an answer is overly complicated. And answering why you think that is in itself a revealing process.

Review

The Launch School syllabus takes a year or two to get through. You start off with Ruby, but later on you’re working on Javascript or whatever. The concepts and the methods and the details could easily start to get forgotten if you’re not regularly reviewing and practicing things you studied in the past.

• Anki as the cornerstone for spaced repetition

As evidenced by the large number of cards in my Anki deck, Anki occupies a central place in my strategy to outsource the need to worry about reviews and recall over the long-term. If there’s something I want to be able to recall a year from now and it’s not something I’m using literally every day or two, then it’s going to end up in Anki.

An important note, though: learn the material FIRST, before adding it to Anki. I’ve learned this the hard way in the past; if you don’t learn it before adding to Anki, you’ll find Anki becomes slow and filled with a sense of drudgery. It’s also inefficient to group those two very separate tasks into a single moment at the point where you’re reviewing a card.

The great thing about Anki is that as a particular fact passes from your short term memory to your long-term memory, the need for reviews becomes less frequent, so you’ll see it less often. Trust the spaced repetition algorithm. It knows what it’s doing.

• Explain a concept out loud

This overlaps with the Feynman technique (see above). You can do this on your own, or to a friend / captive audience. Doing this with people who are much older or younger than you can be instructive as to whether you actually understand a particular topic.

I sometimes build this in as part of my Anki studies. I’ll have a card where the front says “What is [concept x or whatever]? Try explaining it out loud.” Then I’ll either find someone to do this with or I’ll just do it myself. Then on the back of the card it’ll either have a small list of key sub-concepts to make sure I got it right or it’ll say “Go look at your notes to confirm that you covered everything important”. This way I’m getting prompts to review old material, but they’re reoccurring at regular enough intervals that I don’t have to worry about having to do this too often.

• Keep Ruby / other fundamentals sharp

People in the forums mentioned that when they moved on to Javascript or other parts of the course, they found their Ruby skills starting to atrophy. Many said they wished they’d been more formal about reviewing old materials and keeping those skills fresh.

I think this is best solved by doing regular code challenge exercises as provided by sites like those listed above. I’ll use Beeminder to keep me honest and doing at least one or two every few days.

• Review old materials

People suggested that roughly 20% of your weekly study time should be devoted to reviewing old materials. I wonder if that’s a little high, but for me that might translate to keeping a solid hour or two on Saturdays for review of those old materials. And by review I mainly mean active recall using some of the techniques mentioned above, and then reading through notes to confirm whether I still knew something or not.

Getting Stuck

This is where I struggle the most with coding — the mental game of failure. But having a process to deal with those moments — because they will come — addresses a good chunk of the issue when it comes to getting stuck. The following are possible options for working through it, as suggested by fellow students / instructors:

• Read the error messages thoroughly
• First try it with pseudocode
• Solve problems on your own before looking at solutions or asking others for help. (If you can’t solve it, and depending on the size of the problem, still don’t look at the solution until a day or two has passed).
• Use the rubber ducky method of talking through a problem. (This can be translated to writing as well, where just the act of writing up where you’re stuck can often be enough to get you unstuck)
• Don’t cheat yourself of the opportunity to learn if the problem is difficult. Work through it and take your time.
• Use the PEDAC system / process

Community

Everyone studying at Launch School is doing so remotely. We’re all scattered around the world, but doing thing with others can be really helpful with motivation. I don’t always find it the most time-efficient way of studying, but working with others in a structured manner seems to be strongly recommended by posters in the forums. For me I think this will take two forms: attending the group study sessions appropriate to my particular level, and interacting with discussions on the forums and Slack channel.

I might supplement this with ad hoc study groups depending on my need for that during assessment preparation. At any rate, there seems to be a good deal of opportunity for that kind of thing among fellow students.

Habits / Meta-Structure

A lot of this comes under the rough category of ‘life fundamentals’. Most shouldn’t need too much explanation.

• Stop using / viewing social media or meaningless input — for me that’s Twitter and YouTube. I have turned this off completely outside specific windows.
• No email — I also have email turned off everywhere except outside certain windows. On my phone, I’ve set it up that I don’t have access to IMAP mail via apps or the standard ‘Mail’ app, but I am able to send mails through SMTP email.
• Be careful with caffeine / tea — I don’t drink coffee, but some varieties of tea cause me to get a little too edgy and scatter-brained. So this is just a reminder to be conscious of that and always err on the side of caution. Also, periodically taking 1-3 weeks completely without caffeine (as with salt) allows me to reset my baseline, needing less to cause the stimulating effect it has.
• Keep the house / room clean
• Go for a walk every day
• Exercise — do it.
• Sleep — this is maybe the most important item in this entire post for me.

Scheduling Study / Core Routine

• Study Every Day

I try to study a minimum of two hours every day on average, moving up to a stretch goal of three or four if I am able. This allows me to make meaningful progress in my studies. Ideally, I try to have at least one day / week which is a 3-4 hour uninterrupted slot. But probably four hours is my maximum when it comes to focused, productive work.

• Pick a sustainable pace

I could probably do a few days of full-on / flat-out work, but eventually I’d burn out. The trick here is to do enough that you can always work the next day. This means not working from a place of exuberance or excitement. Learning and coding doesn’t have to be high-octane. That doesn’t mean it can’t be enjoyable or satisfying, needless to say.

This means starting with reasonable weekly hours and slowly increasing them rather than jumping straight into an intense pace of 5 hours a day, let’s say.

For me, this initially looked like starting with 15 hours per week and I’m currently at around 18. Reaching somewhere around 25-30 would be my ideal, but I have to listen to how my mind and body responds, and have to balance other work to support (read: pay for) this course of study.

• Create a routine / habit around Launch School study

For me, this means having my studies as the first thing I do in the day. I want to give it the time when I’m at my best during the day, so that means first thing in my morning. I potter around for 30-60 minutes after getting up, and then I immediately start work on my studies.

• Block things

I covered this above a little, but basically for me it means using tools like Freedom and Focus apps to keep me honest and not distracted. I’m fairly good about using these tools, but not always and it’s easy to notice the difference.

• Take breaks

I usually segment my studies with inbuilt short breaks. These can be anywhere from 5-10 minutes and I try to get up, stretch or do some kind of physical exercise / movement. For Macs, the Move! app is a great utility. I like to take somewhere between one and two breaks per hour on average.

• Think about posture early on

This is something which I haven’t thought too much about, but people on the Launch School slack channel and elsewhere have suggested it’s important. If you’re going to spend hours behind some sort of laptop, getting posture and ergonomics right seems like a good thing to aim for. I’ve had good experiences with the Ninja Standing Desk (sadly not being produced any more, it seems!) though I don’t currently have it with me. This is something to return to in a few months.

• Take a day off

I take one day off each week which is for non-tech things, or family or friends. This is usually Saturdays for me but not always. I turn off phones and laptops and don’t let myself use them for the whole twenty-four hour period. I sometimes lose this habit when I have too many things going on and am overcommitted — witness that I’m currently writing this blogpost on my supposedly sacred Saturday ‘day off’ — but in any given year I’ll stick to it perhaps 80% of the time. The more I work on Launch School the more I’m reminded that it’s a good thing to disconnect from digital input and reconnect with the world around me.

• A routine for the end of the day

Currently the two key parts to this involve writing down what’s coming up tomorrow and where to start with them. It also includes making my environment conducive to just starting work the next day — i.e. cleaning my desk.

Walk Around the Block

People increasingly live in cities. There's a good chance that if you're reading this, you live in a city. That's good for exchanging ideas and stimulating opportunities, but it often means we don't get as much movement as we'd like or as would probably benefit us.

So here's a little trick I've used for the past three or four years. First off, you shouldn't be working uninterrupted for much longer than 45-60 minutes at a time. When you take a break from work, get up and move your body. Ideally, leave the house or place where you're working, walk round the block or the building. That shouldn't take you much longer than 5 or 10 minutes. If you're working for 45-minute segments, it's an ideal amount of time and it'll refresh you physically so that your next session isn't hampered by waning energy levels.

Try it out and let me know how you find it...

Variations on a Pomodoro

I've recently started work on a large translation project (about which more in due course). This sees me grappling with the Arabic text for several hours each day. Early on, I tried replicating my '4 perfect hours' approach that had worked so well when writing my PhD dissertation.

Translation is hard work, and tougher on the brain in ways I hadn't first anticipated, not having done it full time before. So I've found myself adjusting my 45-minutes-work, 15-minutes-rest cycle to something closer to 25-minutes-work, 5-minutes-rest (with a longer 15-20 minute gap every 4 cycles).

For writing and anything where you're trying to hold lots of pieces of information in your head, it makes sense to go for longer stretches of time if you can. 45 minutes was ideal for writing my PhD, since any shorter and I felt like I was loosing too much time rebooting all the information at the beginning of each new session.

Translation is far more piecemeal, in a way. I can work on one sentence at a time, at least in this stage of the process, so shorter sessions work just fine.

This is all just an extended way of saying that customisation is important, and whatever you read online (or hear on a podcast or whatever) needs to fit into your own life, needs and patterns rather than the other way round.

Introducing CoachBot: Your Personal Language Taskmaster

For languages that aren’t new, I often feel like I’m stagnating and get bored when I reach the intermediate levels. This can reflect a lack of materials from which to study (as was the case with Pashto when I first started studying it) or — more commonly — a surfeit of materials. This creates a kind of choice paralysis where the number of options means I’m far less likely to sit down and pick one of them. (In a similar way, I'll sometimes choose not to watch any of the in-flight entertainment because there are too many choices to pick from.)

Studying a brand new language is (almost) always fun: you’re making quick progress, everything is new so you still have that nice-and-shiny feeling, and you feel like you’re really on your way to success. Continuing that study after two to four years of effort is a little harder. Like with any longer-term project, you start having to find ways to remind yourself of why you’re even working on it in the first place. It can often feel like you’ve lost that original magic somehow, even to the extent that you question whether you actually want to learn the language.

It is useful to address some of these issues ahead of time. That way, when you hit a period of less energy or motivation, you have a pre-formulated plan of action (made by you when you weren’t consumed by whatever mood is dominant). For me, this takes the form of making lists of suggestions to my future-self. I have pre-made task lists for:

• When I’m travelling
• When I’m feeling sick
• When I have no time to study
• When I have oodles of time to study
• When I have lots of energy and enthusiasm for learning
• When I have no enthusiasm for learning

Try to have at least 10 or 15 tasks in whatever lists you do end up creating. Maybe save a few pages at the back of your language notebook to list these tasks. This way, you always have them handy. It helps to have a good amount of variety in the tasks you pre-assign to yourself.

I keep lists as described above, but they weren’t as effective as I'd hoped. I’d glance at the tasks, feel only a limited enthusiasm for the options available and then put the list to one side. I needed a different solution.

I happened to be teaching myself to program/code at around the same time, so I thought this might make an interesting practice problem to try to solve. (I was studying Python and so I found a way to make a web app that uses that to connect to Flask.)

CoachBot is the free tool I designed to solve the problem of study choice paralysis for language-learners. It’s still only a prototype, but I'm soft-launching it here now since I imagine it might help those reading who are in similar situations.

CoachBot gives you a task that you can complete within a specific time-frame. If you have only 5 minutes, it'll pick a random task from the database that I curated and wrote myself. Have an hour? It'll suggest a different kind of task. If you don't want to do a particular task that it suggests, just click a button to get a new one.

These are the kinds of tasks I suggest when working with students one-on-one. They’re also the kinds of tasks I had written down in my lists. As of writing, there are 386 unique tasks in the database, which means that the suggestions are far more varied and creative than anything I was previously using.

I’d suggest you use it as follows: if you ever feel like you don’t know what to do to keep going with your language studies, open up CoachBot, pick a time corresponding to your needs and do whatever it tells you to do. When you’re done, make a note of what you did and how long it took in your learning log. Consider doing another session.

I’ve been using this for a few weeks already and can attest to its value. One of the key benefits I’ve found is just in getting started. Sometimes I’ll only need to do a five-minute task before I realise that there was something else that I wanted to read or study and then I’ll get busy working on that.

There are lots of features that I hope to build in for future versions. I want to include user accounts and tracking of how much time you spend on the different tasks. I want to sub-divide by language skill (i.e. which skill is being trained) and eventually to build in some kind of guidance and interactivity to how the tool functions. But for now, use it as it is: get some studying done by outsourcing the choice of what you’ll be studying.

There are more details on the website itself. You can click through to the project’s roadmap where you can see an updated version of features coming soon. You can also make suggestions for tasks that you’d like included in the Bot and/or specific features you’d like me to build as part of the project.

[Special thanks to Alex, Ian, Kevin and Peter for patiently answering my questions while I was building this initial prototype].

Things We Control: On Internal vs External Goals

When it comes to goal setting, I’ve found it helps to distinguish between the kinds of goals you envision and create. I first came across this concept in a book on Stoic philosophy: A Guide to the Good Life, by William Irvine. (If you’re interested in the full details/writeup, read chapter five.)

The basic premise Irvine lays out goes as follows:

Instead of seeking contentment by trying to change the external world, rather we should think about how to change ourselves (i.e. internally).

He splits up the internal / external distinction a bit further:

View fullsize

Here you can see that there are some things over which we have complete control. There are also things which we don't completely control. This can be split into things we have no control over at all, and things we have some control over but not total. (This is actually a trichotomy derived from the philosopher Epictetus.)

An example of something we have no control over at all is when the sun rises. Things that we have some control over but not total are generally impulses, desires and aversions, so you can control your attitude in a certain situation or what kind of effort you put into a language-learning exercise. Things we have complete control over include our opinions, the goals we set, the values we consider important and our character.

This is a really useful way of splitting things up, and you can maybe see why it might be useful. We should spend no time at all thinking about or worrying about the things that we have no control over at all. In terms of language learning, this might relate to any putative 'innate' or genetically-based learning ability or aptitude. You're stuck with who you are, so there's no point being upset, particularly when it comes to comparing yourself to others. (Plus, a lot of this discussion of 'innate talent' for learning languages misses the point: there are many things that one can do to speed up one's progress.)

The other two categories are really what we should be concerning ourselves with, since this is where we have the ability to influence the outcome. We can set our goals in a useful manner (as described above) and we can change our impulses and perspectives on particular tasks.

The practical realisation from all of this, for a language learner, is that it really makes sense to find ways to set internal goals as opposed to external goals.

Think of a game of tennis, for example: you might have a goal to 'win the match'. This would be an externally facing goal. It is one over which you don't have complete control. Your opponent may have advantages over you that you can't anticipate or prepare for.

Alternatively, an internal goal might be to 'play my best'. This has the advantage of being something you have full control over (i.e. how your effort is directed) and it is not something that can be refuted or quashed by your opponent on the court. Even if you lose the match, by taking this perspective of 'doing one's best' you'll be able to take solace in the fact that there was actually nothing you could have done to change this outcome. Plus, you met your goal (presuming you did actually try your best).

In terms of language-learning, this translates to formulating your goals in terms of process rather than fixed targets. So: rather 'study for 10 minutes every day' than 'reach a B2 level by September'. This way, you're setting yourself up for success and you can focus on what matters in your studies without the feeling of pressure. Same thing with something like writing a PhD. (I've written elsewhere about how you can think of writing a PhD in terms of time rather than wordcounts or sections completed.)

I hope I've convinced you that goal-setting can be an important lever in how you tackle the meta-goals of your language-learning journey. It's certainly been an important realisation for me in how I setup goals and intentions. It also works really well with commitment tools like Beeminder, though that's a topic for another day!

[This is an edited excerpt from my new book, Master Arabic, now available for discounted pre-order here. Use the offer code 'preorderthankyou' at checkout to get 10% off.]

Notification Zero

As I reach the final stages of a major project, I’ve been saying ‘no’ more often. I’ve been turning down work, conferences and all the little things that take away from my ability to focus for hours at a stretch.

The other day I realised that my usual clampdown on notifications on my various digital devices wasn’t as tight as I ideally prefer, so I turned them all off. (You can read how to turn off iOS notifications here, and Android notifications here.) I’m writing down the various parts of this in case it’s useful to someone else in the midst of a big project.

In practice, this means the following:

• no badges on apps on my screen. (The software on your phone is designed to be addictive, to make you spend more time using it. I already live my life in black-and-white so that’s a start, but removing app badges is the next step.)
• permanently set to airplane mode. (This is easy for me as my work or life doesn’t ever really involve receiving phone calls, but it removes the chance of business / telemarketing distractions.)
• all other apps’ notification permissions turned off. (If someone messages me on WhatsApp or Signal, I will never ever get a notification about it. My phone won’t make a noise, nor will there be any badge showing that there are people who tried to get in touch with me. The only way I’ll ever see if anyone wrote to me on a messaging app is to open up that app. I do this perhaps once a day, sometimes only a couple of times a week, but I’ve conditioned myself to this level of withdrawal over the past year or two).
• Email permanently disabled on my phone. (Email is the big focus killer. If I generalise, it amounts to a box of other people’s requests on my time. So I have no way to receive email on my phone. I have things set up that I can send email (i.e. I’ve installed the SMTP login details but not enabled IMAP), but no way to receive it.)

I have a fixed schedule for things like checking email: two windows from 12-1pm and 5-6pm. Outside those windows, my email is disabled (using Freedom) so there’s no way for me to access it. On my laptop, a whole bunch of other sites whose addresses are easy to type and get lost on, I pre-empt my worst self by just disabling them during the day. Problem solved.

Whenever I write a post on this blog, it auto-posts to Twitter, Facebook, Linkedin and Tumblr. While the temptation might be to check to see who has commented on it and so on, by locking myself out on a specific schedule, this means I can choose to look at these things at the end of the day, if I really need/want to.

Highlights + DevonThink = Pretty Great

I’m late to the Highlights party, but I’m glad I got here.

Like many readers of this blog, I get sent (and occasionally read) a lot of PDFs. In fact, I did a quick search in DevonThink, and I am informed that I have 52,244 PDFs in my library. These are a mix of reports, archived copies of websites, scanned-and-OCRed photos and a thousand-and-one things in between.

Thus far, my workflow has been to read PDFs on my Mac. Any notes I took while reading the file were written up manually in separate files. I would laboriously copy and paste whatever text snippet or quotation I wanted to preserve along with its page reference. These would be fed into DevonThink’s AI engine and magic would happen.

Now, post-Highlights-installation, my workflow is much less laborious. I can take highlights in-app, export all the quotations as separate text or HTML files and have have DevonThink go do its thing without all the intermediary hassle. If you’re  a professional researcher or writer using DevonThink as your notes database — and quite frankly, if not, why not? — the Highlights app will probably please you.

Scratching Below the Surface with David Heinemeier Hansson

I’m part-way through listening to a podcast interview with David “DHH” Heinemeier Hansson, creator of Ruby on Rails, author of Rework and Remote and co-founder of Basecamp. I wanted to write down some brief notes on what came up so far before I forget. I may return to this thread after I’ve finished listening to the rest. These are just some of the points that stood out for me from the conversation; I’d strongly recommend you give it a listen yourself, especially if you’re interested in coding, systems thinking, improving and learning new skills and so on.

• Curiosity — this is a skill worth cultivating. There are various metaphors often used for curiosity, but in the podcast DHH talks about the need to ‘dig / scratch below the surface’. He talks about how finding the thing in the topic / skill / domain that interests him is often a case of just keeping burrowing down until you find it.
• Learn What You Need — DHH talks about learning to code as a way of solving a particular problem, and about learning only just enough rather than diving into that learning as a pure pursuit needing you to learn everything.
• Systems Improvement — this isn’t explored that deeply in the part I listened, but it was a good reminder that there is a way of thinking about improvement that sees improving the system as the way to improve the skill.
• Time / Flow — DHH talks about driving racing cars and how time really flies when he does this. This is an observation that this, for him, is a skill he is enjoying learning, and one that gives him a great sense of that satisfaction that comes from doing a rewarding activity at just the right level of difficulty.

More on this to follow (maybe).

Fundamentals Versus Hacks

I was talking to someone a couple of days ago who pushed back a little against some of my recent posts. In particular, she was resistant to the idea that there were special techniques or skills that could be learnt that might help with writing, studying and learning.

I obviously disagree with the premise that we can’t get better at the things we do in a domain like learning, but it encouraged me to define the core principles as something separate from the less important lessons.

I’m writing something on the specific question of software — i.e. do we really need to buy all this expensive software to be able to do great work — so I’ll set that part of the problem to one side for now. For the rest, I think it’s useful to make a distinction between fundamentals and ‘hacks’.

The idea of a hack or ‘lifehack’ has garnered a decent amount of criticism over the years, often for good reason. Whole sites exist to tell you small things you can change — little tweaks to the way you’re already doing things — that will supposedly free you up to do the important work. My experience is that these are mostly cosmetic changes, and that they don’t deliver 10x (or more) improvements. The only time when you should be looking for tweaks of that kind is if you’re already in the 99.9% bracket for what you do.

For whatever reason, people seem to prefer the idea of hacks to fundamentals. Perhaps because fundamentals are harder to change, more ossified and because to change a fundamental belief or practice is to question who you are on some level.

A preference for hacks is why people think that drinking some new type of tea or a particular kind of food is better for their ability to make decisions in the long run than simply making sure to get enough sleep.

I have read a lot in and around the productivity / health domain, and there’s a strong tendency towards these small ‘hack’-like tweaks. But what are the fundamentals? I think often a lot of that comes down to things we already know:

• get more sleep
• eat more vegetables
• move your body more
• prioritise the long-term over the short-term
• Find a way to do the ‘hard thing’ earlier in your day

Some other principles that I’ve found useful:

• Subtract first, then add — if you can find a way to simplify your current process (or whatever it is) by taking something away, I’ve found that that really helps. This can apply to big things (like the conflict in Afghanistan and the international involvement there — see this for more) as well as smaller things (your daily work schedule).
• Perfect the process; think less about results — I’ve noticed this most profoundly in my exercise and movement work over the past few years. Whenever I’ve focused too much on the hoped-for results of a particular routine or programme, I’ve had things go wrong (either injuries or setbacks of other kinds). When I stay focused on the process, trying to make each movement as good as I can, trying to stay mindful of where I am on a particular day vs where I want to be, then I find this really beneficial.

The fundamentals are low-hanging fruit that offer big returns, albeit in a slightly less sexy packaging. Hacks are shortcuts that offer minute incremental improvements, at the expense of your time and energy.

There is a time and place for tweaks and fine-tuning and smaller productivity wins, but unless you’re finding a way to sort out your fundamentals, you’re missing a great opportunity.

Seeing The Forest But For The Trees: On Exist.io

So many services, so much data. How can I make sense of it all? You’ve probably had this thought yourself on occasion. You have your Fitbit data, your calendar data, your email data, your task management system, your last.fm music data and so on. All of these things exist in their own silos.

If you’re halfway intrepid, you’ve maybe even made efforts to liberate your data from these prisons. Best case scenario: you’re left with a half-complete .CSV file that is incompatible with all the other .csv files you’ve downloaded from other services. Now, if you want to hook all these files up together, you’ll have to clean them up, massage the various tables and forms so that they match up. And then you’ll have to perform a whole host of calculations in order to figure out how you’re doing, or what the data has to tell you.

Collating all this data and making sense of it can be a full-time job in and of itself. I admire those who give talks at institutions like the Quantified Self, telling tales derived from the past 20 years of financial tracking or weight data.

Personally, I don’t have time to do all of that. I need a service to help me out, something that will serve up platters of charts and correlations that address the main broad questions that I might address of these various data streams, notably:

• how am I feeling?
• how am I sleeping?
• am I moving enough?
• am I getting enough work done?

Now you might say that it’s easy to look at each of the services individually and you’d be right. I can look at a chart over at Fitbit.com and I’ll see something that shows me all the data for the past 12 months:

This is nice, but it doesn’t tell me a great deal, aside from the fact that I seem to be walking less in Amman than when I lived next to a huge forest in a provincial part of Holland. No surprises there. Also, a whole year is a bit too much for me to process. It doesn’t really help me calibrate my current actions and my plan going forward.

Enter, Exist. I’ve been using Exist for a little over a year now, checking in on the site pretty much every day. Their own explanation for what they do is:

“We turn numbers into insights. We collect data from the services you already use and find trends and correlations in the results.”

You hook up all your web services, and your Exist dashboard will be populated with pretty graphs, useful correlations and various other goodies. These are the services currently supported:

Your dashboard page has a bunch of different panels which aggregate data from different parts of your life. For instance, my activity panel for today looks like this:

I usually go for a walk in the evenings, so I’ll most likely end today with a higher count, but you get the idea. There are panels for activity, productivity, sleep, mood, workouts, health, location, social media, music and weather.

So the dashboard is where you can come to get a snapshot of the reality of your current short-term. Exist also offers correlations and suggestions based on its combination and number-crunching of all the various parts of your data stream. This is often most interesting when it comes to your mood data. Check out these recent correlations that Exist crunched from my self-reported mood data alongside the other automated streams:

There are so many different types of charts and graphs; it’s difficult to pick my favourite ones. Here you can see my slow but steady battle to increase the amount of time I sleep every day, for example:

The mood data is self-reported. Exist sends you an email every day at a time of your choosing and you respond with a number from 1–5 alongside some comments about your subjective experience of the day. These comments are also then processed into useful charts and prompts. Weird things I’ve learned from Exist’s number crunching:

• the less I sleep, the more likely I am to have a ‘perfect’ day (i.e. 5 on the 1–5 mood scale)
• the more it rains or snows, the happier I am

You can use Exist in a bunch of different ways, depending on what you hope to get out of it. For my own situation, I love how it encourages awareness of my current patterns on the short- to medium-term timescale (i.e. one week to three months). For things like sleep, where it’s easy to forget whether you’re managing to do what you seek to do (i.e. sleep more, or get up earlier etc), Exist is really excellent.

There's a sizeable userbase who actively contribute to shaping the future of the company / service through feedback. There are a bunch of things I'd love to see happen with Exist -- changing the 1-5 scale for mood feedback to 1-10 as a start -- but the site is actively developed, and I'm really happy with all the new features that have been added in the year or so since I signed up.

You can find out the future / expansion plans that Belle and Josh have for Exist here. There’ll be more services and correlations and integrations will be more usefully presented. All of this is as you’d expect. Belle and Josh are good people (together, they make up HelloCode which is the Australia-based parent entity that produces Exist, among other things). I spoke to Belle for a Sources and Methods podcast episode; that’ll be out soon, I hope, so keep your eyes out for that.

In my interactions with Belle / Josh I’ve been really impressed with the service that they offer through Exist and their other products. I put them in my personal category of ‘nice, kind people seeking to do good things in the world through offering really useful services’. Like the team who run Beeminder and GMB Fitness, Belle and Josh offer something that saves me time and adds meaning on a daily basis to my life. Exist is a paid service. If you already run a bunch of the services listed above in the diagram, you’ll probably benefit from Exist’s charts and correlations. I hope you’ll consider signing up for their free one-month trial.

Turn Off Facebook's News Feed

Judging by the stats generated by Google Analytics and Squarespace’s own tool, over 40% of those who read my blog come here from Facebook. I’m slightly astounded by that number. It also means if I left Facebook (as I’m sometimes wont to do), I’d presumably lose all of those Facebook readers since most don’t seem to use RSS readers or anything else similar.

All of this is just by way of preamble to point you towards a neat little tool called News Feed Eradicator. I’ve been using it for the past 5 or 6 months, and it has delivered many benefits. Its function is pretty simple: turn off the News Feed in Facebook. The only thing you’re left with is the bar on the top with the little red glowy number indicator (that you won’t be seeing as a red if you turned your screen to greyscale as I previously suggested) for all the millions of notifications Facebook seems to think are important.

I only use Facebook as a sort of broadcasting platform since I do know that some people exclusively use it as a source of news and reading material. But if I have to log in to post something, I don’t want to be confronted by my News Feed and its temptations (or dissatisfactions), then I have this Chrome extension to switch everything off.

So I write this now to encourage you all to turn off your News Feeds with the extension, even though I realise this might mean you might not see the next time I post something. (There are, in any case, many other ways to follow my writings/blog: RSS, twitter and via email newsletter, for instance).

PhD Tools: Omnifocus for Managing your Non-PhD Life

[This is part of a series on the tools I used to write my PhD. Check out the other parts here.]

Discussions of task management systems have a tendency to devolve into disagreement and discord, so I'll state upfront that the choice of how you manage the various projects and goals in your life is a very personal one. There is no one single 'best' software for task management; there is only the best one for you.

One problem when writing a PhD is that it is impossible to completely isolate yourself to the extent that might be optimal for the wiriting of the PhD. Even if you're lucky enough not to have to work while you're doing your research/writeup (i.e. you have funding), you still have things to plan outside the work of your dissertation: you have to shop for food, you have to pay your taxes, you have to workout, and so on.

If you're anything like me, it's easy to ignore these tasks and let them pile up in the absence of a system or a specific place where you're storing these different commitments. There are many different approaches to both the storage of tasks as well as the precise way of implementing those tasks (the order in which you do them, for example), but the one that I've found most useful in my work and personal life is the Getting Things Done (GTD) system proposed by David Allen.

You could lose yourself on the internet reading about approaches to GTD and advocates have the reputation of being a little intense in their zeal to convert you to its glories. Suffice it to say for now that the basic idea is pretty simple: split all your tasks down into the smallest possible component and assign each task an overarching project and a context (i.e. 'working on my laptop' could be a context, so could your phone, or a specific shop in town etc). Everything else is just icing on the cake.

There has been a lot of debate as to how suitable a GTD approach is for creative professions (such as PhD writing) and I've changed my mind on this a number of times over the years since first reading Allen's original classic book when I lived in Kandahar. My current position is a blend: I think GTD itself isn't probably the best single system for the kind of complicated 'knowledge work' that creative pursuits demands. In particular, there is a certain encouragement to reduce all tasks down to little 'widgets' that doesn't quite gel with how I write. (See the recent post by Kouroush Dini which examines some of this). That said, I do think that GTD is pretty excellent as a system to contain and support everything else that goes alongside your creative pursuits. Again, I don't have that much sense of the variety of everyone's approaches to task management, but I have enough going on (and I suspect you do, too) that I need a system that is more flexible than a big long list. In particular, I need something that can ping me about things that will happen in the future (or that I have to do in the future). I don't want to see those things in the interim period, mind you, so the system is already somewhat complex.

For me, all these tools are not important or useful in and of themselves. They are means to an end, or means to a series of interwoven goals. The whole point of having a task management system should, I believe, be to reduce friction and to give you back as much time as possible to do the important work to which you are committed. This means a system that is flexible and light-weight in terms of maintenance. It means something I can carry everywhere with me (from my laptop to my phone). And it means something that won't get in my way.

With regards to the various tasks that formed my PhD process, I moved most of those over to a Trello board (as I've explained in a separate blogpost here). I generally have a specific place for creative work -- either Trello, or Tinderbox, or perhaps just a specific notebook. Everything else goes in Omnifocus.

Omnifocus itself is a Mac-and-iOS-only programme. There's a popular competitor, Things, which others swear by and I used to use. For a more cloud-based approach, some love Todoist. All three offer are based around a GTD philosophy. I like how Omnifocus works, but it may just be because I've been using it for a long time and it's what I'm used to. All have a free trial period, but you'll only figure out whether they work for you over the longer term. I would not advise constantly changing task management systems. It takes a lot of time (relatively speaking) to get comfortable with how the software works (and how you fit it into your life and workflows). Moreover, these systems aren't cheap, especially once you shoot for the mobile versions / licenses alongside the desktop version. For affordability, I think Todoist is probably your friend. For power and if you really find you click with it, Omnifocus might be more suited.

With all of these approaches, having a broader sense of what you want the software to do for you really comes in handy. I don't think it is essential to read Allen's Getting Things Done prior to working with one of these systems, but I know my own use of them wouldn't have been the same without a sense of the guiding principles. It's a quick and easy read.

Three things that I found really essential and stimulating from his book:

1) The idea of splitting things down to smaller chunks and the 'next action':

Let's say you want to host a dinner party on the weekend. You could just write a line on a piece of paper, "prepare for dinner party" and be done with it. But, as Allen pretty convincingly shows in his book, without defining exactly what that means (using sentences that have verbs in them, in Merlin Mann's useful phrasing) then you're likely to procrastinate about that particular task. You're also likely to forget things, and you'll probably feel like you're juggling a thousand separate small balls prior to getting ready for the party.

Similarly with something in the knowledge work field. If you've ever had a task like "write article" or "write chapter" or (even worse) "work on PhD" in your task list, you're pretty sure to have avoided that at some point, probably often. It is the lack of specificity that really causes problems. So Allen encourages you to figure out what is the smallest single-action next step in order to move forward with your particular project. Maybe you need to read something before you can work on your next PhD chapter. But then you realise that you don't have a copy of the book at home, so you'll have to go to the library. But then you realise your library card needs renewing before you can take it out. Finding and specifying these chains of dependencies is a really great way, therefore, to get and keep moving with your work.

2) Regular reviews:

GTD encourages weekly reviews of your tasks and projects. Since reading Allen's book, I've sometimes neglected my reviews, but I am certain that when I do block out an hour or so to make sure I am on track (or figure out what went wrong) each week, I feel much more in control of what's going on. (I even have used Beeminder to make sure I keep doing my weekly reviews in the past).

Reviews keep you aligned with the various levels of goals that you have. Allen talks about the runway level (the individual specific tasks you have to do), then the 10,000, 20,000 ft all the way up to the 50,000 ft perspective. At 50,000 ft, you're starting to talk about your purpose as a human being on the planet. At 10,000 ft, this is your list of ongoing projects. And so on. At the beginning, I was much more focused on the day-to-day actionable side of GTD, but as the years have passed I've become more convinced of the use of having these higher-level goals and perspectives.

3) 'Capture', or an inbox to store random things during the day:

This was half from David Allen, half from Merlin Mann (who in turn was inspired by Allen). The idea here is that whenever you think of something that needs to be done, or an issue that you have to handle/tackle, make a note of it. If you just try to keep it in your head, you'll either forget it, or you'll lose energy and mental bandwidth because you have too many such items hanging around.

I have a digital inbox in Omnifocus where I'll make notes of tasks or things I need to handle as they occur to me. Adding it into my inbox is easy, and I know it won't be forgotten because I'm reviewing everything at least once a week. In reality, I'm sorting through my task inbox once every day or two as well, so as to stay on top of these tasks.

I also have a paper notebook, which I'll use to jot notes down when I'm out and about, or when I don't want to be using digital technology etc. I'll transfer any tasks or notes from this notebook into Omnifocus usually at the end of every day, but if I'm particularly busy then I'll just do it during my weekly review on Sundays.

This turned out to be a longer post than expected. I barely scratched the surface of my workflow around Omnifocus but I think you'll have to develop your own if it is really to stick. Let me know if you find these concepts useful, or if you end up having some success with a task management system like Omnifocus.

PhD Tools: Turn Off the Internet with Freedom

[This is part of a series on the tools I used to write my PhD. Check out the other parts here.]

Freedom does one thing and it does it well: turning off the internet (or parts of it). It removes temptation by giving you a time slot where the internet is turned off (and no way to turn it back on) on both your laptop and your phone. [Note: at the current moment there is no Android version of Freedom, but it's been a long time coming so I imagine that will be released in the near-term future -- a recent twitter query suggested "end of the summer"].

You can run it on an ad hoc basis -- i.e. you decide that you want 30 minutes of 'freedom' starting now, click, and then you've turned off the internet. OR you can pre-schedule those times (my preference) such that you can say Every Monday-Friday, I want to turn the internet off from 5am-12 noon every day. That time will thus be core time for writing, reading or using in some other kind of productive manner, free from distractions and interruptions.

You can tweak the settings so that you're not turning off the entire internet. You can make your own custom blacklist of sites that you know are kryptonite for you. (RescueTime is a great way of coming up with that list of which sites you're sinking too many hours into, especially when you have a few months of data). I don't particularly like this selective blocking because there's always going to be a new site of some kind or other that I haven't preemptively added to my blacklist. I don't need any access to the internet for my work, actually, so it's easiest to just turn it off completely.

In short, Freedom is great for aligning your goals (i.e. write words for my PhD every day) with a reality in which there are many shiny sites and videos and social media streams to follow. If you can find a way to turn that all off (or down to as minimal a level as possible) you'll get a lot more done and feel better at the same time.