Working Thoughts

I’ve recently begun the practice of maintaining a working thoughts document. The idea behind this document is to work through difficult or interesting problems I’m dealing with on a day-to-day basis at work through writing.

I was inspired to start doing this after reading Dale Carnegie’s How to Stop Worrying and Start Living. In the book, Carnegie describes a technique Ben Franklin used to use. Franklin would write down the pros/cons for something that he worried about to help conquer his worries on the matter and settle his mind.

Much has been said elsewhere about the value of writing things down rather than just thinking about them. For me, writing really helps debug my own thought process. Sometimes I have a vague sense of why something feels like a good or bad idea but I can’t quite explain why. This practice helps me flush things out and consider more supporting arguments for or against something.

A working thoughts document is also a great place to prepare for debates or difficult conversations. It helps me feel more prepared and makes me more likely to think through rebuttals and counter-arguments. Sometimes, they even make me change my mind!

After doing this for a while, I’ve found a things helpful and made a few observations.

Have one big document

Having one big document is probably the lowest friction way to get some quick ideas down without having to be super organized about it. I just make a google doc and have it as a handy link in my bookmark toolbar for quick access. Using the google docs outline feature, I give each thought a heading and it is easy to jump back to it later if I want to iterate on it.

Having it be at my fingertips makes me more likely to just do it and makes it feel like less of a big deal each time. Like many people, I find it difficult to get things started when it comes to writing. I can always spin off a specific thought into its own doc later if needed.

Approach an issue as if you haven’t made up your mind yet (even if you think you have)

Approaching an issue with an open mind can help divorce you from a preconceived or emotional attachment to an idea. I try to allow the arguments to unfold and see what I think after reading my own words. Sometimes I surprise myself! There is an amount of objectivity that comes from writing an idea down, and then reading it back – some time later. I tend to mold my ideas into something more coherent over time; I think they start to make more and more sense to someone else; which is usually the objective in the first place.

It’s not useful for all things all the time

My usage of this technique has waxed and waned over time, based on what was going on. In more stressful, hectic times, its super useful. At other times, I may not use it as much.

Archive for historical purposes

Can you remember what you did last month? Last summer? Last year? I know I can’t.

Since working thoughts tend to be transient, you might think to just throw them away; I don’t. I move them to an archive document and put a date on each entry. I do this periodically to housekeep the main document. Archiving can serve many useful purposes. It can serve as a historical record of how I made decisions in the past or what my rationale was at the time. This can be especially useful in retrospectives on past decisions, another great activity I plan to start doing more deliberately.

You can also use it to populate a career document, probably one of the most useful documents you can maintain relating to your career. It can be relatively straightforward to translate these thoughts to a career log later, since they tend to represent the important things you’ve had to do in the past.

Conclusion

I’ve found the practice of writing working thoughts down really valuable. Try it for a week as an experiment and see if it helps you. There is a good chance in any given week you’ll run into a problem that could be well-served by it. I probably start a new entry at least 1-2 times per week.

Leadership Podcast Roundup

Another year, another podcast blog post. I’ve been binging on leadership podcasts for the last few months, and have hit on some new gems. The crazy thing is how many of these podcasts are super new – like in the last year or so. In particular, leadership content catered specifically toward technology and software engineering leaders. So without further ado, here’s my roundup:

Continue reading “Leadership Podcast Roundup”

On Testing – Part 3

Browser-based Testing

In part 2 of this series, I talked about the lower levels of the test pyramid: unit & integration tests. In this post, I’ll be focusing on the highest level of the pyramid: browser-based tests.

Browser-based tests are slow. Really slow. They run an order of magnitude slower than other tests. Large browser test suites can quickly bog down your CI pipeline. Make sure there’s a good reason to write a test case as a browser-based test and that it can’t be accomplished at a lower level of the pyramid.

The sweet spot for browser tests

Continue reading “On Testing – Part 3”

On Testing – Part 2

Unit & Integration Testing

In part 1 of this series, I talked about the test pyramid, and how to approach applying it in your testing process. In this post, I’m going to focus on the lower levels of the pyramid, where you should ideally be spending most of your time.

Continue reading “On Testing – Part 2”

On Testing – Part 1

In this series of posts, I’m going to cover my views on software testing. I’ve spent a lot of time recently re-factoring some fairly large test suites, and would like to share some best practices I’ve learned a long the way.

In this first post, I’d like to cover some high-level testing strategies and my philosophy towards testing. In subsequent posts, I’m going to dive deeper into testing in each part of the stack.

Continue reading “On Testing – Part 1”

My Favourite Podcasts in 2017

I’ve blogged about why software podcasts are awesome and why you should listen to them in the past. In this post, I’m giving an update on my favourite podcasts in 2017.

Continue reading “My Favourite Podcasts in 2017”

Rein in the madness: Intelligently using wikis for your dev team

TL;DR Wikis are awesome tools. When used poorly, they’re like black holes; documents disappear into the ether. When used intelligently, they can be powerful, self-organizing knowledge centers for your team.

On most large software projects, organization is key. Developers aren’t always the most organized people in the world (I’m no exception) and project managers tend to focus on the project schedule. This can leave something to be desired or tracking the team’s progress and keeping everyone on the same page in terms of technical decisions and understanding of the larger system architecture as the project progresses.

Most projects hit a speed bump or two along the way, and it isn’t uncommon to have people scrambling trying to remember what was agreed to and when or struggle to remember why or how a certain decision was made.

Continue reading “Rein in the madness: Intelligently using wikis for your dev team”

The Importance of Modernizing Legacy Code

The term legacy code conjures thoughts of dread in developers everywhere. It’s code that’s perceived (justly or unjustly) to be tightly-coupled, hard to understand, hard to change, and just plain out-dated. It’s an immovable object.

The reality is, legacy code is everywhere, and it isn’t going anywhere. So why not make it better, and make our lives working with it everyday easier?

Continue reading “The Importance of Modernizing Legacy Code”

Truly rapid development of admin apps with json-editor

At work we have a lot of configurable settings in our application. Like a lot. For a long time, nobody tackled the task of properly exposing the management of these settings in a UI because they thought it would be way too much work. The settings have a flat unified structure in the back-end, making them awkward to manage logically as a set of related settings. Building support for a large set of arbitrary data types, different editors for each, custom validation, etc. seemed like a daunting task.

In this blog post, I’m going to show how you can use the json-editor library to build these kinds of complex back-office admin apps really quickly and easily.

Continue reading “Truly rapid development of admin apps with json-editor”

Hello Idris

I heard a great podcast interview recently with Edwin Brady. He was discussing his upcoming book Type-driven development With Idris. After listening to the podcast, I immediately picked up a copy of his book. Having now completed the book (well it’s a MEAP, so what’s finished so far), I’m finding Idris the language really intriguing.

I’ve always had a preference toward statically-typed languages. I just like the ability to specify type constraints and have some level of confidence of correctness in my programs before I run them.

Continue reading “Hello Idris”