There were only a few hours left until the culminating tech presentation my team and I were preparing for. I find myself grinding out the last few bits of code hoping, praying that things will work- a situation no developer wants to be in. Murphy’s Law comes to mind.
Why am in this situation? I asked myself.
I finished up the last parts of my code and I handed it over for the presentation and laid in my bed. Wondering how to describe this horrible feeling, my mind looked for the right words to define what the problem was. There was a problem. There was something to be fixed. Huge disasters don’t appear suddenly from no where- I believe that they are an aggregation of small mistakes: mistakes across teams and across people; mistakes that make it increasingly conducive to make even more mistakes.
Where did we go wrong? I wondered.
This blog post weighs two opposing forces, and presents my observations in trying to resolve them: the challenges of a high-paced work culture in tech and the kind of software development work culture I wish to propagate and sustain within the world. It also translates to what I believe (and what my values are) and how I want to work with people around me. At the end of the post, I describe a small framework that I hope to put into practice, to increase foresight and field of view when it comes to planning, leadership, and execution.
Hopefully, with more visibility and an open framework for all to use, we would be able to reduce the mistakes made so that we can become more efficient in our work.
Tech work culture
For me, software development is a safe space. It is an area that I feel confident and competent in, though I do not claim to the best at it. I do know how to rely on the work of wiser and more intelligent people. Open-source software development is a clear, concrete example of standing on the shoulder of giants.
I love studying and building systems and understanding the designs behind them. It is because of this characteristic of mine- this patience and relentlessness in pursuit of understanding problems- that enables me to learn a lot in the field. However, there are great costs to it: I spent a lot of sleepless nights pursuing a bug. I would spend late hours at work trying to understand concepts, new technologies, learn design patterns. Not all are privileged to be able to afford that cost.
The work culture in tech is immensely stressful with a lot of demands. The work hours are a lot, and the demands are really high and overwhelming. I’m not going into more details but if you’ve been in the tech industry already, you would have a vivid picture of yourself enduring through hardships.
This is why I wrote this blog post. I believe that we can build great tech while being fantastic leaders and humans to our colleagues and workmates.
So where did I go wrong?
I must work hard
This is the first and greatest lie I am in the process of unlearning. Being hardworking in itself is not a bad trait. First, let’s explore some potential reasons why people become hardworking.
I must work hard because I have to prove myself. I think this is the most common reason for newbie software developers. It stems from insecurities (am I good enough?) which is prevalent in tech, especially when there isn’t a lot of positive feedback from the team people work with.
I believe that people insidiously nurture this sense of insecurity because they either calibrate themselves against others rather than themselves or because they lacked affirmation growing up. The mere absence of positive affirmation from parents, peers, or professors prevent individuals from learning that at some stage in their adulthood they must become their own source of truth and positive reinforcement and becoming less dependent on external inputs (others’ opinions).
I must work hard because that is what it means to be good employee. It is true that working hard is a sign of a good employee- but there is more to being a good employee than working hard. Becoming hardworking is a great place to start especially when you are new to a craft and you are still learning and practicing the skills necessary. Once you’ve mastered the necessary skills, the value of being hardworking plateaus.
I think many fall into the trap of settling as a hardworking employee because it is a fairly reasonable initial goal, that they can comfortably sense when they have achieved it. And of course, other people shift in their priorities sometime at this point (ages 30-40) towards family. However, true master craftsmanship goes beyond simply being hardworking.
In fact, it is very obvious what you must be that is better than to be hardworking.
I must be clever
There are different ways clever is portrayed. A common picture is a set of men pushing large stone cubes, while a single man pushes a sphere they’ve sculpted from the cube. In early childhood, it might be keeping a handy reference guide when studying.
When it comes to software development, it is the same. Learning to cut corners is a necessary skill, because we do not live in a finite world: we do not have enough resources for all of the requirements analysis research, software development and testing, infrastructure provisioning, quality assurance. So the question that is asked is: how does one become clever?
I think we can find the answer to that question when we are able to:
- know areas to cut corners: where can we cut corners?
- know our options: what are sustainable ways that we can cut corners?
- know the risks: what are the risks introduced by our options, and how do we mitigate those risks? what risks are acceptable?
These are all really tough questions to figure out. This is where truth shines as an ultimate value. Not having enough information (and thinking, quite proudly, that you actually do) is a very big problem. It can lead to making implicit assumptions that can surface later on, possibly when it is too late.
In the case of a young child, they might be tempted to cheat in exams because to them, the numeric grade they receive from the exam is the end goal, when in fact, they naively cut off their chances to become disciplined and learned in the area of study. In the case of software development, it might be choosing to forego long-term good software development practices that are time-expensive in exchange for short-term fast applications that are a nightmare to maintain.
In my reflections, I find that there is a prerequisite to being clever, and that is to be wise.
I must be wise
What does it mean to be wise? In software development, I think being wise is about knowing how to be humble in the genuine pursuit of truth, and to honestly speak it with the people you work with.
What this does is that you clean out the pride goggles you have when you look and think of yourself. It allows you to ask seemingly ‘dumb’ questions with your team that many are simply afraid to ask, worrying that they may look inferior or incompetent. It means that you can recognize capabilities in your teammates and knowing how to leverage each person’s skills. It means being sensitive to people’s different needs and situations, and knowing how to listen.
I analogize being wise as being able to clearly see the battlefield. It means clearing away the fog of war that prevent us from making the best decisions. It means enabling the team to gather intel, so that we can come up with a masterful strategy that will decisively win a war.
In more concrete terms, being wise means asking the right questions humbly, so that we can find the truth. Specifically, the truth is necessary to properly define the problem at hand. This is why observation is the first step to the scientific method, and why university researches begin their introduction by posing a well-defined problem and its scope. Being wise is like that. Being wise is like surveying the land and deciding what exactly we can see, why something is a problem, and then deciding a hypothesis or an experiment.
Initially I thought that being wise was enough. However, as I was pondering on my bed about the frustrating experience of working late hours for that end-of-week presentation, I realized that being wise, clever, and hardworking would not have been enough in the end.
It would have been fruitless if we had forgotten to care for people: colleagues with whom we work with, employees, our exhausted leaders trying to firefight issues left and right. This led to what I believe to be my first objective; the first constraint.
I must be human
Why do I work hard? This becomes a personal question- one that I encourage you to ask yourself too. For whom do you work hard for?
And I saw that all toil and all achievement spring from one person’s envy of another. This too is meaningless, a chasing after the wind.Ecclesiastes 4:4-16 (NIV)
It has been a full year since the COVID-19 pandemic spread. Third world countries suffer immensely, waiting for vaccines that can potentially protect their citizens. Corruption, leveraging the pandemic for elections, selfishness, and greed all become extremely evident and immensely insensitive at this very critical time.
In the end, we will all pass away. I can imagine even the richest people in the third world countries ponder about the futility of money against an enemy like COVID. Money becomes pointless. What good now is being hardworking, clever, or wise?
Why do you work so hard?
As I drift off to sleep, I come to realize that I desire to work hard. I want to work really hard because I believe I was blessed to be positioned in a booming industry. I was blessed with wisdom and skill with my profession. I am granted different privileges which I can use to uplift the people around me. I am granted a voice that can be heard.
I realize that I want to work hard because I have so much, and there are those with very few. I work really hard at my craft; my craft which I do not call my job because I am drawn to the beauty of creation. Creating value and impacting lives- the effect is immeasurable. I am drawn to learn it even further, to teach it to more curious minds, and to uplift and enable people.
I have experienced what it feels like to be cared for. I work hard because I want to be a person that cares for people. In a few years time, I will have made plenty more mistakes, failed more people, embarrassed myself, and possibly let many people down. But it is this genuine desire to be human- to care for the last, the lost, and the least- that I want to be remembered for.
We will all pass away, and everything will be forgotten. I would like this to be the last few things remembered of me.
Using the framework
I’ve broken down the framework into four parts: it is to be human, to be wise, to be clever, and to be hardworking.
By being clever first before hardworking, you prevent yourself from the danger of being too narrow-minded or short-sighted on solving a problem. It prevents you from having horse-blinders on a specific set of tasks, because the task in itself is allowed to change. That change could save time, effort, energy, and other resources.
By being wise first before clever, you allow yourself a greater field-of-vision as to deciding how to be clever about the problem at hand. This lets you (and your team) decide what your options are on how to execute it as efficiently as possible. An open, collaborative, respectful work culture enables your team to speak truthfully and honestly, allowing everyone to contribute ideas that can allow us to be clever about the problem.
Being human first before wise sounds like a misnomer. It isn’t about being unwise.
Being human first before wise is about knowing and understanding the resource constraints that you currently have (the number of people: the time, energy, and capabilities that they have). Personally, I do it because it throws me forward knowing why I am trying to become wise. I do it for the people in my care. By knowing the constraints, this allows you to define the problem properly, and to scope it down (i.e. negotiate deadlines, deliverables, and requirements).
As a leader, I believe this clears my head a lot. It also sets the tone for being wise- this isn’t about you and your knowledge and your skills. It is about putting your skills in service to the people entrusted to your care. This humbling tone clears out pride issues when opening the discussion for the problem definition.
Thank you for taking the time to read my thoughts and ideas. As in science, these hypotheses and ideas that I put forth are simply models that I use to simplify my thinking. Models can be incorrect and subsequently subject to updating. At times, it can be correct, but still be invalid given a different circumstance or set of data.
What is beautiful about models is that it is open to being used when useful, and being changed when needed.
Thanks for reading and have a lovely day.
Editor’s note: The page currently has dead links- they are blog posts that I have not yet posted and are still in the pipeline for writing/editing. Build in public and do a shitty job!