Bullet Journaling for Software Developers

Software development is an intellectually intensive job. It requires focus, determination and a good amount a strategic thinking to be fairly good at it. And so software developers by nature are not very organized outside of their current development task. They would rather focus on the current task than to manage their overall workload. Because of this they are generally not very good at managing expectations. And because they are so focused on development, often have a very skewed view of how much time it takes to do any sort of development. This is why frameworks like Scrum was invented.

The amazing thing about Scrum and why bullet journaling it perfect for it is because it allows you to work in iterations. Even if you don’t work in iterations, you can still use bullet journaling to manage your work load. But for this article I’ll focus on the iterative approach.

Bullet journaling, for those who aren’t aware of it, is a means to add structure to your life, yet it’s flexible enough to make adjustments as you go forward so you can improve on the way you work. And as a software developer it forces me to slow down and thing more thoroughly about my day and upcoming week.

The Tools

Below are the tools that I use on most days to keep my journal.

The Notebook

I prefer to use a Moleskine or a Leuchtturm 1917 with dotted pages. They’re more expensive, but keep me on track and committed. Currently, I have my Leuchtturm 1917 covered in a nice leather sleeve. It’s more professional; it adds that extra oomph and is definitely better looking than any of the senior level’s notebooks I have ever seen.

The Highlighter

I use mildliners to highlight the headings and special sections. They’re translucent like highlighters, but more subtle so they don’t jump out like the neon colours. Zebra is the most popular brand, but there are others.

The Writing Instruments

I’m still on my quest to find that perfect writing instrument, that writes well without leakage. Currently, I use a 0.38mm black pen that I bought off of Wish. I also use the coloured pens, also 0.38mm, that I bought off of Wish. They’re better than anything I’ve found at Staples or on Amazon so far.

The Writing Gang

Other Accessories

Other things that I use are rulers to keep the lines straight. Whiteout tape for those annoying mistakes. And page tabs to highlight each sprint and important pages. Amazon has all of this stuff, but Etsy has some nice page tabs for the creative type.

The Setup

After several two-week intervals (sprints) I’ve more or less settled on the main sections of my notebook. There’s the sprint page, the daily update, the meeting notes and the information section.

The Sprint Page

This is a straight forward full page that describes the current sprint number and/or dates. The stories or tasks that I’ve committed to and the effort required to complete them. I’ll also add any information relevant to the sprint. When the book is flat open, I always make the sprint page on the right, so I can attach a page tab to it.

The Daily Update

Every morning after I’ve logged onto my computer, the first thing I’ll do is setup my daily update page. I use the green mildliner first to setup the title and then write the current date into the highlighted section.

Then I’ll go through my calendar and emails and write down all the meetings for that date; the time, meeting description and the bridge number of room number of the meeting.

Then I’ll jot down any daily tasks that I need to complete for that day as well as the sprint commitments, etc. Also I’ll keep a running journal of important events that occurred that day, if they’re important. These events could be blockers, emails I’ve sent, reminders. I’ll use different coloured pens and mildliners to bring attention and prioritize work and meetings.

The Meeting Notes

I use the purple mildliner for the header of meeting notes. I’ll always use half page chunks regardless of how much content there is and I start at the top half or bottom half of a page, never in the middle. If I’m hosting the meeting or am expected to participate, I’ll prep by writing out questions and points I want to bring up during the meeting.

If the meeting will be a knowledge sharing session, then I’ll write my notes in a crappy spiral bound notebook and transcribe the main points into the Leuchtturm after the meeting. If I have any action items, I’ll highlight those and may also write them down into the daily update section.

Information Section

Sometimes I like to keep track of a list of ideas or long term items I’d like to work on. Just like meeting notes, I’ll use a full half page and highlight the header in blue. And then use a page tab to mark this page a special.

If I have a small chunk of data I want to remember, like the daily scrum bridge number. Someone’s phone number or other small tidbits, I’ll draw a square below the current daily update and inside it will write out that bit of information.

Other things you can document in a blue section:

  • Code review notes
  • Coding practices
  • Git commit instructions
  • How to determine a story estimate
  • Motivational quotes
  • etc.

Super Important

I have a red mildliner that I use to highlight very important information. Just like the blue mildliner, I’ll use it on a half page or a small square box or just to highlight a single line. What ever is appropriate.

Other tips

I use the gray mildliner to highlight important information that may be contextually important.

Be creative in how you use the journal. Don’t be afraid to experiment; you don’t need to be perfect the first time. Every page is a new chance to try something new. Software development is mostly a left-brain activity. But using colours and rulers and trying to be a bit creating will unlock the right-brain. This is particularly good for those developments that have a hard time switching between coding and documenting. Reserve half pages for doodling. Or to experiment with the mildliners and pens.

The purpose is to unlock new potentials that you may not know you have. Essentially self-improvement.

Development Sandbox: Building A Better Math.pow() Function

I remember a long time ago I had read an article comparing two keys on a classic calculator. Someone had asked why the [Xy] key where y is equal to 2 is slower than the [X2] key. So I thought I’d have a look at the JVM’s equivalent function, Math.pow(). But also I wanted to see if I could create a better version of that function. Continue reading “Development Sandbox: Building A Better Math.pow() Function”

Ways to Learn a New Programming Language

Every programmer should be learning a new programming language on a regular basis. That’s every three, six or twelve months. For me, I like to vary my languages by paradigm. Object Oriented Programming. Functional Programming. Declarative versus Imperative Programming. Compiled Languages versus Scripting Languages. Dynamic versus Static Programming languages. There are two reasons I want to learn new languages. One, I like to apply what I’ve learned from one paradigm and apply it to my current situation. Second, I like to stay up to date on the needs of the industry and be ready for whatever may come. Continue reading “Ways to Learn a New Programming Language”

Development Sandbox: My Coding Guidelines

Great programming is a balancing act between writing good, readable and organized code. Good code is fast, efficient and memory conscious. Good code is also very easy to read and to understand. But also the way the code is organized is of the utmost importance. It’s a balancing act because sometimes fast and ugly code needs to give way to readable code. A single linear function that’s optimized to the nines may be super efficient. But it’s also a maintenance nightmare. Continue reading “Development Sandbox: My Coding Guidelines”

Development Sandbox: Coding Patterns

Java is a habit-forming programming language. After a few years, good programmers find efficient ways to code. They’ll accept the programming language’s shortcomings. And they’ll make the best of a not-so-good situation. Pair programming and code reviews have provided a means for programmers to share ideas. They learn from each other to write better and cleaner code. It’s a social experiment of sorts. The more you are exposed to other developers and their code, the more your skills improve. It’s an evolution. Continue reading “Development Sandbox: Coding Patterns”

Development Sandbox: Int to String Conversion

Recently, while reviewing some legacy code I discovered a trick a developer had used to convert an integer to a string. The developer did this because the function only accepted a string as a parameter. As developers, often we look for succinct ways to code thinking that less code is faster. The interesting thing about the code is that it was the slowest of all the tests I had done. In all my efforts, I found five different ways to code to a conversion of an integer to a string. Continue reading “Development Sandbox: Int to String Conversion”

Development Sandbox: String Concatenation

When you review and work with other people’s code you sometimes find some tricks to optimize your own code. Most of the time the tricks look impressive in their succinctness and streamlined approach. And so you’d assume that the performance behind the scenes would be mind-blowing. So I decided to have a look at string concatenation. I have seen a number of ways to concatenate strings. Usually, the ones that do everything within scope will do it properly. And there are concatenations done other ways for appropriate reasons. But I thought I’d still have a look at the many ways one can concatenate a string.

Continue reading “Development Sandbox: String Concatenation”