Create a “todo.md” routine

Tl;dr, part of your work is setting goals for next time, seems trivial but not done enough.

If there is one thing I can attribute to being more productive it’s this one simple trick. Raise your hand up if you’ve ever had to scratch your head while opening an old project, thinking, “wtf am I supposed to do now?”. Or even worse, you didn’t want to start working on a project again because it seemed like the tasks are complex, making it really daunting to work on it rather than play PUBG?

The basic idea is that part of your work is “caching” tasks for next time. Like a CPU does before context switching. You are basically helping your future-self get back to business by writing down in a clear manner where you left off and what is needed to be done.

“Todo” — Photo by STIL on Unsplash

Here is a real-world example:

You are creating a new web app. You’ve just finished implementing the basic user flow, you still know that you need to add a “login-by facebook” feature. So before closing the project, you have this routine of writing to your todo.md, you add the relevant task.

So if the todo.md was this before:



https://laravel.com/docs/5.7/authentication - Add a user flow (login, register, forgot password)

https://github.com/Vinelab/cdn - Move all URLs of static files to point to a CDN.

It will look like so after (we removed the user flow, and added the facebook login):



https://developers.facebook.com/docs/facebook-login/web

https://github.com/laravel/socialite - Add a login by Facebook

https://github.com/Vinelab/cdn - Move all URLs of static files to point to a CDN.

This will make it so much easier to get right to business next time we work on this web app. We are helping our context switching become faster.

Why not use Project Tracking Software™? (trello, jira…)

Hmm, basically, we are lazy (in a good way!). Why use an overkill solution when I can just open a new tab in my IDE or even head -5 todo.md ?

This is why I wrote the disclaimer. This tool is good while you are working alone/with a very small team. When this starts to work badly, you should probably go with a more “enterprise” solution. But up to then why not use a KISS ™ solution?

Notes:

If there is a need to rearrange an existing task, do it. That way you will know what is the most important thing to work on next time.

Always ask yourself if you can split a task into smaller parts so it will be easier to work on them next time (less scary), try to make it easy on yourself.

Always try to add some “mini-research” like “Documentation URLs” and tutorials that will help you jump into the task more easily next time.

Mini tip: I have a neat trick where I tell myself that work on the project means just looking at the todo.md and starting my server, nothing more. If that is all I want to do/have time for then it’s completely ok. What usually happens is that I see that the todo is so clear and encapsulates to the most basic task possible that I actually finish working on it, and sometimes even more todos(!). This is an extension of the 1-minute rule.

Create a useful.md

I love MD’s don’t I? Actually, I’m not even writing valid markdown, but you can (I mainly want readability). I just like that it’s readable text-wise and I can (kind of) format it if I want to.

So basically, I just create a little cheat sheet that helps me along the way. The rule of thumb is to add “useful”s every time a task is done by hand more than 5 times (automate??? Nah I’m too lazy — you probably should though, this might be a good indicator)

For example, I was using Laravel (😍 — quite impressed about the 7 years it‘s growing strongly and maturing, especially in the PHP ecosystem) in one of my projects, it has this cute little CLI tool that helps you with stuff. The problem is that I always forget the exact command (and --help is too generic most times). So migrating the database, clearing the app cache or even creating a new controller are tasks that I do routinely, manually. Why not have a “cache” for that?

It might look like so:

Artisan:

Clear Cache

`composer dump-autoload`

`php artisan config:clear` Generate new controller:

`php artisan make:controller name_here --resource` Make jobs (email) queue work:

`php artisan queue:work` ... Common fixes:

Env not defined:

`php artisan config:clear` Email not sent:

`php artisan queue:work` Cloudfront "access denied":

"edit distribution"-> "origins" -> edit -> "Grant Read Permissions on Bucket" -> Save, it will update the S3 settings (OMG FU Amazon UX). ...

Paypal:

Email:

Password: 123456

... Test accounts:Paypal:Email: myemail@emailprovider.com Password: 123456... Production:

Migration:

`php artisan migrate` Check logs:

`cd ...; less error.log` ...

I’m pretty sure this saved me countless hours of opening Google and typing the same thing until I remember it. Plus, in production, this saved my a** a couple of times when I needed to act quickly.

Comment Driven Development™ — CDD

(Partial CDD) I made this just for you ❤

This is fairly simple. Just write comments before you write code. Writing on paper may seem like too much, so here we are still in the comfort zone of our IDE. You will have a better understanding of what you need to do. Have cleaner code (most likely, because you aren’t spouting out code that may never be called, don’t be fixated — BFS > DFS here). I actually found a nice article about this, I guess this situation is like “who found calculus first”, here is the article, “Comment-Driven Development”.

Another flavor of this might be a minimal way of TDD, where I would write some asserts in my main function to check that everything is working correctly.

Another possibility is to write all the functions and add a pass in their “body”, so you know how your “API” looks like, now you just need to implement it.

All those approaches are way better rather than just starting to write code. Over all you should probably just go full TDD, but if you feel like it’s an overkill at least try these.

Watch one good video a week

This habit will let you learn and acquire new technologies, ideas and even opportunities (depends on how much we tie those together).

For example, I’ll watch a video about a new technology I heard from a colleague or in a tech interview. Then I’ll search YouTube for “X crash course” / “Intro to X” and watch it. Always strive for learning more and not stagnating.

Here is an example of a video I might watch. It’s about system design (event sourcing) and other treats:

Sometimes I’ll try to create a mini project using what I’ve learned so I can fiddle with it locally while not ruining real projects with whims of new technologies “just to test them out” (Hype Driven Development -> Not good).

Quick tip: Use the x1.25/x1.5/x2 speeds to get through them faster.

Learn to read other people’s code

I can’t seem to find enough people that do this as often as I might think, so I’ve decided to write it here too. This one is kind of ambiguous. But it will have tons of impact in the long run.

Knowing how to read other people’s code is crucial for being a good developer. You will learn other ways to think about solving problems. You will be able to read → understand → and fix tools you are using, maybe even getting some Github cred ;)

I actually started coding by stealing other coder’s code (I feel really bad talking about this now, but that is the truth). I used this old site called “planet-source-code.com” where I would shamelessly just go find a cool project and steal it, making my own version (I actually forked “before it was cool”). This was before Github (!) I had to read tons of code, most of which I didn’t understand at the beginning, slowly but surely I started to read more and get better at this concept of reading code (ahm... stealing…)

Eventually, I started to write my own code and was taken by inventing my own wheel.

Who doesn’t like graphs???

Anyhow, just work on this “muscle of reading other people’s code”, it will help you so much (can help with interviews, security, os and much more…) especially with the feeling of being capable of doing almost anything. Take 45 minutes to go through your favorite Github repo, see how it works internally, I’m sure you will find some gems (unless this repo sucks).