Shadrack Lilan

Akrasia

Tue, 16 Feb 2021 00:00:00 GMT

When I started this blog, I hoped to churn out at least one article every two weeks. However, it has been over 8 months since my last post and I felt frustrated because it was not the first time I set a seemingly easy goal but failed to follow through.

Out of my frustration came a desire to understand why I couldn't maintain my goal of a post every 2 weeks. I began my research on procrastination around September and I came across an interesting concept called Akrasia. This post is a series of notes I made on the topic.

What is Akrasia?

According to Google's dictionary, akrasia is:

the state of mind in which someone acts against their better judgement through weakness of will.

A student wants to set aside some study time in the next hour. The student knows the benefits of study time, however, they find themselves watching family guy during this period.

Here is another example:

9:00 AM: I have to study at 3PM
2:30 PM: Champions league game is on; Not feeling like studying, I can push it off to 5PM
4:55 PM: Got invited for early diner; I still have time in the evening, I'll study at 7PM
7:00 PM: Okay enough procrastinating, let me actually get some studying done.
7:30 PM: Oh crap! I have way more material to go through than I thought (panic sets in)

In those two examples we can see two things happening:

Procrastination: irrationally delaying a task with immediate cost and delayed benefit.
Preproperation: overindulgence in activities with immediate benefit and delayed cost.

How is it possible that we do stuff that's against our best future interests?

The most compelling explanation for me came from an economics concept known as time inconsistency. It's when your preferences change over time in such a way that what you like today, is not what you like in the next hour, or tomorrow, or at some other point in the future. An example is how TV time is more preferable than study time in the present, but if asked yesterday on how to spend your time today, you would gladly mention that study time should come on top.

Unfortunately, Akrasia is a default setting for all humans, and the faster you recognize it, the better the chances of avoiding a potentially deleterious sequence of actions.

Let's start running

Let's say you want to pick up a running habit. If you are a first time runner, you will probably research on the best shoes, proper form etc., and it's easy to find yourself in forums where people are clocking 10K runs daily, and then you get discouraged because the thought of running 10K in the Nairobi sun is too daunting. However, the initial goal was to pick up a running habit, and not to run a 10K daily so let's stick with the former. You can break this up into 20 minute run sessions with the basic minimum of giving your best effort, and just like that we have made the goal easier to achieve, just a 20 minute run with no speed requirements. The most important thing is to get started and to get over the initial hump. However there are 2 things that are likely to happen:

You fail to get over the initial hump
You get bored after the initial hump

Certain people may never face these issues, others might quickly recognize things going south and they will correct their path, and others(including myself) might fall into one of the aforementioned situations. However all hope is not lost, in fact, there are tools and strategies out there to help you defeat the tendency to "give up"/"get bored". I'll focus on one the one that I found most effective for my own challenges.

Commitment Contracts

One of the more impactful strategies that I came across was creating a commitment contract. Basically, you need to set penalties for your current self whenever you fail to do an action that you know will cost you in the future.

An example of a commitment contract would be, you will lose $5 if you do not get out of bed and meditate as soon as your alarm goes off. You set your alarm because you wanted to create time to meditate. When the alarm goes off, you might be tempted to stay in bed because it is warm, and you might end up rationalizing your behavior e.g. "I have never meditated in my life, so one day without meditation is not going to kill me". Although lack of meditation won't kill you, you will be denying your future self the upside of a meditation habit. The commitment contract now comes into play by adding a penalty that's felt in the present i.e. you get charged for not waking up early and meditating. You are now forced to meditate more, but after a certain period of consistent meditation, it becomes a habit, and you may not need that commitment contract anymore.

How can we apply the commitment contract to our running situation? I can create a contract whereby if I fail to go for a scheduled run, I will lose some money. The money represents the future fitness"points" that I lost because I didn't go for my run. I'll be starting off with small 20 minute runs, and I am unfit so I end up doing 2 miles. For some, that running time is awful, but remember our objective is to start running, not to run 4 miles in 20 minutes. Whenever I feel like slacking, I am reminded that I will lose $5, as a penalty from future self. Over time, my body gets accustomed to running, I notice that I am faster, and I am fitter. I am finally realizing the gains of running consistently. I may have even reached a point, where I cannot start my day without a solid 5k run.

How can we apply the commitment contract to our student trying to study? We could get the student to study could be to ask them tol donate money to a cause they hate for every hour that they procrastinate. That way, watching that champions league game means that your least favorite charity gets your money. Although the incentives might be a bit warped, you will be setting up your future self for success.

Conclusion

Commitment contracts are great for getting over the initial hump of the habit forming process, but they can help with just getting things done that maybe spanning a long time horizon e.g. a thesis.

I created commitment contracts for my most troublesome habits/activities. I used beeminder and it has kept me honest for the last 6 months. You can track some of my activities on beeminder page, and you'll see that I still struggle from time to time, but I have also made considerable progress that have translated to real life benefits.

I plan on reviewing the data towards the end of the year and share any insights I can find.

A Review Of My First Year As A Software Engineer

Fri, 26 Jun 2020 00:00:00 GMT

Today marks a month to my one year anniversary as software engineer. I began working for a local startup in Nairobi without ever doing a software engineering internship. I am forever thankful to my manager for taking a chance on an unproven, fresh out of college kid who barely took enough computer science classes to really understand what's happening under the hood of a computer.

The opinions in this piece are shaped by my experience working in a startup, therefore some readers may relate, others may not.

A little background...

Disclaimer: This section may have little to do with actual software engineering but I thought I would open up about my journey leading up to this point. This section mainly details my self esteem issues, and it's the first time I am opening up about this to anyone. Feel free to read this or skip to the next section.

I have to admit the lack of internship experience was entirely my fault. I was fortunate to attend a school where the largest tech companies in the world would show up begging for people to apply, however I never took advantage of this opportunity because I had a strong case of impostor syndrome. I had a rough start academically in my freshman year and it took me up to up to spring of sophomore year to get back on track. However, by then my self esteem was so low that I could never muster the courage to apply for an internship.

I took a handful of computer science classes in college and I built some really cool stuff for final projects. I was quite good at coding assignments but sucked at proof assignments (to this day I wonder why there was a chasm between the two assignments yet the former built on the latter). I would help a bunch of my friends out with these practical assignments, and it reached a point where they would prefer to see me instead of seeing the teaching assistants. This was a great self esteem boost and it encouraged me to do an even better job of helping others with their coding problems, but it wasn't enough of a boost to deem myself worthy of a shot at a big tech company.

The height of my impostor syndrome was in Fall 2018 when a good friend recommended me to a Facebook recruiter. The recruiter looked at my pet projects on GitHub¹ and decided to give me a chance. However, my mind conjured all manner of excuses to avoid the interview. I sent an email to the recruiter that went along the following lines:

Hey, thanks for the interest, I am honoured. However, at this stage I have not taken the requisite class so I think I will fail the interview, can I check in again at the end of the semester?

Some of you will cringe after reading that email, and I feel you. The requisite course referred to in the email was a DS and algos course. My university split DS and Algos into two courses, and I had only done the first course, which focused on implementation over proofs. The second course was where proofs met implementation, and it introduced concepts like space-time complexity. In retrospect, I think the first course was enough to power through FAANG interviews with maybe a month of preparation to touch up on space-time complexity. The fact that boot-camp graduates land in big tech without taking a rigorous DS and Algos course vindicates my opinion. However, the first thought in my mind when the recruiter reached out was "I am not good enough to interview".

(Reader warning, more cringe to follow...)

One of the hidden motives of my email response was that by asking for time, the recruiter would move on to find other candidates, and save myself from eventual rejection during a phone screen. To my surprise, the recruiter was perfectly fine with my request, and she actually waited. In January 2019, I got an email from the recruiter saying the position was no longer available. It is at this point I realized ... I am a complete joke. This email response weighed heavily on the rest of my senior year, and I was so crushed by how poorly I thought of myself that I could not get myself to apply for anything else.

It was time to graduate, but I had nothing to show for it. I had an average GPA, no serious leadership positions in college, one half-assed extra-curricular activity, and no internship. I knew that finding a job was going to be hard. With my back against the wall, I decided to move out² out of my comfort zone and do two things:

Apply everywhere.
Accept that rejection is a part of life, embrace it. I will try to limit it's occurrences, not by shutting myself out of opportunities but making it harder for someone to say no to me.

I decided to return to Kenya, and begin my job search there. I felt confident in the decision to go back home because I knew there was a bustling start-up scene so there won't be a dearth of opportunities. I landed two interviews within a week of getting back home. After two weeks, I had secured a job.

Initial Thoughts Of The Profession

I really believed that a software engineer only creates applications and that's the end. I thought that software engineers never interacted with the business side of a company. Software engineers lived in this bubble in their office and their only worry was making something run faster, or release a new feature so that users are happy and will continue using the product.

The Reality

Software engineering is one of the components of the business' machine. Depending on the size or the culture of your organization, you may actually never speak to the business team. On the other hand, you may find yourself very involved in the business side of things.

I'll go a little in-depth on some key areas that stood out to me during this past year.

Software vs Business

I started thinking more about business, and how my work directly impacts the bottom-line. I have seen how a bad data model can slow down or potentially ruin a business opportunity. I have come to appreciate the importance of understanding the problem that you are trying to solve for.

I have wrestled with the idea that you shouldn't go asking customers for requirements, even though conventional thought suggests that "The customer is always right". I have learned that you should not ask developers for requirements because they tend to operate in a bubble and their suggestions could be far from the users' reality. I am not saying that you shouldn't listen to the users and developers, rather, their opinions and experiences should inform product development

Tools and Frameworks

If you go to any programming/tech related website, you will find discussions on the next new thing, or some strong opinion about an existing tool or framework. Initially I was drawn to such content because I could learn the new in thing or have something cool to say when I meet other people interested in software development. A year later, I have a different reason for consuming this content. I now read to see if the new tool/framework addresses a problem that I am facing at work, or if the cost of switching over to the new tool will pay for itself down the line.

I have learned it is more important to select the right tool for the task at hand e.g. you would use C or C++ for embedded systems programming or something where every millisecond counts, or you should use Python for data science stuff since it has a robust ecosystem in that area. There are more examples and use cases I could jump into but that's not the point here.

This does not mean that you should not read up on the new stuff or test new tools. I'd now attach a target outcome when reading about this stuff e.g. does this tool address a problem I am facing. However, sometimes you just want to stay in the know and that is absolutely fine too!

Trade-offs and Thinking Fast

I went into software engineering thinking that the environment/expectations would be the same as an academic setting i.e. write modular code, test everything and you are good to go. All of these concepts carry over from the academic realm to the professional world, but it may not be a 1:1 transition.

One of the concepts that did not map neatly was testing. Business requirements are ever changing, which means that code is ever changing, and in this case, unit tests may become an impediment when refactoring/deleting old code. I remember reading an article about an engineer working in one of the Silicon Valley pioneers (think HP, Oracle etc) who had to spend months working on a small change because he had a test suite that run for almost 2 hours and most of them were unit tests that were no longer relevant. The point here, is not to condemn unit tests, but to provoke a discussion of when and where to have unit tests, especially if the code base is changing quickly. Personally, I don't have an answer for this yet, but someday I may be on a podium in some conference talking about this issue, so stay tuned!

Another issue that popped up was how to deal with tech debt. There are instances where business requires a new feature in short time frame. The feature could be complex and may require significant code overhaul, but the folks in management want the thing shipped as soon as now. In that case you will have to make some tough decisions with respect to your code, and possibly monkey patch some things and add feature flags here and there and add something like this :point_down:.

  // TODO: please refactor this block of code.

Voila! Tech debt. The managers are happy that a customer is happy with a new feature, but as a developer, this TODO block is an eyesore every time you come across it. It could be that the block of code is hard to understand for other developers, or it could be that the block of code is demonstrably slow for some operations e.g. database calls. The code base will be littered with these TODOs unless the team schedules a regular clean up. However, business needs to keep innovating and meet investor demands so the rate of clean up might be slower than the rate of TODOs popping up in code despite going through rigorous code reviews.

The Next Steps

As I head into year two, the main thing I want to focus on is to get better at thinking on my feet. This is not to say that I have achieved perfection in terms of coding style or testing or even the fundamentals of computers. I am still learning as I go, and they will get better with applied effort and experience. However, I have learned that this career is full of trade-offs, and having a good nose for the right trade-offs is really valuable.

I also want to dive deeper into the inner workings of computers. How does my JavaScript code move from a .js file into the V8 compiler and finally into machine code? I have some understanding of how this works, but I think it would also be nice to know these hard concepts.

Since then I have deleted these projects because they were one-off projects and I am currently working on more involving projects for my own use. ↩
Note the use of the term move out as opposed to step out. I feel like step out implies that I am still close to my comfort zone. I am a firm believer that language is a manifestation of your thoughts, and in this case I really wanted to move out of my comfort zone. ↩

Setup Vim for Javascript Development

Tue, 09 Jun 2020 00:00:00 GMT

There are a lot of tools that you can use to edit your code, and none of them more intimidating than vim. There is a saying that a good way to freak out the non computer savvy public or new linux users is to ask them to close vi/vim/neovim instance from the terminal.

When I started using linux, I would occassionally end up in situations where vim was opened by another program (looking at you git) and I did not know how to manipulate a file, let alone close the program. I would feel very frustrated, but not sufficiently motivated to learn how to use Vi/Vim.

My "I must learn Vim" moment came when I saw my engineering manager move code around using only vim and his keystrokes. However, I couldn't make the switch because:

I needed a language server for JS/TS (though I feel like I need it wean myself off language server use)
I needed a linter running in my IDE/text editor.

I would consider myself an early adopter of VSCode, and what set it apart from other editors(IMO) for JS development was it's inbuilt TypeScript langauge server. This simplified writing Javascript because you had autocomplete on your side and a rudimentary linting service provided by the language server.

The de facto linting tool for JavaScript is eslint. Visual Studio does not ship direct support for eslint but one can download the eslint extension from the marketplace to get linting on the fly. After installation, you would see red squiggly lines on offending lines of code. You could right click on the line and you would be presented with different options for handling the error.

A direct jump to Vim for JS work would mean I would keep syntax highlighting but I would lose the language server and IDE linting.... or did it? Turns out Vim can support a language server and a linting service. This can be done using plugins or scripts, but for this tutorial I shall be using the former. The next steps assume that you are using VimPlug as your plugin manager. If that's not the case, you can substitute your package management system/scripts wherever VimPlug is mentioned.

Setting up a language server

We have VimPlug up and running, so let's install a language server. There are several language server packages out there but I chose coc.nvim, becuase it's an IntelliSense engine i.e. the same as VSCode. Just like that I have VSCode like language server engine in my terminal. Shout out to the team that develops this package.

Open up your .vimrc file and add the following lines in the VimPlug section.

# rest of you configuration

call plug#begin()
Plug 'neoclide/coc.nvim', {'branch': 'release'}
call plug#end()

# rest of your configuration

Save the document, but don't close Vim yet. Type :PlugInstall and watch VimPlug do it's magic.

Once that's done, we can now install the TypeScript language server by running the following command in Vim:

:CocInstall coc-tsserver coc-json

coc-tsserver and coc-json are language servers for TypScript and JSON respectively

And just like that you have a language server up and running. See the GIF below to see it in action.

Language server at work in Vim

Setting up a linter

Last step is to setup a linter a.k.a the developer's first defense againt bugs. I chose ALE for this simply becuase of the internet activity around it. I have not yet reached the technical proficiency to tell you how it get's its business done, but I plan to revisit this topic later so stay tuned for another post.

ALE comes with sensible defaults, but it is highly configurable, including prettier configuration. I encourage the reader to checkout the documentation and learn what can be changed.

See some language server + linting action in vim below:

"Language Server + Linter at work"

As you can see in the GIF above, ALE will list the errors in the status bar when you navigate to the "offending line".

Conclusion

With two easy installation steps, we can go on with JavaScript development in Vim. I guess the next challenge for me is to become a keystroke guru in Vim.

Building this blog using Hugo and Netlify

Thu, 21 May 2020 14:44:58 GMT

For my first post, I thought it would be nice to share how I set up this blog. I wanted to set up a blog for a while so that I could share my thoughts and learnings with the world, and improve my writing while at it. I figured that since I would write about some technical stuff, I would have to really interrogate my understanding of things before I could post about them.

Building this blog was 99% fun. The 1% bad part was dealing with GoDaddy's crappy and slow UI. I'll go ahead and outline my steps

Choosing the blogging platform/tool

A blogging website

I think the default option for most people would be to use Wordpress. The free plan works fine however, I didn't like the fact that my website would come with wordpress ads. If I didn't want ads, I would have to pay a minimum of $4/month, and this was too high for me because I knew that I could away with cheaper.

The other, more technical option, was to download the source code and manage the build, deploy and hosting processes myself. This should tickle some developer's fancy, but I wasn't ready to start tinkering with PHP code, so this was a non starterd.

There are a ton of other blogging sites that one could use, but I didn't bother looking after realizing that I could build one to my liking without spending a dime (though I will have to spend some time 😀️).

Building my own

The main reason I chose to build my own, was that I was looking for a very minimal blog. I wanted the reader and myself to focus on the writing. I was inspired by Tom MacWright's blog, and how simple it looked (there is some good stuff on that blog feel free to check it out).

One thing about building your own, is that you will have to fiddle around with setup, layout, deployment etc. While this could be a good learning experience, I did not want to reinvent the wheel for some of those tasks, especially, building and deployment.

In comes static site generators. These generators basically handle the building part and enforce some convention to allow you to focus on crafting your content. Some of the popular ones are Jekyll, Hugo, Gatsby etc.

I started off with Jekyll, because I saw more references to it. I created another version of this site and tried to host it on GitLab using Gitlab pages. However, setting up the domain name on GitLab and GoDaddy was annoying and frustrating. I tried adding Gitlab's TXT record to GoDaddy so I could encrypt my domain and I expected the DNS records to propagate, but this was not the case. I decided to delete the site's repo, and consequently ditch the domain.

After that horrible exprience, I decided to start afresh with Hugo. Working with Hugo is conceptually similar to Jekyll with a few differences including choice of language. One difference that was noticably obvious was the build time. I tried comparing the pixyll theme implemenation on Jekyll and Hugo, and I found that the latter built the site faster. I found Hugo's documentation to be extensive, which is always a good thing in software.

The next step was choosing a theme. As mentioned earlier, I wanted a super minimal site with these requirements:

Fast render time
No fancy transitions
No ads
No fancy interactions
No flashy images(unless it's an image attachment for a blog post)

There are many hugo themes and templates out there, and I settled on Anubis. It was very minimal, looked good on mobile and desktop, and it had pretty good LightHouse scores.

I deliberately didn't explore Gatsby because I did not want to use React, and I think it's a bit of an overkill for simple static websites. In Jekyll and Hugo, I only needed to put my markdown files in content/ but for Gatsby, I needed to install plugins and handle some GraphQL, and that's a bit much for me, possibly overengineered for my particular use case.

Alright, we have our site setup with Hugo, and a theme, the next and final step was figuring out hosting. I settled on Netlify, since I was quite familiar with it's product offering, I liked ability to deploy straight from GitLab, and I would get an encrypted domain. Setting up a domain with them was super easy, and after the intial deploy, my secure site was global in less than 3 hours.

Conclusion

I am quite happy that I have this blog up and running. This was a high level description of the process that I went through to get things up and running. I have left some details out e.g. installing Hugo, or setting up deploys from GitLab to Netlify, because these processes are well documented.

There are still more things I would like to add/change e.g improve constrast of the theme, dark mode etc. but I am happy with this start.

Shadrack Lilan

Akrasia

What is Akrasia?

Let's start running

Commitment Contracts

Conclusion

Further reading

A Review Of My First Year As A Software Engineer

A little background...

Initial Thoughts Of The Profession

The Reality

Software vs Business

Tools and Frameworks

Trade-offs and Thinking Fast

The Next Steps

Setup Vim for Javascript Development

Setting up a language server

Setting up a linter

Conclusion

Building this blog using Hugo and Netlify

Choosing the blogging platform/tool

A blogging website

Building my own

Conclusion