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.)
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).
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).
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.
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.
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.
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.
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).
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.
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.)
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).
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).
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.
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.
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.
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.
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).
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.
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 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.
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.
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.
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.
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
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.
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
Sleep ā this is maybe the most important item in this entire post for me.
Scheduling Study / Core Routine
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.
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.
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.
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.
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.