• Christ and Church Life and Building Spirit and Bride


    As a lover of Christ and a pursuer of truth, I write down my joys, memories and reflections.

    May God lead us all into the secret of His presence, and build us into the oneness of His body in love.
  • Categories

  • Archives

  • Recently Viewed

  • Recent Posts

Things I learned as a software engineer

Though I don’t like to label myself, the fact is that I spend most of my time as a software engineer. Undeniably, writing software is a prominent portion of my life, at least for the time being.

I would rather say that I am a software engineer than I write software because  this profession involves much more than writing codes. It is both an engineering and an art; it requires not only disciplines and experience but also creativity and elegance. It is about fulfilling meticulous  and prioritized requirements under a tight deadline while keeping the codes extensible, efficient, and secure. It is about connecting two worlds by speaking both the language of machines and the language of humans. It is about collaborating with various roles and types of people with the common goal to build something that people would love.

However, this post is not about software engineering, but about the things about life I learned as a software engineer:

  • Good people are valuable. To ensure the quality of the software, the managers often institute some rules or processes, such as code reviews or continuous build. These things help but ultimately what really produce good software are still engineers of good quality. What I learned is that countries,  companies, or families, enact a lot of laws or rules to ensure their safety, order or prosperity. Yet these will help to certain degree but ultimately it requires people of good quality and morality to be a good citizen or employee.
  • Diminished returns on labor. A good software engineer can be as productive as 2 to 10 mediocre ones. Sometimes 10 people may not be able to finish the job that a good one can do. This principle applies to many other fields: what get things done fast and well are often a small team of motivated and capable individuals. Like a lot of things in life, adding more people or labor doesn’t always solve the problem or making things done faster, and, similarly, spending lots of time into something may not  always contribute to the best results.
  • Don’t always trust the numbers. There are plenty of examples why numbers can be misleading software engineering: the number of lines of code an engineer writes or the number of hours an engineer works cannot really reflect his or her productivity; the amount of time and effort to accomplish features or fix bugs cannot be predicted by the number of them. The last 20% of the software may well likely take 80% of the time and effort; fixing 10 bugs in one day and only 1 bug in the other day doesn’t mean that the productivity has changed. The list goes on. An engineer should not be measured by how many lines or codes written or how many bugs fixed. On the other hand, I don’t really know how to truly measure the productivity of a engineer. Historically speaking, we rarely evaluate a  historical figure by numbers but by significance.
  • Talent is overrated. The classic saying “Practice makes perfect” remains true. Before becoming a software engineer, I always think a good programmer is either genius or talented. The truth is that anyone who programs well must practice hard. A fresh graduate, no matter how smart they are, or how good their schools are, would not be able to do the things that a professional software engineer does. Like many arts such as playing piano or paintings, it requires not only raw talents but both years of hard working and experience to make a master.
  • Timing and prioritization is key. Given enough time, we can do anything. But the truth to both life and software is that we always have limited time. Hence, it is much more important to decide what to do and when to do them than how to do them. Like Gandalf said, “All we have to decide is what to do with the time that is given us. ” Having limited resources, time and energy, we need to choose wisely on what and when to do in life. This is classical dilemma between urgency and importance: obviously we should give immediate attention to things that are both urgent and important. But there are things that are urgent but not important, and things that are not urgent but extremely important. A good project manager or a successful person in life are those who can find the balance.
  • Perfection is an illusion. Anything man-made is as perfect as it dpes what it is expected to do. Before I always thought how can there be so many problems and patches to software but now I realize it is not only normal  but inevitable. It is not possible to define perfection in software because the requirements and contexts always change. Ultimately, good software is about managing and handling more than what your customers or users can think of or expect. It is not possible to define a perfect human being. A person is as good as how he or she manages or handles the circumstances that he or she runs into. Earthly and humanly speaking, perfection requires contexts.
  • Life is a series of stories and bugs. Software is not written in one giant piece but by finishing features and fixing bugs. There are always new features to finish and there are always new bugs to fix. This is similar to life in 2 way: Firstly, we experience life as stories. Though we traverse time in a seemingly linear fashion and time seemingly passes by at fairly constant speed, we experience, perceive, and remember life as a series of events, such as graduation, first job, marriage, first kid, etc; there are always new adversity to meet, new events to experience, and new joyful moments to remember. Secondly, we experience life as bugs. Life is always unexpected, giving troubles and issues that we need to deal with and fix. This is also why life is interesting.
  • Heterogeneous collaboration gets the job done. As a software engineer, I have homogeneous collaboration with other engineers: we need to do code reviews, design discussions, etc. And I also have heterogeneous collaborations with other roles and types of team members, such as system admins, product managers or QA. One thing I learn in life is that we need and must collaborate all kinds of people to get things done. The truth is that everyone has different functions, everyone complements each other, and we need each other. There is no one that is self-sufficient and has everything all together. This is universally true to life, to a society, to a country and to countries.
  • Pre-mature optimization is evil. In general, anticipating or planning for the future is good. But planning or doing for something unclear before the task is even finished is evil. Getting the job done or fulfilling the requirements are always the first priority. A well planned and optimized but incomplete project is, after all, a failure; completing something poorly is still better than not finishing something that was well planned. It is good to prepare for the unexpected and the unknown but at the end of days we need to see that there are too much unexpected and unknown, and there are times that it is better to react than to prepare for the unknown.
  • Accept the reality. Like I mentioned earlier, it is impossible to declare that a software in a done and complete state, but only in a ready-to-ship state with known issues, bugs, and limitations. There times to make the effort and figure out the best ways of doing things, and there are other times to say we accept the reality and ship the product with known issues. This is true to life in a lot of ways: there are times  to find a perfect or ideal solution or person, but there are times to accept the existing facts and the circumstances.
  • It is never over until is over. Like I mentioned earlier, there are always bugs to fix, especially the unexpected ones. A good engineer don’t declare early or premature victory. There should always be backup plans, contingency plans, or even rollback plans. The key is to be prepared and not over-confident until the product is shipped. This is true to life: we should continue to work hard until the end, do our best within our control, prepare for the unexpected, and leave the unknown to faith.
  • At launch you realizes there are features you don’t need. Engineers are in the constant fight against product team that demands more features. While the product team doesn’t have concerns with performance, security, stability, engineers do. Like I said earlier, it is common to decide a deadline and ship the software with known issues. Though it is always good to think about what features are important  or not, it is at the moments of launching that we realize there are features that are not important and, therefore, droppable. It is true to life that we human beings often chase unimportant things until the last dying days we realize what are actually important, and how much time and efforts have been wasted upon unimportant things. As good product managers and engineers thinks about what features are actually important and critical, we human beings should also consider what are really precious and significant in life.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: