A Different Place

PhD student @ King's College, London // Co-editor of 'My Life With the Taliban'; co-editor of 'Poetry of the Taliban'; co-author of 'An Enemy We Created'

[alexstrick]

On the interpretability of models

A common criticism of deep learning models is that they are 'black boxes'. You put data in one end as your inputs, the argument goes, and you get some predictions or results out the other end, but you have no idea why the model gave your those predictions.

This has something to do with how neural networks work: you often have many layers that are busy with the 'learning', and each successive layer may be able to interpret or recognise more features or greater levels of abstraction. In the above image, you can get a sense of how the earlier layers (on the left) are learning basic contour features and then these get abstracted together in more general face features and so on.

Some of this also has to do with the fact that when you train your model, you do so assuming that the model will be used on data that the model hasn't seen. In this (common) use case, it becomes a bit harder to say exactly why a certain prediction was made, though there are a lot of ways we can start to open up the black box.

[alexstrick]

FastAI Lesson Zero: video notes

[These are mainly notes for myself, based off Jeremy Howard’s ‘Lesson 0’ video that was recently posted. It doesn’t capture the entirety of what was said during the course, but it includes pieces that I felt are relevant to me now and that might be relevant to me in the future.]

decide when you’re studying

be precise about how much time you’re going to spend

think about how it’s going to fit into your day or your life

give yourself deadlines and goals, perhaps, but also don’t worry if disruptions happen.

Mainly make sure that if something does come up, make sure you get back on the horse and keep going. (Tenacity counts for a lot)

Finish. The. Course.

make a commitment to complete the course, and make sure you actually do that.

If you’re attending the course and working through it, you should follow through on your original commitment and actually work through the course.

Finish a Project

build a project and make it really great.

You’ll probably have several projects here and there that you work on during the course of the fastai course, but at a minimum make sure you pick one of those and make it really great.

(It doesn’t have to be unique or world-changing. Even replicating something that’s already in existence can still be worth it).

Find good role models

Jeremy raises up the example of Radek Osmulski (who recently published an ebook called Meta Learning).

(Jeremy himself is a good role model too).

Learn by doing. Use what you learn and figure out the rest as you go. (Don’t get paralyzed by trying to learn ‘pre-requisites’ like complex mathematics topics, esp since most of them aren’t actually needed to become a practitioner).

Share and communicate your work

(Jeremy doesn’t mention the book, but I’ll insert here that the book “Show Your Work” by Austin Kleon is a great starter on this point).

If you consistently blog during your studies, at the end of it you’ll likely have a huge collection of artefacts of that study, showing what you’ve learned and accomplished.

Alongside that, being a good citizen and contributing in the forums etc is also a really solid way to extend whatever knowledge you have to others, and quite possibly cement things in your own mind as you reply.

How to do a lesson

watch the video / read the chapter

Run the notebook & experiment — play around with things + make sure you actually understand what’s happening

Reproduce the notebook from scratch — (and really start with nothing here, and try to reimplement whatever was done during the lesson. From previous experience, this work will be hard, but it’s super worth it. Recall learning is the best kind of learning)

Repeat with a different dataset — use the techniques you learned in the course on a dataset of your own / or solve some related problem using these techniques

Using a notebook server vs a full linux server

the notebook server allows you to get going much faster

A full linux server is more ‘your own’ and you get to also practice a bunch of other not-specifically-deep-learning skills along the way

With the fastsetup library, Jeremy has made getting going with an EC2 instance pretty easy.

Get better as a developer

just doing the course, you’ll also work on your development skills along the way

Two important things to do to help with this:

Read a lot of code

Write a lot of code

Start with a simple baseline & get a basic end-to-end solution up and running

When you’re working on a project, it’s a really good idea to start with a naive / super-basic baseline so that you know whether you’re making progress or whether you’re achieving anything with the work you’re doing.

Successful ML projects that Jeremy has seen start with the simplest possible end-to-end solution and then incrementally grow from there.

The work of getting your pipeline working / your data imported etc will take a bit of time, and if you get that all sorted upfront it’ll help you focus on the actual work you want to be focused on.

(At some point during the course) join a Kaggle competition and make a serious attempt to do your best

just getting a model on the leaderboard tests your knowledge and your skills

just work regularly on things, show up every day, try to make your model a little better each day

Do these things:

For getting a job in the space

having a public-facing portfolio of writings and projects will take you a really long way

Some companies are more interested in people having the right credentials etc and will never choose you.

Startups are a great place where this matters less.

Try to take the second course

The first course gets you going as a practitioner of deep learning, but the second course allows you to implement algorithms and models from scratch and digs far more into the depths of the subject.

Jeremy wishes more people would take part two + encourages them to do so.

The fastsetup library is great for installing everything on a Ubuntu machine (like an AWS EC2 instance)

Experiment tracking software

The two big players are TensorBoard and Weights & Biases.

Jeremy doesn’t use these. Finds it too tempting to spend your time watching your models train instead of doing something else that is probably more valuable.

There are some cases where it might help to use this software.

Weights & Biases seems like a good company to work for & they’ve hired FastAI grads in the past.

[alexstrick]

Getting Out of the Intermediate Language Plateau: Arabic Edition / Principles

[This is part of a series on getting out of a language-learning plateau at the intermediate-advanced level. Check out the other parts here.]

Seasoned language learners are familiar with the concept of the 'language plateau'. If you're learning a second language for the first time, you will inevitably reach a point in your studies where your progress seems to flatten. You will find this place and period extremely frustrating.

When you are in your plateau, it's hard to improve because you're already at a point of (some kind of) self-sufficiency. You can express yourself. You understand most of what is going on in a conversation or TV series you watch. You can write things and people will understand what you're saying. You could (and many do) stop your studies at this point and still be 'functional' in the language.

Getting out of this flat, dead zone is what I want to talk about today. It's hard, but it's by no means impossible, and making this kind of progress is possibly the most valuable work you'll do in your language studies, because all of it will be specifically tailored to your needs.

The starting point, though, is to identify your current status. What can you do? You don't (necessarily) need to take a formal language certification test to get a grade, though that can sometimes be useful. The kind of measurements you want to take are more subjective. You want to take stock of your capacity in certain situations, what level you are able to achieve in different contexts (your skills in reading will be different from writing vs listening or speaking, for example) and you want also to assess your experience on the cultural level as well -- i.e. how much experience do you have navigating all the unspoken parts of culture, whether that is body language, or behaviours and so on.

Principles of Skill Acquisition

Now a slight detour into some more general principles of skill acquisition. Some of this is derived from my own personal experience, other parts from interviews with experts in this field (such as my conversation with K. Anders Ericsson, who more or less invented the field of expert performance studies), and other parts still from reading a bunch of books on the subject.

Three things are relevant here:

1) Stretch

When you're learning a new skill, you want to step outside your comfort zone. This is usually difficult work, and work that is mentally (and possibly emotionally) taxing. Thus, if you want to get better at speaking in Arabic, you'll need to speak more, but at the beginning this practice (i.e. talking with other people) will feel pretty horrible, simply because you're not used to doing it. It's a paradox that you need to do the thing to get better at doing the thing. It is this difficulty, pushing yourself a little past what you're capable of doing, that allows for personal growth. (I wrote about this in an entirely different context a few weeks ago with respect to my attempts to get better at climbing.)

2) Lots of practice coupled with speedy feedback

These two parts (practice and feedback) go together. It isn't practice alone that will allow you to improve, but rather the combination of making efforts to use new skills alongside getting some kind of feedback that tells you when you're getting it wrong vs when you're not. An implication of this, too, is the reality that this kind of practice is going to involve you making lots of mistakes. This can feel crappy, especially when you're getting immediate feedback on exactly when this is happening. You need to adopt a flexible mindset, if possible, in which you see the mistakes as indicators of growth rather than as any kind of personal or intellectual failures on your part.

3) Know what you're practicing and focus on that

This is basically Ericsson's principle of "deliberate practice":

"Rather than chilling out in the comfort of skills you've already acquired, as an expert-to-be, you're relentless about heading to the frontier of your abilities. The practice shouldn't be so difficult that it overwhelms you—that would be depressingly demotivating, but not so easy that you're unconsciously languishing. In other words, you're arranging for flow, that space where you're right at the boundary of your abilities."

See also this summary of the routines that 'experts' tend to have around deliberate practice:

They can only engage in practice without rest for around an hour. They practice in the morning with a fresh mind. They practice the same amount every day, including on weekends. They only have four to five hours of deliberate practice a day. If they don't get enough rest, they can get overtraining injuries or burnout.

If you're hoping that 'using the language' in a general and non-specific way will get you out of your plateau, you'll be disappointed. It's perfectly possible to exist in the plateau zone without improvement ad infinitum. If you want to improve at a certain skill, you'll need to isolate that element and focus on it in a targeted way. This can be vocabulary, or speaking about a certain topic, or even something as small as 'using conditional sentences'. Whatever it is, you'll only get better if you concentrate your efforts.

Customisation & Your Individual Needs

Learning languages at the post-intermediate level will be a different experience from what you are used to in the early stages. Early on, you're doing a great deal of necessary-but-boring work to learn basic patterns, vocabulary and grammar.

Once you have mastered that, and you can explain yourself in most basic contexts, you reach the point where you have to customise. There's a great deal of science and research behind this claim. Check out this talk, by the always stimulating Alexander Arguelles, for an overview of some of that research.

You'll need to pick which areas you're most interested in. This is the hard work of advanced language studies -- you pick one area or context, conquer it, and then pick another area and repeat. This fulfils the princicle of focus that I mentioned above.

To give an example from my own studies. My current big push for Arabic is to be able to read serious fiction (i.e. short stories and novels written for native speakers). I've written previously that this was a personal goal, but various realities of how modern literature is written really make it hard to take the leap into complex native-reader-level fiction (especially novels). Arab writers like to use many synonyms (for poetic effect, or perhaps as an attempt at pretension?) for words, so when reading I often find myself stuck referring to dictionaries the whole time. Fortunately, a new textbook offering graded literature at just that 'stretch' level was released recently, which is allowing me an entry point into that world. None of the texts are simplified, and the language is hard and the number of unknown words is pretty large, but it's not too far down the scale of difficulty.

On Making a Self-Study Plan

My next post will cover and offer a host of suggestions for resources you can use to get out of this plateau / dead zone. Before you start reading through and diving into things that seem interesting, I'd strongly advise you take the time to figure out your specific goals. "Improve my Arabic" is not a useful goal. It's too unspecific. Even "improve my spoken Arabic" may not be particularly useful at the intermediate-advanced level. Once you figure out your goal, write it down somewhere. Maybe stick it to your wall or on the inside of your notebook. It's good to be reminded why we're doing the work.

Once you have your goal, then you want to set yourself small targeted bursts or challenges to push out into your stretch zone. You don't want these challenges to feel like you're straining against the limits of what you are capable. You want it to be just challenging enough that you feel uncomfortable, but not so much that you are constantly questioning yourself and your abilities in any kind of fundamental sense.

The scale of these challenges will be pretty variable, so examples will span a range of tasks from taking a week to learn and read deeply in a niche topic, to something more longer-term (over six months, perhaps) like my modern literature challenge. The characteristic that you need to look for, however, is that you'll be able to tell when you're finished with the challenge. Part of defining the goal is finding a specific (and somewhat measurable) definition of what it means to have achieved what you want.

Then the rest of the trick is basically keeping moving, tracking your progress and achievements along the way. There are various ways of doing this, some of which will depend on what else you have done in this regard. You can add in things like Beeminder to encourage compliance and regularity, or you can do that in other ways.

When I work with people 1-on-1 to learn a language, a lot of what we do is figuring out this kind of ongoing goal setting and progress assessment. (If you want to learn more about this, click here and read through what I offer).

The next posts will offer a roadmap to the different resources available to the intermediate student of Arabic and some of the ways you can utilise these resources. It won't be exhaustive, but I'm pretty sure that most will find something of use in them. Feel free to get in touch if you have specific things you want me to tackle in terms of skill development in Arabic.

[alexstrick]

Arthur Samuel and the 'Frontier of Automation'

The use of neural networks / architectures is a powerful pattern, but it's worth remembering that this pattern is part of the broader category of machine learning. (You can think of 'deep learning' as a rebranding of neural networks or what was once more commonly referred to as connectionism).

In a classic essay published in 1962, an IBM researcher called Arthur Samuel proposed a way to have computers 'learn', a different process from how we normally code things up imperatively (see my previous post for more on this):

"Suppose we arrange for some automatic means of testing the effectiveness of any current weight assignment in terms of actual performance and provide a mechanism for altering the weight assignment so as to maximise the performance. We need not go into the details of such a procedure to see that it could be made entirely automatic and to see that a machine so programmed would "learn" from its experience"

Within this essay and this quote specifically, we can find some of the key building blocks of machine learning:

We have our inputs (our data) and our weights. Our weights (or the weight assignments) are variables that allow for different configurations and behaviours of our model. Our results are what the computer has assumed based on the weights and the model, and we have some kind of a metric (our performance) to judge whether this model was accurate or not. The computer then updates the weights based on that performance, tweaking it such that it tries to get better performance.

This is a slightly amended version which language or jargon that are more commonly found today. As you might expect would happen, the language used in the 1960s is in many cases different from what gets used today:

The main difference here is that we have some labels which are used to know whether the predictions are correct or not. The loss is a way of measuring the performance of our model that is suited for updating our parameters (that used to be referred to as weights).

[alexstrick]

PDP: a precursor to modern neural networks?

Parallel Distributed Processing: Explorations in the Microstructure of Cognition, a multi-volume publication by David Rumelhart, James McClelland and the PDP Research Group, was released in 1968 and is recognised as one of the most important works relating to neural networks.

They lay out eight features necessary to perform what they called 'parallel distributed processing' (which I suppose you can think of as a sort of precursor to modern-day deep learning):

processing units

a state of activation

an output function for each processing unit

a pattern of connectivity among units

a propagation rule (for propagating what is learned through the network)

an activation rule

a learning rule (where 'patterns of connectivity are modified by experience')

an environment in which the system operates

I haven't read the book, and I don't fully understand all these different pieces, but it isn't particularly hard to see the pattern of what would later come to be handled by modern-day neural networks in these features. The vocabulary used to describe it is slightly different, but you have the connectivity between neurons, and you have a process through which you update the layers…

This feels like a book that would reward returning to for a proper in-depth read later on in my studies.

[alexstrick]

Telling Cats from Dogs

One of the main ways that using neural networks to train models is different from traditional (imperative) programming can be illustrated with a specific task: let's say you want to use a computer to tell you whether any particular photo you give it is a cat or a dog.

An imperative approach might be to make a mega list of certain kinds of features that cats and dogs have, and try to encode the differences into some kind of list of logical features. But even knowing how to tell the computer how it should recognise those features is a potentially massive project. How would you even go about that?

Instead, with neural network layers, we turn that pattern on its side. Instead of this:

We have something closer to this:

So the neural networks are learning on the basis of data provided to it — you give it a bunch of images which you've pre-labelled to say 'this one is a cat and that one is a dog' and so on.

If you use transfer learning, too, you even can use a pretrained model (which is already pretty good at recognising features from images). You can then fine-tune that model to get really good at the specific task you need it to do. (Note, that's exactly what you do in the first chapter of Howard/Gugger's Deep Learning for Coders).

[alexstrick]

Two Ruby Patterns around map and reduce

When you're going to choose a method to work to transform a group of n things in Ruby, there are two broad patterns you can choose: work with a map function or work with a reduce / inject function.

This pattern choice was recently explained to me as part of my Ruby education at Launch School. I hadn't fully grokked that the choice around how you transform a bundle of things (an Array, perhaps) really can be summarised by those two options.

You use a map method when you want to transfer your array into another array of (transformed) things. (For example, you wanted to transform an array of lowercase names into an array of uppercase names).

example_array = ['alex', 'john', 'terry', 'gill'] transformed_array = example_array.map(&:upcase) # => ["ALEX", "JOHN", "TERRY", "GILL"]

You use a reduce method when you want to transform n number of things (inside your array) into a single thing. (For example, you wanted to sum up the values of an array).

example_array = [1, 3, 5, 7, 9] transformed_array = example_array.reduce(:+) # => 25

[alexstrick]

How the Internet Works

The internet. It just works. Understanding exactly how is a bit more complicated than many pieces of engineering. The more you examine the different aspects and parts that make it up, the more you see complexity concealed under the surface.

Visiting this website, for instance: it feels like a trivial thing to do, but there are many different parts making that happen, from the parts that actually transport the bits of data across the physical infrastructure, to the pieces that serve it all to you on a secure connection (ensuring that what I've written hasn't been altered by a third-party).

I've just finished Launch School's LS170 module which takes you a decent way down in the weeds to explain exactly how all of these pieces fit together to make up 'the internet'. So today I thought I'd retransmit some of that as a way of cementing it in my own mind.

At a very abstract level, the internet can be thought of as a network of networks. A network itself is a set of two or more computers which are able to communicate between each other. This could be the computers attached to a home network, or the computers that connect through a central server to a particular Internet Service Provider or ISP.

The internet makes use of a series of 'protocols', shared rules and understandings which have been developed or accreted over time. These protocols allow a computer on the other side of the planet to communicate in a mutually comprehensible manner. (If these shared sets of rules didn't exist, communicating with strangers or sending messages from one server to another would be a lot more difficult).

So once we have this top-down understanding of the internet as a bunch of networks that interact with each other, what, then, is the process by which a web browser in the United Kingdom communicates with a web server in China? Or in other words, if I want to access a website hosted on a Chinese webserver, how does that series of communication steps work to make that happen?

At this point, it's useful to make use of another abstraction: communication across the internet happens across a series of layers. There are several different models for these various layers. Two of the more common models — the OSI model and the TCP/IP model — are represented below:

At the top level — "Application" — you have your website or whatever the user comes into contact with that is being served up to your web browser, let's say. All the layers below that are progressively more and more specialised, which is another way of saying that they become progressively less comprehensible if you were to eavesdrop on the data as it were passing over the wire or through the fibre optic cable.

Let's move through the big pieces of how information is communicated, then, starting at the bottom. (I'll mostly follow the TCP/IP model since it's a bit less granular and allows me to split things up in a way that make sense). This chart will help keep all the pieces in your mind:

Note that each layer has something known as a 'protocol data unit' or PDU. A PDU is usually made up of a combination of a header, payload or chunk of data and an optional footer or trailer. The header and footer contain metadata which allows for the appropriate transmission / decoding etc of the data payload.

The PDU of one layer is used by the layer below or above it to make up its own separate PDU. See the following diagram as an illustration:

Physical Layer

Before we get into the realm of protocols, it's worth remembering and reminding ourselves that there is a physical layer on which all the subsequent layers rely. There are some constraints relating to the speed or latency with which data can be transmitted over a network which relate to fixed laws of physics. The most notable of those constraints is the fact of the speed of light.

Link Layer — Ethernet

Ethernet is the protocol that enables communication between devices on a single network. (These devices are also known as 'nodes'). The link layer is the interface between the physical network (i.e. the cables and routers) and the more logical layers above it.

The protocols for this layer are mostly concerned with identifying devices on the network, and moving the data among those devices. On this layer, devices are identified by something called a MAC (Media Access Control) address, which is a permanent address burned into every device at the time of manufacturing.

The PDU of the Ethernet layer is known as a 'frame'. Each frame contains a header (made up of a source address and a destination address), a payload of data, and a footer.

Internet Layer — The Internet Protocol (IPv4 or IPv6)

Moving up a layer, part of the Ethernet frame is what becomes the PDU for the internet or network layer, i.e. a packet.

This internet layer uses something known as the internet protocol which facilitates communication between hosts (i.e. different computers) on different networks. The two main versions of this protocol are known as IPv4 and IPv6. They handle routing of data via IP addressing, and the encapsulation of data into packets.

IPv4 was the de facto standard for addresses on the internet until relatively recently. There are around 4.3 billion possible addresses using this protocol, but we are close to having used up all those addresses now. IPv6 was created for this reason and it allows (through the use of 128-bit addresses) for a massive 340 undecillion (billion billion billion billion) different addresses.

Adoption of IPv6 is increasing, but still slow.

There is a complex system of how data makes its way from one end node on the network, through several other networks, and then on to the destination node. When the data is first transmitted, a full plan of how to reach that destination is not formulated before starting the journey. Rather, the journey is constructed ad hoc as it progresses.

Transport Layer — TCP/UDP

There are a number of different problems that the transport layer exists to solve. Primarily, we want to make sure our data is passed reliably and speedily from one node to another through the network.

TCP and UDP are two protocols which are good at different kinds of communication. If the reliability of data transmission is important to us and we need to make sure that every piece of information is transmitted, then TCP (Transmission Control Protocol) is a good choice. If we don't care about every single piece of information — in the case of streaming a video call, perhaps, or watching a film on Netflix — but rather about the speed and the ability to continuously keep that data stream going, then UDP (User Datagram Protocol) is a better choice.

There are differences between the protocols beyond simply their functionality. We can distinguish between so-called 'connection-oriented' and 'connectionless' protocols. For connection-oriented protocols, a dedicated connection is created for each process or strand of communication. The receiving node or computer listens with its undivided attention. With a connectionless protocol, a single port listens to all incoming communication and has do disambiguate between all the incoming conversations.

TCP is a connection-oriented protocol. It first sends a three-way handshake to establish the connection, then sends the data, and sends a four-way handshake to end the connection. The overhead of having to make these handshakes at the beginning and at the end, it's a fairly costly process in terms of performance, but in many parts of internet communication we really do need all the pieces of information. Just think about an email, for example: it wouldn't be acceptable to receive only 70% of the words, would it?

UDP is a connectionless protocol. It is in some ways a simpler protocol compared to TCP, and this simplicity gives it speed and flexibility; you don't need to make a handshake to start transmitting data. On the negative side, though, it doesn't guarantee message delivery, or provide any kind of congestion avoidance or flow control to stop your receiver from being overwhelmed by the data that's being transmitted.

Application Layer — HTTP

HTTP is the primary communication protocol used on the internet. At the application layer, HTTP provides communication of information to applications. This protocol focuses on the structure of the data rather than just how to deliver it. HTTP has its own syntax rules, where you enclose elements in tags using the < data-preserve-html-node="true" and > symbols.

Communication using HTTP takes the form of response and request pairs. A client will make a 'request' and it'll receive (barring some communication barrier) a 'response'. HTTP is known as a 'stateless' protocol in that each request and response is completely independent of the previous one. Web applications have many tricks up their sleeve to make it seem like the web is stateful, but actually the underlying infrastructure is stateless.

When you make an HTTP request, you must supply a path (e.g. the location of the thing or resource you want to request / access) and a request method. Two of the most common request methods are GET and POST, for requesting and amending things from/on the server respectively. You can also send optional request 'headers' which are bits of meta-data which allow for more complicated requests.

The server is obliged to send a HTTP status code in reply. This code tells you whether the request was completed as expected, or if there were any errors along the way. You'll likely have come across a so-called '404' page. This is referring to the 404 status code indicating that a resource or page wasn't found on the server. If the request was successful, then the response may have a payload or body of data (perhaps a chunk of HTML website text, or an image) alongside some other response headers.

Note that all this information is sent as unencrypted plain text. When you're browsing a vanilla http:// website, all the data sent back and forth is just plain text such that anyone (or any government) can read it. This wasn't such a big issue in the early days of the internet, perhaps, but quite soon it became more of a problem, especially when it came to buying things online, or communicating securely. This is where TLS comes in.

TLS or Transport Layer Security is sometimes also known as SSL. It provides a way to exchange messages securely over an unsecured channel. We can conceptually think of it as occupying the space between the TCP and HTTP protocols (at the session layer of the OSI framework above). TLS offers:

encryption (encoding a message so only authorised people can decode it)

authentication (verifying the identity of a message sender)

integrity (checking whether a message has been interfered with)

Not all three are necessarily needed or used at any one time. We're currently on version 1.3 of TLS.

Whew! That was a lot. There are some really good videos which make the topic slightly less dry. Each of these separate sections are extremely complex, but having a broad overview is useful to be able to disambiguate what's going on when you use the internet.

[alexstrick]

New book, new ways to order

“I was around three or four years old when the Communists led the bloodiest coup in Afghanistan. KhAD personnel were arresting the faithful. One day, a few ugly moustached men knocked on our door. My father left with them and then he never came back. We never saw him again.

“After a year, I began to understand that this kind person was no longer with me. Poverty, a cold fireplace, and my old clothes made it evident – I was an orphan. Every man with a moustache looked like my father’s murderer. My uncle took us with him to another village, and we no longer had a home of our own.”

In this way Abdul Hai Mutma’in begins his memoir of time alongside the senior leadership of the Afghan Taliban movement. First published in Afghanistan a couple of years ago, Taliban: A Critical History from Within is now available for pre-order in an English translation.

Mutma’in served as a political advisor to Taliban leader Mullah Muhammad Omar and as spokesperson. He worked in the media section of Kandahar’s Culture and Information Ministry and from 2013 onwards served as a political and humanitarian affairs advisor to Mullah Akhtar Mansour from 2013. In short: he spent a good deal of time around the senior leadership and was privy to the internal workings and machinations of the Taliban movement at its highest levels.

At First Draft Publishing, the small publishing house I started five years ago together with Felix Kuehn, our explicit agenda is to publish books that will help “give researchers, professionals and the interested public access to primary and secondary sources”. This book falls firmly into this remit. The list of primary sources relating to the Taliban (or primary-source-adjacent) is exceedingly thin, even all these years since the movement first burst onto the national and international stage. From our perspective as researchers, the more such memoirs get written, the more we are able to attempt a critical unpicking of narratives and myths that have driven both conflict and efforts towards integration. Without these raw materials, it is impossible to begin the slow and methodical work of scholarship: triangulation, verification, context, synthesis and so on.

A bit of additional housekeeping: if you want to (pre-)order Mutma’in’s book, we have made some changes to how we’re producing and delivering books. We’re moving away from Amazon as the delivery system for our content and will simply process orders manually. For hardcopy purchases, we’ll be printing copies on demand. For ebooks, we’ll distribute DRM-free copies upon receipt of payment. If you’re interested in purchasing any of our books, please visit our website to learn more about our titles and email us to place an order.

[alexstrick]

Mastery-based Learning with Launch School

It’s a new week, so we have a new podcast episode for you. Matt and I spoke with Chris Lee of Launch School about his approach to online education. We discuss the different tradeoffs and considerations that come into play when a curriculum is being put together.

To my mind, mastery-based learning — where you don’t advance to the next stage until you’ve really mastered the topic at hand — really shines for things where you have some kind of longer-term goal. Just because it’s a good approach doesn’t mean it’s easy, though. In Chris’ words:

We started this to try to figure out education. It was not a money making endeavor. So to us, teaching became the engineering problem to solve. I was not a proponent of Mastery Based Learning before Launch School. Mastery Based Learning or Competency Based Learning is not unique to Launch School, it’s a well known pedagogy in academic papers. But it’s really hard to implement.

Think about a physical classroom. Mastery Based Learning means that a student gets to occupy a seat in that classroom for an indefinite amount of time. That’s a really hard promise to make when our schools are tasked to usher through students. It’s not about training students and making sure they understand every topic, but getting people through.

You can download and listen to the episode over on the main Sources & Methods website here.

[alexstrick]

Sources and Methods Does Technology

Episode one of Sources and Methods’s new season is out today. In this interview, Matt and I spoke with the two creators of an online programme to teach the abacus.

I’ve been studying the abacus over the past few months using the RightLobeMath course and can attest to how thoroughly they build up the skill progressions. Using the web app doesn’t always feel completely polished as an experience, but it’s clear that a lot of thought has gone into the pedagogy. I’m extremely glad that it even exists at all as a service!

The rest of the season has all been recorded and edited and will be released at regular intervals. We got to talk to some amazing guests, some of whom are personal heroes / inspirations of mine from the world of technology. For now, though, you can find the first episode here.

[alexstrick]

Using Ruby's .digits method

I discovered the .digits method in Ruby the other day. As a quick illustration, it extracts the digits of a method into an array, reverse sorted.

12345.digits #=> [5, 4, 3, 2, 1]

You can optionally specify what base you’d like it to use to calculate the digits using, i.e. the same calculation as above but in base 100 would give you the following:

12345.digits(100) #=> [45, 23, 1]

Reading around a little bit, it seems that if you’re trying to get hold of the digits of a number, simply doing a .digits.reverse is perhaps an ok solution if the number is small, but at a certain point it starts to get slow. This is because .digits isn’t just ‘splitting’ the number.

For that reason, perhaps using .to_s.chars might be a better alternative. You can then use a .map function to convert the characters into integers:

12345.to_s.chars.map { |digit| digit.to_i }

I’m not entirely sure what .digits is actually used / useful for, given the speed issues.

[alexstrick]

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 toomuch 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.

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.

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 toomuch 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 documentationexists 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:

Write the title of a topic that you want to study / test yourself on

Write or map out an explanation of that subject intelligible / appropriate to a non-specialist. Do this from memory.

Identify any gaps in your explanation / understanding.

Relearn / restudy / interrogate to fill in the gaps.

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.

[alexstrick]

Using Ruby's .zip method to combine arrays

In Ruby, zip is a way to combine elements from two different arrays, albeit in a way that is slightly difficult to understand at first glance.

The documentation is a bit opaque, at least to my eyes, and the examples given take a bit of time to get your head around.

Let’s say you had an array of fruits that you wanted to distribute to your friends. You’re organised, so you have a list of your friends as well.

fruits = ["mango", "orange", "pomegranate"] friends = ["Rob", "Mary", "Holly"]

Using multiple methods and loops, it’d be fairly trivial to conjure up something to combine these two into a new array, but luckily for us .zip exists to save the day.

friends.zip(fruits)

will return:

[["Rob", "mango"], ["Mary", "orange"], ["Holly", "pomegranate"]]

This way everyone will know what fruit they’re getting.

Note that if one of the two arrays is longer / shorter than the other, the missing space(s) will be filled with nil values.

[alexstrick]

Pain: A Love Story

To go in the dark with a light is to know the light.

To know the dark, go dark. Go without sight,

and find that the dark, too, blooms and sings,

and is traveled by dark feet and dark wings.”

— Wendell Berry

“We have been conditioned to think of the darkness as a place of danger, even of death. But the darkness can also be a place of freedom and possibility, a place of equality. For many, what is discussed here will be obvious, because they have always lived in this darkness that seems so threatening to the privileged. We have much to learn about unknowing. Uncertainty can be productive, even sublime.”

— James Bridle

This is a story of pain. (The title sort of gives it away). As with babies or dreams, telling stories about pain is primarily of interest to the person directly involved. This is also not the story I thought I was writing. A few months back, I was starting to feel much better, as if the story that I began writing had changed. That one was a story of recovery, a story of lessons learned. It wasn't a story dictated from the trenches. Since then, I have been plunged back a few times into the experiential side of things. It's only a temporary setback, I keep telling myself. Nothing is permanent, especially pain.

For the past five years, I have living my days in varying levels of pain. It seems to have started with some routine wisdom teeth surgery. Or a period of intense stress in my life. I have no real answers about any of this, least of all about the beginning of it all.

What does this mean, practically speaking? What do you have? What did the doctor say? (Yes, I hear you speaking as I write). The doctors say nothing. Or they say many things, which is the equivalent of saying nothing in practical terms.

This thing I’m writing here, this is an attempt to carve out some meaning from my experience. I initially wanted to write something more abstract about the medical system, or about the aetiology of stomach pain, but what I’ve settled on is something a lot more personal. I’ve tried to capture what it’s like to be me at this precise moment in time. I have some conclusions and a sense of some pathways that have opened up ahead of me towards the end, but that’s all quite provisional.

A year or two ago I came across something called a keukegen. See the picture to the side. These are Japanese folkloric creatures. They are, in the words of one online source:

“particularly filthy monsters commonly found in populated areas. They are the size of a small dog, and appear simply as a mass of long, dirty hair. They make their homes in cool, damp, dark places, and are particularly fond of living under floorboards and around run-down homes, where stuffiness, moisture, and lack of human activity create the perfect breeding place for sickness.”

They are often cited as explanations for complicated illnesses that appear without a clear reason or pathway.

I grabbed on to the idea of externalising what I was feeling — or the cause of what I was feeling — into this shaggy creature. I loved too how this somehow allowed me to feel some kind of compassion for whatever was going on. The creature perhaps can seem a little sinister, but mostly it doesn’t seem like what you’d consider to be a scary depiction of illness or pain. There is somehow some kind of reassurance in the keukegen. It'll stick around as long as it needs; while it's here I might as well feed it and take care of it.

A lot of the experience of pain is a mental game. You get quite good at the somatic dialogue, listening to what the body has to say, sometimes reacting, sometimes choosing to just be there with it, sometimes trying to talk back. Dialogue is the ideal, you see, and not always achieved. Sometimes it's just the somatic lecture, with me trying to interpret the signals that my body has to communicate to me.

You want these signals to have meaning. You desperately want all of this to have some kind of meaning or deeper purpose. You need it not just to be empty sensation. In my more wise moments, or when I am able to step back, I realise or understand that there is no such thing as 'empty sensation'. Sensation is all there is. But at other times it feels like a disappointment.

You look to the past, casting glances at the wreckage of your life, all the things you haven't been able to do, everything you've had to turn down. You look to the future, always assessing the ways in which some decision will complicate your life in the future, the ways where you'll get something wrong or have to pay a price. These can be a bit like visiting a museum — glimpses of the lost life you'll never get to experience, everything encased in glass cases, all the plans you have to say no to, all the things you’re too scared to accept for fear of what the consequences may be.

You also lose your memory of a pain-free body. I sometimes try to imagine myself into that life, into a body where I did not feel these sensations, but it is like trying to visualise negative space. It feels like a logical impossibility.

Where to start? I have been in some degree of pain for much of the past three to five years. Memory of pain is notoriously (and, experientially) fickle, hence the huge variance in that estimate for how long this has been going on. I only started to really get serious about addressing the pain once it started to significantly affect my life and my ability to go about everyday tasks and my work.

To talk about pain is to enter a universe of metaphor and simile. There is nothing to put your hand on directly, and the measurement of pain itself is notoriously difficult to achieve in any kind of objective manner.

What does it mean for me and my day-to-day life? In the last 9 months I've often been confined to home, stuck lying in bed or on the sofa. Things that normally bring me pleasure became out of reach. They became impossible to do because I didn't have the energy, the mental space, the focus. I lost my creativity. My sense of possibility. My options. Simple things like planning out the coming month with travel for work became weighed down with what sometimes feel like astrological predictions. Nothing beyond the next hour or two seemed to exist with any certainty. I was forced to abandon any sense of the long-term future, existing instead in a tiny pod made up of the short-term.

A few months back ago, it began to seem as if things had taken a turn for the better. I had stopped taking medications for the pain. I was on a new treatment regimen. My body felt better. I started thinking that my body and my gut — and my ability to eat any kind of food — was more resilient. It's hard to convey how this felt in words — it was far more like a feeling of confidence than a particular thought or any objective measure of 'being better'. I felt like I could relax back into the experience of my life once again.

I started saying 'yes' more often. I started participating in more things outside the house. I started coming up with plans for work, for my personal and intellectual development. I started to think about travel in a timeframe looking six months ahead.

But the pain returned. I knew that feeling, the way it melded with my thoughts and my attitudes. What it did to my ability to plan, to think about the future, to move forward in my life. My vision closed down, it curtailed itself.

Instead of fanning out, opening to the world, I closed various doors open around me. I retreated to the few rooms that I knew well, and where I had some sense of control and familiarity. I adjusted my work schedule. I adjusted what passed through my mouth. I ramped up my self-care protocol, much-honed after months of trial in the trenches. This is a familiar place. I know what works — mostly — and what doesn't. I say no more often. I don't do things. I stay at home.

I put the walls back up around me. I closed myself off to experience, to the world. I returned to focusing more on what is happening right now instead of what will or might happen in the future, or in any kind of future that I want to construct for myself. This is a retreat. But it's ok, it's a retreat that is familiar, where I know what's going to happen, what kinds of pain and sensations are likely. I rest. I watch, wait and listen. What's happening in my body right now? Oh, that sensation. I know you. I've met you before. I know you.

Pain is notoriously hard to describe to those not experiencing it directly. There's an interesting history to the different attempts that have been made by medical professionals in an attempt to get a gauge of their patients’ pain levels, but the two more common methods are to make an estimate from one to ten (with ten being the most intense pain you've ever experienced in your life), or choosing between a series of smiling (or crying) faces on a piece of paper. As the subject experiencing pain, neither feels very satisfying or communicative.

The experience of pain in the moment is also quite different from the experience of pain as a long-term phenomenon. One is (mostly sensation) mixed in with some thoughts that are reactive in kind. The latter is mostly thoughts, or thoughts about thoughts — swiftly a recursive and enfolding phenomenon — where the moment-to-moment sensation falls to the background and a wider picture emerges.

Two useful words to add into the mix at this point: tolerance and threshold. Tolerance is the point at which pain becomes intolerable. Your threshold is the point at which pain breaks into your consciousness (possibly as contrasted to a kind of background feeling that's possible to ignore). I seem to have developed a high tolerance for pain over the past few years. I have grown to tolerate far more pain than other people would be able, especially moment to moment. My threshold shifts over time. I couldn't really say I have a fixed idea as to whether my threshold is high or not.

The more time you spend with pain, the more you realise how the usual metaphors start to break down. Pain is like a scale, yes; there is something that we can equate to more and less pain, but there are also degrees or different flavours of the same number on the scale. Spectrum is perhaps a better word — you can be more or less intense, but you can also be different colours on this intensity scale.

I often find that the different flavours of pain come with a colour or mood or shade association. The more time I've spent with pain — the hours really spent with the focus of my attention directed towards whatever sensations are inhabiting my body — the more I realise how many different gradations and flavours there are.

The smiley faces card method of grading your pain is more or less useless. For starters, the scale of the smiley pictures often doesn't make any sense. Why does the frown have to come before the grimace? Why is the wide-open mouth with tears the final position? It doesn't correspond to my pain scale, at any rate.

I tried to express a little of what my body feels sometimes in this drawing. It's not always like this — either the intensity or the precise flavour — but it gives you an idea. Like this piece, the drawing was just a snapshot in time. Pain never stays the same; it is always changing. This is one of the things I've learnt and that I find somehow reassuring; nothing is for ever after all. There is reassurance in that.

Most of my pain is felt or begins as a sensation in my abdomen. Following my own observations plus the investigations of a series of doctors, it seems that this is related to an imbalance of gut bacteria and some infections and weaknesses of that gut. Pain is sometimes caused by an excess buildup of gas in the gut — trapped there by who knows what — or sometimes just a phantom pain all of its own. Figuring out the precise pieces and tessellation of this cause-and-effect puzzle is frustratingly hard to do, and I gave up any hope of real answers a couple of years ago.

If it’s caused by something I ate, or if I’m experiencing some kind of flare that that moment, then I experience that as a sort of torture from the inside. The slow passage of food through my intestines is accompanied by an intense sharp pain, as if a ball wrapped in razor blades is attempting to pass through my digestive tract. Everything is inflamed, raw and highly sensitive to every single inch traversed.

That pain sometimes becomes a whole-body feeling. It'll often reach this point if I've been ignoring it — trying to push through whatever work or exertion I'm currently trying to do. The signal becomes amplified beyond the origin point (the abdomen) and booms out from throughout my body. It becomes unavoidable.

There are some second-order pains that I experience. After several hours of intense pain, I can sometimes feel a kind of tiredness or exhaustion. This is a kind of mental lack of energy. I sometimes get headaches. I sometimes find that the pain saps the energy that allow me to sustain or find my natural (or, at least, in the past it was natural / default position) default mood.

Sometimes the pain will be so strong that I have to lie down, curled up in a ball. This is my not-so-subtle invitation to spend some time with it. Sometimes I can ignore it a little but keep it in mind so that it doesn't become bigger. Sometimes it'll be directly related to what I just ate. Sometimes it appears out of nowhere. I fairly long ago abandoned the need always to find a reason for the pain's appearance each time.

Most of this is just telling stories, making up a narrative that may or may not relate to reality. And the thing with stories, I came to realise, is that they can change the pain as well. Sometimes for the better, often for the worse.

The pain is constantly changing. Never the same. There is almost always some level of pain on a day-to-day basis. There are periods of acute pain flares. This is when I need to cancel everything, give in to whatever experience my body wishes me to have. They can be predicted to a certain extent — certain things, were I to eat them, would certainly provoke such an acute episode — but sometimes come out of nowhere. This unpredictability is what makes it difficult to live or plan with any kind of medium-long term plans.

For the most part this pain I experience does not conjure up any kind of fear. These are pains I know. They are almost a kind of friendly presence by now. Old pain becomes part of the furniture. It is new pain, new sensations in new places or in new configurations, that can sometimes provoke fear. The more time that passes, the more I realise that these are all variations on a theme. They are all sensation, unpleasant sensation to be sure, albeit with something dysfunctional about the messages they send.

After a while, you start to get good at feeling the sensations in your body. Sometimes your body literally stops you in your tracks and you have to go lie down. Distraction makes things worse. You just have to be with the unpleasant thing that is happening. The pain, the uncomfortable sensations, the sense of powerlessness and the things you are unable to do. It’s useful to try not to overdo things on a particular day, or part of the day. You can push yourself, but then you won't have anything left over for the next day or for the evening. If you push yourself too hard, maybe you push yourself into pain. All the observation is a critical part of ensuring things stay manageable, within the limits of what is manageable and controllable.

You get to know certain sensations, or certain patterns of sensations. Some of them become familiar, and thus seem less threatening even if they are painful. You start to discount those sensations; they become more of the background. They become your new baseline. You aren't well, you don't feel well, you lack your full energy and aren't living as you fully could, but you just accept everything. You stop asking for help, stop going to doctors, stop considering the situation unacceptable. You accept it. Sometimes this is useful, other times not. I've found myself in that place at several points. Sometimes it's just a break, it's a space in between treatments, or its a place where you find yourself needing to pull back from engaging with the world, to pull back from hope — the hope that there is a straightforward medical answer, that the medical system can and will solve your problem.

The consequences of this ongoing pain experience are manifold and interact in complex ways. Frustration and grief are both good words to encompass these various responses.

To start with, a high tolerance for pain makes doctoring hard. After months of pain, you adopt to that pain as your new baseline. After doctors prove their ineffectiveness, you stop going to them because you know that the tools in their kit aren't able to address the root cause of what's going on.

The more the pain continues, the more I lose my trust in my own ability to interpret my own pain. In the beginning, pain seemed to mean something ("something is wrong! pay attention! fix me!”) but now after so many months of signal, of this alarm bell ringing, I have lost trust in the meaning it is trying to impart. It has become the new normal. I am more used to ignoring it, to being with it and not reacting to it, so it somehow fades into the shadows of normality.

Chronic pain is not just about the pain, as I stated above. It's also about the second-order effects, the loss of energy and of mental clarity. In periods of acute pain, or even just as a general pattern, I find that I am unable to go as fast as my mind wants me to go. I’m certainly not able to take on or handle the things that I recall being comfortable doing in the past, a few years earlier.

When I read in a book last year that fourteen percent of cases of chronic pain lead to suicide attempts, I could see and feel how that could be the case. I feel lucky that my pain ebbs and flows somewhat, but I’d be lying if I didn’t admit that the thought hadn’t passed through my mind at my worst moments.

Hospital visits mean lost work hours as well as a steady mounting influx of bills to pay.

The dietary restrictions that I've found myself adopting mean that eating out, or eating with anyone else, is more or less impossible. This narrows my social circle, already somewhat narrow to begin with. Spontaneous decisions to stay out in town, to get food as a takeaway or to attend things like conferences or work trips require intense planning and forethought. Everything needs planning and consideration ahead of time.

Then there's what it does to my mind: chronic pain can turn even the nicest person into a far shittier version of themselves.

The loss of control and freedom to choose my life's path and options is a frustration.

In periods of acute pain or when my energy is too low to participate in life in any kind of active manner, this is when I have the feeling that life is moving on around me. I am missing. I am still on this planet, joining everyone in this journey around the sun, but it is as if I am absent.

There is also an occasional anxiety and the desire to push the pain away. This is usually short-lived since it is not a useful way of relating to the pain, but it does occur and is not pleasant as a sensation.

There are some other consequences of the pain that are somehow less obvious.

I am more isolated and disconnected than ever. There is simply no way to convey the day-to-day experience — nor the energy or even the inclination — to anyone apart from a very small core circle of people. This means I can't really share the experience with anyone when I meet them or talk or interact with them, since to do so would require too much background explanation and context. So I just don't bring it up. You feel pretty alone pretty quickly when this is what's going on.

In the beginning, or in occasional moments where I've agreed to do something or other, you feel like you're getting a reputation for being flaky and cancelling appointments and or commitments. I recently had to go back through my calendar to find something from a few years back and I was struck by how many events, appointments and work commitments I'd had to cancel or pull out of at the last minute because my body wasn't up to it. Not only do other people find this inconvenient and wearing after a while, but you lose a sense in your own ability to stick to things and/or commitments after a while doing this.

Another consequence of being ill in any kind of not-so-easy-to-explain way is that you have to suffer through and tolerate other people's armchair diagnoses and well-intentioned-but-wearing interventions into your health. Everyone has an opinion. After a while you learn not to share things with people since you can't face explaining the whole story and then you can't face their explanations of what they think is going on, their presumptions to know your body better than you do, and their questions — as if you haven't already thought everything through a thousand times as to what might be going on.

If you don’t have a single-word medical diagnosis your pain is not taken seriously by others. If doctors haven’t found something that’s wrong, then that somehow means — though people rarely say this out loud — that there is nothing wrong with you. To have a chronic pain condition is to suffer through the shaming, doubting and negation of what you feel by others.

My interactions with the medical system have been instructive, if only in a negative sense. In the UK, where I began some of my investigations into this pain, most doctors simply don't have the time to listen to the whole story, to really delve into the details of what is going on. My general practitioner doesn't even take face-to-face appointments as the first point of call; you first get screened with a five-minute phone call. Then if your condition is deemed serious enough, you get an appointment to see the doctor which is limited to 10-15 minutes.

The body is a system. The medical structures as they currently exist doesn't treat that system, however. They treat individual parts of that system. It has developed a pretty good sense of acute conditions and things going wrong — if you get shot, stabbed, have a heart attack or a serious allergic reaction, you’re in good hands. These are all things that the medical system does pretty well at fixing. You’d do well to go to a doctor or a hospital to deal with those things.

What it is less good at is fixing or addressing systemic conditions that have multiple causes, or that are caused by complex interactions between different systems and groups of causes. Most kinds of chronic pain conditions — characterised as something ongoing and recurring for a lengthy period of time, sometimes even absent any clear or specific stimulus — are these kinds of complex problems.

I saw my GP, received referrals to various specialists. I was referred for followup tests. All the different parts to this universe of treatments were characterised by two- to four-month waiting lists. In between treatments there was no followup. The system wasn't configured to link all the parts together. Once one specialist ruled something out, I'd get sent back to square one with my GP.

Eventually, the default position for unexplained abdominal pain that reoccurs or exists on some kind of chronic time-scale is a diagnosis of 'irritable bowel syndrome'. As most doctors will willingly describe, this is a diagnosis of exclusion: they haven't been able to find anything that fits into a specific 'bucket' so you end up with 'this is something else but we don't have a word to describe it’. You'll usually receive a lecture on clean eating, perhaps something about gluten or FODMAPs, as well as instructions to try to 'manage stress'. Any further investigations are usually much harder to initiate at this point because the doctor — by putting you in the IBS bucket — has essentially decided that there's nothing left to investigate. At this point you're on your own.

If you have an uncharitable doctor, or if you discuss it with (mostly well-intentioned) family or friends) you'll hear about how it could 'all be in your head'. You'll hear a lot about stress, and how you should 'really try to get a handle on that'. Your doctors will tell you to 'learn to live with it’ (read: ‘we don't know what's going on so we're giving up searching any further’).

When you go see a new doctor, particularly after a few years of a chronic condition, you have to play a delicate balancing act in terms of the quantity and type of information you reveal about your story. Tell too little and the doctor won't understand what's going on and you won't get any kind of solution. Tell too much and your doctor will quickly put you into a hypochondriac bracket in their minds.

Sometimes I'll be in a lot of pain and I'll know — in an acute episode, for example — that this kind of pain will probably dissipate in a day or two but that I need something to get through it for right now. I've tried enough of the pain medications out there by now to know which ones are good for which manifestations of acute intense pain. The problem is that if you go in requesting a certain kind of pain medication — particularly anything of any kind of strength, and especially if it is any kind of opiate — you'll be labelled 'drug-seeking' and you may never get what you came in for.

For non-acute episodes, doctors will ask you to rate the pain on the 1-10 scale. Because of my high tolerance, my instinct is to rate the pain fairly low because it is all — on some level — tolerable (quote unquote). (Just unpick that word ’tolerable’ for a second in your mind). Or even if it is quite intense, I've lived with it long enough that it doesn't necessarily manifest on my face or my body as if there is any kind of intense pain. Just because I'm not crying out, wincing or bent over doesn't mean that there is no pain. In fact, in my worst moments of pain I'm simply unable to get to a doctor or hospital and you'll find me instead in bed or lying on a cool floor waiting for it to pass.

Abby Norman’s fantastic book Ask Me About My Uterus has this section on how you can grow to some kind of uneasy familiarity with pain:

“Bodily agonies that do not end beget a kind of forced intimacy with pain that, not unlike other intense relationships, can eventually bleed into something tedious and almost unremarkable in its enduring presence. Its place in our lives can become ordinary and even, at times, oddly reassuring. The moment that pain owns us is not when it chokes our breath, when it knocks us down, or when it steals our pleasure. Pain becomes our master when we wake up one day and realize we no longer fear it. When we come to regard it as not something separate from us, but something of us. As much as we have labored to resist this in our minds, our bodies acquiesce. Our hearts beat, our cells divide, our nerves—frayed though they may be—fire, and one day we realize that we no longer remember what it feels like to live without pain. What becomes remarkable is not our body’s distress call, but the silence. Really, it’s the silence that we fear, because it does not mean we have been healed. Silence after pain usually marks our body’s inability, or unwillingness, to adapt again, to heal itself, and to persist as we do for an answer, or a reason, for our suffering.”

There is also a kind of shame in this familiarity. The dominant narratives that you’ll hear around illness and healing usually have some kind of ‘struggle to beat adversity / struggle to win’ theme to them. Coming to a familiarity, making peace with pain, or surrender of any kind is somehow socially anathema. That may be the case, but I have been finding something compelling in the feeling of reassurance.

I gave this piece a slightly odd subtitle. ‘A love story’. Amidst all the uncertainty and inability to describe (or understand) what’s going on inside my body, I have grown much closer to all the myriad sensations and energies happening from moment to moment.

The experience — an extended period of illness and suffering in general, chronic pain in specific — has taught me a lot along the way. I’m far less disconnected from the everyday somatic experience of my body than I’ve maybe ever been in my life. I’ve learned all sorts of things about stress, trauma, the mind-body connection as well as ways of coming to terms with it all. I’ve learned that the treatment of chronic conditions by the normal healthcare system is truly broken. I’ve learned that placebos are a real and sometimes beautiful thing.

I’ve been continually surprised at the body and mind’s ability to adapt to a new normal. Shifting baselines are both a blessing and a curse, but the way I’m constantly calibrating and coping in response to changing circumstances is a marvel to observe.

Amidst this wreckage of what I once thought ‘normal’, there are things that help from time to time. Protective and defensive measures seem to work the best. Awareness and mindfulness help prevent small irks and aches from growing when I try to ‘just push through’. Following a restricted dietary regimen can sometimes help, but not when I’m so far gone that my body reacts even to the good stuff. Stress and time management is almost a truism, but it’s achieved that status for a reason. Sleep is possibly at the top of my list of things that make me feel better; it’s also the first thing I’ll start neglecting the moment I start to feel better. Slow kinds of movement, be it walking or yoga, have been useful in reconnecting me to some kind of energy and reminding me that there is some life or presence in me yet. Acceptance and a reminder about death (not getting too attached to my body and the world) is a surprisingly handy mental model to have when going through the worst moments; in the end, everything passes.

When pain shows up all guns blazing, that’s who’s in control. For someone who generally has a sense of how they’d like things to unfold, this powerlessness took a long time to come to terms with. But there’s some sort of relief in the surrender, even if that’s also somehow layered alongside shame. And since we’re quite far down the road of dealing in metaphor and story by now, maybe it’s just a question of taking care of this scraggly keukegen beast for as long as it takes. One day perhaps I’ll wake up and it’ll have decided to move on to take up residence in someone else’s back yard.

Pain is a profound teacher. If only the experience weren’t so unreasonably unpleasant.

[alexstrick]

RaspberryLPIC: A New Series & Setup Steps

I mentioned in my last post that I hoped to move on to the LPIC-1 exam in the coming weeks. I’m going through a bit of flux in terms of my stable laptop setup at the moment and I wanted a bit of stability as I work my way through the course. The idea suggested itself to me: what if I work through the syllabus using a Raspberry Pi?

I have a few Raspberry Pi 3 and Zeros lying around the house, so I’ve chosen the latest model I have — a model B version 1.2. I can SSH into the device over wifi regardless of whatever laptop I’m using at the time.

I’m choosing to use a Raspberry Pi for a few reasons:

I want something that feels (and is) ‘disposable’ — if I make some mistake in my settings, I can install everything from scratch fairly trivially

I didn’t want to do it on a virtual machine because sometimes this can behave idiosyncratically and I wanted something as close to an ‘authentic’ Linux experience as possible.

I didn’t want to use a server from a cloud hosting provider since a dedicated server running online is probably overkill for what I need. You can get cheaper if you’re just using part of a server (via some virtualised service etc) but that seemed likely to provide non-standard output.

I wanted to plug and play bits of hardware as part of my studies. That’s obviously not possible on a cloud server, and can provide non-standard responses when done through a virtual machine.

I didn’t just want to install Linux on a spare laptop since I don’t have one of those lying around where I currently am. If I break anything, moreover, the installation / reformatting process and so on takes much longer than just flashing a SD card for a Raspberry Pi.

The hardware is pretty decent on the model I’m using, at least for the purposes of the LPIC-1 exam. This seems like an ideal use case.

Once again, I’m following through using the Linux Academy’s video lectures. As far as I understand things, the LPIC-1 exam requires more than just passing familiarity with a few commands. For that reason, I’m using a few supplementary books. Once I’ve gone through both books and videos I’ll be testing myself with practice exams.

Yesterday I spent a few hours trying to get my base setup installed on the Raspberry Pi. I started with an ambitious plan to install the version of Arch developed for use on a Raspberry Pi 3 (i.e. this version of an ARM chip) but it ended up being somewhat non-trivial. I ended up breaking Pacman (the Arch package installer) and unable to install any new software or update the system.

I realised that Arch probably wasn’t the ideal setup for this experiment in any case. The default Raspbian distro, based on Debian Wheezy, seemed a better option. Flashing that onto my SD card and getting a headless copy up and running was easy.

I might take a short detour before diving into the LPIC course proper by working my way through the Linux From Scratch series. I figure I’ll learn some useful things in that process of building my own custom kernel / distribution that I can then build on through the LPIC-1 syllabus. But I haven’t fully decided on that path yet.

[alexstrick]

Earning a certificate in Linux Essentials from LPI

Last week I went to a test centre here in Amman to take the LPI Linux Essentials certification. The qualification doesn’t expire and takes you from zero to dangerous in a variety of basic scenarios in the Linux operating system.

I’ve been using Linux for a couple of years now. (Started out with Fedora, then went to Manjaro. Currently actually running OpenBSD but mulling a switch back to Arch). I was getting frustrated with only knowing certain areas to some level of competence — usually ones where something went wrong, requiring me to troubleshoot. I wanted more of a sense of the overview / fundamentals.

LPI is the Linux Professional Institute. They are the gatekeepers to a number of different Linux certifications (and, coming soon, BSD certifications as well!). The Linux Essentials syllabus gave a good grounding in the history around Linux as an operating system, a number of core UNIX tools, and a basic overview of some things going on under the hood. Some of it was easy / familiar, but I’m glad I went through this systematically.

I’ve been studying this for a few months now, using a mix of Linux Academy videos and good old Anki. The videos were enough on their own to get a passing grade in the exam (they only have pass/fail, though you do get your final ‘mark’ as well), but I really needed the spaced repetition in order to retain all the key commands and UNIX command line options. Retention might be easier for you if you’re already using Linux tools / OSes in work and you have that practical repetition going on, but that wasn’t my situation so I needed something else to make sure I had it all memorised.

The exam itself is multiple choice, which I’m not sure is the best way to test if someone knows their stuff. The level of depth expected was sort of opaque, too; you get an outline of what they expect you to know in the syllabus, but the various books and online resources all go into different levels of depth in terms of how many of the command options you should know etc. On the plus side, it forces you to overlearn which isn’t the worst thing in this case.

I’m now finishing up Linux Academy’s short DevOps Essentials course. Parts are a little basic, but it gives you a fairly decent overview. After that, most likely in the new year, I’ll settle in for the long haul to study for LPIC-1 (AKA the Comptia Linux+) certification. It’ll bring me a whole new level deeper in my understanding of Linux systems, and I’m excited to get started with that.