Our brains are fantastic devices and I think we have so much more to learn about how they really work. Maybe now in the AI area we will start to actually taking them seriously as we start to realize how things like mindset and how we think so concretely influence the outcome of our thoughts and work.
I mean, brain researchers and the like sure know this but it seems to be left to chance in a lot of the daily practice of tech work out there. E.g. we had zero training in this in my engineering degree.
Anyways, to the topic of the post.
As a sometimes overly reflective person who need to mentally be acutely aware of my mode of thinking & working to get anything done at all (I definitely lack an auto-pilot) I have found it helpful to list a number of such practices somewhere easily accessible and constantly revisit them. I even put them on my desktop wallpaper for some time.
I’ll start with the list, and go through them in a bit more detail further below.
My current list is:
Be a crafts(wo)man
Break down and plan until next action is obvious
Remove distractions
Immerse yourself
Get immediate and continuous feedback
Find or build tooling to see
Clean up and refactor to understand
Build prototypes
Build mental models
Sketch on paper
Stop and reflect
Allow the mind to wander
Write everything down
Optimize the hot path relentlessly
But since each builds on lot of personal experience that might not be obvious for anyone else, let me add a few words about them each, to give an idea. But since these are mostly thought to be reminders about something that is hopefully obvious, and that needs to be adjusted for each situation, don’t let my descriptions limit the ideas they spur in your circumstances!
The first item in the list starts with the word “be”. This is because this is not only about practices, but even more about who you want to be. If you picture yourself as a person of higher standards that is also what you will increasingly tend to become. Just don’t forget to also be honest and upfront with yourself about your shortcomings, or you will just become a prick rather than learn and adjust.
This is repeated in a lot of productivity books and blogs so nothing new really. It is hard to overstate of its effectiveness though when you are stuck and unsure about your next step. It was an aha moment to me to realize that if you are still unsure about the next step, you just need to be even more radicatl. E.g. if you can’t figure out what to write in your todo-list, then perhaps add “figure out what is the next step” to the list, and if you don’t know what that means in practice: Break it down even more! Perhaps, “talk to my boss/colleague about how to figure out the next step”, and so on. Rinse and repeat.
This one is pretty self-explanatory I guess. For me what it means is I have to have my noise-cancelling headphones on, with music from brain.fm, to turn out all the various sound stimuli that unconsciously is grabbing my attention (didn’t realize until I tried).
I’ve found that when getting into a new area, tool or even just a type of bug, and really don’t “feel like it” it often helps to read up a little around the problem area to get your mind starting to think about those things in the background. Before you notice you might actually start like doing this much more than you’d ever thought you could.
Just as a sculptor could not do their art without continuous feedback from their tactile senses and eye sight, how could you do proper work without it?
Especially when working with abstract things like software and or texts, plans, presentations, teaching materials etc, you often need to be pretty conscious about making sure you get constant and immediate feedback. In software, it often means setting up some automated test of the main path through the program perhaps early. Plus points if you can put in some visualization of the output. And for content for human consumption, it can mean having a colleague look at your draft early and come with feedback, if at all possible. These days you could even ask AI for feedback (Don’t let it replace you, but why not comment on your draft to identify obvious issues).
Again, especially when working with abstract things such as software, my experience is you can often increase your understanding of what you are doing, and thereby the quality of your work, like 10-fold if you can visualize what it really does.
Think about what small script you could produce that could continuously monitor your system and visualize some key parts of what it is doing! I think this is a way underdeveloped area. If you need inspiration, see e.g. these amazing visualizations of a few sequence alignment algorithms!
Often when navigating legacy code bases, you will understand it much better if you can manage to “touch it with your own hands” a bit, meaning, cleaning up, commenting and refactoring to your way of thinking.
Just consciously editing the code will force you to at least read it carefully enough, and it will trigger your thought processes. In addition, you get the freedom to format things in the way you prefer to see it. This is because, you don’t even need to push that back to the upstream code repository, which means you can take all your freedoms (but of course if you later find some obvious improvements, why not).
When you are exploring a completely new domain, or need to solve something you haven’t worked with before, you again probably need a bit more of “tactile” experience from working with in the problem domain.
That is one thing throw-away prototypes are great for! Sometimes people scream “don’t reinvent the wheel” as soon as somebody wants to try their hand at re-implementing something, but don’t let that stop you from gaining the experience. It will help you understand existing implementations better too.
Just as the choice of data structure design heavily influences what computations are easy to implement on the data, the way we think about a problem heavily influences how easy certain insights or solutions to problems appear.
Much more to be said here. Perhaps in a separate post.
No news here, as in some earlier points. Sketching things out on paper can give you something very practical and tangible to do, when trying to get unstuck, and also clarify a lot of things that would otherwise remain cloudy in your mind.
Sometimes you don’t get started doing something because you don’t know what to do which we covered above, but sometimes you rather should just stop and reflect on what approach you are having at a current problem really is! Like, whether you are making any good progress with the current approach or whether it is time to try something else. It is quite easy to go on way too long with an inadequate approach without realizing. For more details, perhaps read about optimal stopping in Algorithms to live by Brian Christian and Tom Griffiths (fantastic book with a slightly misleading title!).
Sometimes it can be really helpful to just consciously allow your mind to ponder upon something. Just levitate around a problem area and see what thoughts or ideas pop up. Being conscious about it is important so you give yourself enough time for it, don’t lose your focus, and remember to pick up (and write down!) what appears.
The above point brings us to the point of really writing down especially new ideas that pop up. These can pop up at the most unexpected moments and the way our brains work means we often forget them as soon as we switch spatial context (like back to the desk from the coffee machine). You better write things down immediately.
As many have discussed before, writing also helps tremendously with clarifying your own thoughts and making them available to your future self. I have seen that the things I have been blogging about during my tech career tend to become the things that really stick in my mind for years to come. Writing in the public also opens up so many chances for feedback and fruitful discussions with others.
This last one is one of my favorites, but fits in the end as it is pretty generic and can be applied to many of the other practices: Figuring out what things you do over and over every day and shaving off every bit of effort from that.
I have used this practice in things such as optimizing my workflow on the command line and in my editor. For the command line, I did statistics on my bash history file to figure out which commands are the ones I type tens to hundred times per day and made sure I have some really short and sweet aliases for them. This allowed me to be so much more fluent in the shell which has had so many unexpected consequences, like how I now don’t hesitate to do pretty complex investigations across the file system, such as grepping through complex code bases. It really is a force multiplier.
I’m sure you can come up with more clever ways to do that!
This is mu current list.1 As said, the descriptions are thought to explain how I think about these practices, but perhaps the ideas that these spur for you will be even better, or can complement this list. Thus I’m now interested in hearing:
What are your favorite practices?
// Samuel (@smllmp)