A decade time would feel short when the clock was ticking pass midnight on the last day of 2019. Where all the time has gone. Yet, a simple act of comparison between the self now and a decade ago, that whole decade would start to appear more real, heavier and thicker in one’s awareness. Old perceptions, preferences, fears, worries, desires were replaced by the new. Changes happened slow enough that one hardly noticed, yet, significant enough to surprise us when compressed in a moment of reminiscing. This is my first time to write them down.

Career wise, I earned my bachelor degree, got my first job and worked in 5 different cities. A few things that I used to do when I first started to work but no longer do now:

  • Be eager to impress by taking on tight deadlines and then spent sleepless nights and weekends to accomplish it. Needless to say, it was not good for health. Trying to impress would prevent timely communication about progress concerns. And looking back, re-negotiating deadlines and resources when they looked infeasible might have been a better strategy. An individual contributor only has fixed amount of time. But a team’s time is more elastic as it can shift people from one project to another, more urgent one. Thus, instead of doubling down, ask for help and more “resources”.

  • Be possessive of the code. Software engineers write code based on their mental concept of how a system would work and interact. Given the same business requirements, individuals have different way of structuring their code. One may prefer having a large centralized logic unit while other spreading logic into smaller more specialized unit. No matter what amount of best practices would change that. After building and leading software teams, I’ve come to accept those idiosynchrasies, and to trust teammates to do what are reasonable. In the end, metrics (performance and business) will drive system designs.

  • Be an energy spendthrift. A decade ago, putting a new programming language to test in the next project sounded like a nice thing. I would maximize unknown factors and plunge myself into figuring out those stuffs along the way. Now I would prefer a familiar toolset, unless there are compelling reasons to do so. It is not that learning new things no longer excites me. I’m more interested into conceptual instead of procedural aspect of things. And a decade ago, I would be eagerly jump on board a new project and think about its practicality much later. A service to send sms notifying bus arrivals, a shopify clone, … are among projects that were quickly started and quickly abandoned. Youthful exuberance gave way to understanding that harder part of a product is not the software part.

  • Be concerned about doing cool things. In the beginning, there is a lot of talk about how one thing in software is more shinny than others. Common beliefs were software outsourcing easy, mobile app development more interesting than core banking, backend harder than frontend… Having worked briefly in each, I think all of them are equally hard and require different expertises. Though friends and families sometimes believe that computer science graduates know everything computer, including fixing broken one, they are jobs for different people. And there is enough depth in each area for people to grow, whatever they choose to do.

Nearly a decade of working in tech, there were things I found amusing about the industry.

  • Occasional invention of new names/acronyms for existing concepts would give rise to much overhyped new field. Think microservices. Service oriented architecture (SOA) has been around for long in the enterprise software world, yet it does not invoke as much trendiness when pronounced. Think NoSQL databases. Taking a relational database, rid it of SQL query processor, constraints and triggers, voila!, a NoSQL database. A few years ago, lots of developer flocked to NoSQL’s banner. But as their use cases grew more complicated, NoSQL were then forced to developed capabilities that are already available in RDBMS.

  • Software developers often lash out library names as knee jerk reaction to a requirement. Need a cache, use Redis/Memcached. Need to store time-series data, use InfluxDB. If you have a hammer, everything looks like a nail. Careful consideration of actual requirements, e.g of a cache, would save everyone a lot of trouble. Similarly, the ancient argument that a fast application layer need to be written in C is still ever present in a lot of people’s perception. It takes some effort to persuade the other person that, it only matters if the bottle neck is the CPU.

  • When meeting software engineer strangers at awkward dinner parties, asking “Do you code Python/Java/…” seem to be popular conversation starter of choice. Yeah, that is a part of what we do.

Near the end of this decade, I got hands-on with projects involving deep learning. The field is increasingly approachable to non-researchers. New releases of Pytorch or Tensorflow now allow users to train and run a model with a few lines of code. Thus at the end of the day, what matters more is who own the data. Though industry leaders often draw analogies between machine learning advancement and the previous smartphone evolution, unlike the smartphone boom, machine learning is more incumbent-friendly. Since established companies have an edge over up-starts and small businesses due to the amount of resources they can pour into acquiring and labeling data. So it’s not likely that the like of Whatsapp or Zalo, dominating consumer oriented applications, will appear out of this trend. That’s said, there are already a lot of new AI-focused companies appearing, which is exciting still.

Given the limited time each of us have, having to put a decade behind is not anything to celeberate. But maybe the price is worth paying for the experiences we gained, the people we met. And not that we have the choice anyway. So I’m grateful for what have been and looking foward to what’s to come.