Code • Life
We are already doing these things to our code, why not do them to ourselves?
--
#1: Profiling
When we try to improve code efficiency, we profile its execution to identify bottlenecks. We use profiling tools that can record and examine a wide spectrum of metrics: I/O latency, memory usage, execution time of a code block, or even the number of executed instructions.
When we try to improve our own efficiency, why not try to “profile” ourselves as well?
For example, if we feel easily distracted, we could write down each distraction and how long they bring us off track. Maybe we can see patterns so we can fix them in the future. If we struggle to change an old habit, how about record each time it happens and why? Or if we want to form a new habit, how about write them down and track our progress? If Benjamin Franklin could record how he did with his thirteen virtues every day, so can you and I.
#2: Debugging
When code doesn’t work as expected, we debug it, often as detailed as stepping through every statement.
When you next time make a mistake, or you wish to things had gone better, try to sit down for a while and “debug” the process. Go through what happened step by step, examine what you did and why, figure out the “bugs,” and take actions to improve.
Debugging might not only apply to our personal lives, but to work as well. For example, at Medium, we run post-mortem meetings for site incidents, project reviews after a project has shipped, and some teams have 30-minute retrospective meeting on Fridays.
We have to debug code in order to make it work, but we often ignore debugging real life. It requires self-awareness, a high level of proactivity and a desire to level up.
#3: Open sourcing
Most of us have used open source software; some of us have even open-sourced our own work. Open source is great because it lets us learn from others, get feedback on our own work and benefit from the work of others.
Wouldn’t it be wonderful if we could “open source” our thoughts as well? How might we open source thoughts? Write them down! By the way, you are now looking at a great tool to do that. :)
Open sourcing helps us write better code. Writing helps us clarify our thoughts, think deeper and better, get feedback from others to improve, and hopefully inspire others as well.
Open source also fosters collaboration, so we can make better software together. Similarly, writing and sharing also create a network of ideas that build off each other.
#4: Using frameworks
Frameworks are our good friends. They help us focus on the business logics, and can simplify the implementation.
Frameworks for thinking are equally important. They simplify our thought process, and help us focus on our unique goals and make better and faster decisions. Good thinking frameworks can apply to many different scenarios. Take Stephen Covey’s four-quadrant framework of time management as an example. It tells us to focus on important but not necessarily urgent things, like planning, exercise, or self-improvement, which are often de-prioritized since they are not urgent. If we apply this framework to software engineering, production bugs are urgent and important (Quadrant #1), whereas automated testing and tools are important but not urgent (Quadrant #2). We should invest in better testing and tools, so we will have fewer bugs in the long run and we can spend time on more important things.
Building thought frameworks is also beneficial and fun. If you observe patterns cross different disciplines, try to abstract the similarity, peel off specifics and build a thought framework. This type of synergistic thinking helps you understand the world better and deeper, and likely you will find the framework can apply to many other areas you haven’t even thought about. That inspires creativity.
#5: Commenting
We all try to write code that is easy to understand. Good code should be readable and tell what it does. Do we still need comments then? Yes, comments tell the “why”. No matter how good the code is, it cannot always explain why it is being written in certain ways, or compare with other alternative solutions.
Similarly, it’s very important and valuable to “comment” on the things we do by thoughtful communication.
People can observe what we do and how we do it, but they do not always understand the motivations, or why we do it in certain ways, especially when the why is not obvious. Without knowing the why, people may get confused, defensive, or even misunderstand what we do; whereas once we know the why, we become supportive, encouraging, and even get inspired.
Thinking about and articulating the why helps ourselves as well. Maybe there are better alternative ways of doing it, or maybe we have other more important things to do first.
Can you think of other things that we do with the code but not with ourselves as often? Write a response :)
Thank Wanmin Wu for always patiently listening to me when I talk about random stuff and inspiring me with her thoughts. Thank Dan Pupius, Jean Hsu and Evan Hansen for letting me bounce ideas off them and greatly helping edit this article.
