Saturday, October 26, 2019

What you want to do in your life

Quite some time ago, I wrote "Good grades, good opportunities". Basically what I meant was that working hard in school is one way to propel in life, but it isn't necessarily the best way. By focusing too much on a part, one risks missing the whole spectrum of possibilities and opportunities, like a sad puppy looking at a rainbow. Yet supposed you have graduated and what you want to do with your life is anything but a fogged window, how would you get yourself into a position with better visibility?

My generation was fed that we should be following our passion. That implies somewhere in your mind there is a hardwired plan waiting to unfold, and that you know what you like - more so than any others. Well, if that was the case, we wouldn't be sitting here, would we? The people who said that also didn't really mean it. They probably meant that though the journey to discover what to do in your life is more banging your head against a brick wall than smooth sailing, don't let it demoralized you. I agree. You shouldn't underestimate your potential, and succumb to the thought you can't do what other people can.

The first step towards a way out is to ask whether you must have a job. Hint: if you can afford the question, you probably don't. Besides providing a means to get by, being in a job is also a useful experience. It is certain that each job is unique, but given a bit of abstraction, they have a fair share of similarity. For example, most engineering jobs are project-based and focus on time management, communication, and problem solving. These skills are interchangeable regardless of industry. Through the job, you also get exposed to an industry, where opportunities barely visible from outsiders. No, the world doesn't have a conspiracy against people like you and me, nor some people have it easier than others. It just changes fast and because innovation rarely follows a pattern, being in the right space is crucial.

Remember this is your day job. Working at a day job doesn't mean doing it half-heartedly. It means you shouldn't let your identity be defined by this job, just as an aspiring writer with a day job as a cram school teacher doesn't think of himself as a teacher. I usually tell fresh grads that who they are in the next 5 years is defined by what they do after 7PM. Because that is when the day job ends and real work begins. If you are one of the fortunate individuals who can afford not having a job, you get to do real work full time.

What real work? To discover what you like. This is actually harder than what it sounds like. There are a lot of jobs, ones that you don't know and ones whose name hasn't existed yet. And the dramatic way the media has described professionals only makes an accurate image harder to find. Most lawyers go through their careers without a single murder case. Literally no one hacks into a system by typing in a terminal like a maniac. And my favorite series House MD is about the exact opposite what doctors do.

I am probably the worst one to whom you can talk about the definition of "like". But I know that working on a job where you only execute instructions is not going to be very fulfilling. It is better to work in areas where you are interested to understand how things work, can exercise your freedom of thought, and get into the zone easily (where time flies). In other words, work on stuff about which you are curious. You don't need a full time job in an industry to experience it. Better yet, don't even bother with the concept of industry, it puts boundaries to your thoughts. Just pick a project that seems interesting: volunteer at a professional event, research the answer to a hard question, build a bottle rocket on your roof top. Choose a project that only takes a few weeks. Make sure it is something you can finish without any blocker. It should be a bit challenging, but not so hard that you feel overwhelmed. Online courses and books are both very helpful in this journey, though you should avoid acquiring too much data without a project to put it to use. Rinse and repeat with another project, and another, and yet another.

These self-directed activities can be a bit overwhelming at first, especially if you have got used to receiving assignments from school. But you will be able to adapt and get better. It is a part of being human, and being young.You need some initial discipline to get started, but once you do, given the project is an object of your interesting, curiosity will turn work into play and discipline is no longer needed.

If you continue down this path, you probably find something that stands out from the rest, enough that you want to come back for more. If you are lucky, you would find more than one. Depends on how good you are at multi-tasking, you might need to choose. Choose the option that leads to more options afterwards. There is a paradox of choice, but advancement in life is measured in possibilities. You go from one stage of education to another because the higher stage give you more options. There are simply more things a guy with a college degree can do compared to one graduated from high school. Building a software product gives your more options than doing business analysis. Once you have built a product, you can get into business analysis later if you prefer the narrow focus. But analyzing business is not going to make you a product manager.

Paulo Coelho's renowned The Alchemist had it that when you really want something, omens is the way the universe points you to the right direction. I have picked up many things in my life, and given up most of them. The ones that stick are usually ones I experienced some sense of beginner's luck. Perhaps it is my omen. Yours might be the same. Or it could be the urge to do something you weren't allowed to do in your younger years. Or the thrill of an audacious plan even people who have known you for years couldn't think you would pull it off (actually, the more people know you, the more likely they are to subject to stereotypical thinking). 

You should believe you have it within, that you will sense the click when the omen happens. Now go give you some more exposure of what the world has to offer.

Saturday, August 31, 2019

Postgres does not use index on gigantic numeric value

Nothing beats a Saturday morning when you wake up fresh and excited, ready for the second sleep, and realize that your Postgres database was harassed over the night and accumulated a number of downtime minutes that is too embarrassing to state here.

My database load looked like this during the outage.

buffer_mapping looks new. Postgres official documentation on this matter seems to be written by Captain Obvious: Waiting to associate a data block with a buffer in the buffer pool. Thanks for nothing. Basically buffer_mapping is a lightweight lock in read operations, my processes were fighting to reserve buffers in which to read data pages.

I have a read problem.

This query accommodates the highest number of locks:

pp_pqsql_prod=> explain select * FROM "big_table" WHERE "big_table"."id" = 9200190224054041915721;
                                           QUERY PLAN
------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..4568847.85 rows=535675 width=1673)
   Workers Planned: 2
   ->  Parallel Seq Scan on big_table  (cost=0.00..4514280.35 rows=223198 width=1673)
         Filter: ((id)::numeric = '9200190224054041915721'::numeric)
(4 rows)

It is a sequence scan, on a 100M-row table, so it is obvious why it caused all the ruckus. What's less obviously is why Postgres performed a sequence scan on a primary key column.

With the help of a colleague, it appeared that given a smaller numeric value, the index kicks in just fine.

pp_pqsql_prod=> explain select * FROM "big_table" WHERE "big_table"."id" = 9200190;
                                              QUERY PLAN
-------------------------------------------------------------------------------------------------------
 Index Scan using big_table_pkey on big_table  (cost=0.57..8.59 rows=1 width=1673)
   Index Cond: (id = 9200190)
(2 rows)

The problem is the size of the queried value. Eventually I stumbled upon this stackexchange Q&A. It can be seen in the first explain that because 9200190224054041915721 was too big, it had to be casted into numeric data type. My primary key was not that big, its data type was bigint. So it had to be casted too, because apple can't be compared to orange. What I have now is a numeric to numeric comparison, and a bigint index can't serve that.

Problem be gone and so was my morning.

Wednesday, August 21, 2019

On organizing Barcamp

If you haven't heard of Barcamp Saigon, then putting it shortly, Barcamp is an open space, also known as an unconference. As organizers, we prepare the facilities to make presentations happen, but both the content and agenda are determined by participants on the event day. Topics are submitted online a couple of months before the event to somewhat ease the hassle. But the voting is strictly limited to the event day, to ensure only the opinions of those who come matter. Topics are then allocated to rooms and time slots accordingly to their popularity. It's that simple.

I have been involving in the Barcamp scene of Vietnam for a few years. There was a 2-year hiatus when it was a make-it-or-break-it period for my employment. Yet eventually, when the dust settled, I found myself, once more, organizing one.

There are more or less a thousand participants in each Barcamp Saigon event. And though we typically only hold one a year, it is still a time sucker, with some hard work, and being a volunteer community project, one pretty much plays the hand that's dealt. Organizing Barcamp is one of the things in my life I consider unusual. Contacting seemingly random people asking for money, dealing with finance and paperwork, and coordinating other people, for an introvert, sound dreadful. Making and answering phone call push my wrong buttons.

Yet I hold on to organizing Barcamp Saigon like my dear life depends on it. I guess because as a twenty-something, I understand how hard it is to get heard in this exhilarating hyperactive city. You kinda have this neat little idea in your mind, but can't seem to find a thought partner to bounce it back and forth, nor an audience to whom the thought is relevant. Heck, even getting invited into a conference (as a speaker) is hard. You are nobody, and the conference you need doesn't exist yet. After a while, you just lose the excitement, the idea is now collecting dust in some closet, in a far corner of your clustered mind. An open space like Barcamp provides all people with an idea to share a platform to do exactly that. You don't need invitation, and the voting board of Barcamp merely shows the topic name, everyone is nobody, and content is king. In a way, an open space is the serverless of knowledge exchange. You get right into the exciting bits.

Barcamp audience is more diverse than it is specialized, more of a melting pot than a silo. If you want to argue the better approach to natural language processing, go to an AI conference; get started with conversational UI (aka chatbot), an UX conference. If you want to make the reservation experience at your restaurant more fluid, well, I guess you are out of luck, there isn't such a space in Saigon yet. But Barcamp is probably the only place you can find people with these three expertise mingling. It reminds me fondly of university time. There was these general elective courses where I got to pick non-IT ones. In those courses, everyone knew something I didn't, and the other way around. And the clash of knowledge, mindsets, and life styles was refreshing. As time goes by, my "tribe" gets smaller and more focused, usually on topics I am very much familiar with. The magic moment when something you have known since forever is basically witchcraft to me get fewer and farther in between. So I learned to appreciate Barcamp for pulling me out of my cave.

To be at Barcamp, in the middle of all communities is, for lack of a better word, a happening feeling. I get to see communities as living creatures, breathing, morphing into shape and form, and reincarnating. That doesn't necessarily mean a good thing. I have been to some Barcamps, at different places. Some were mind blowing. Some sucked though. One was particularly bad that I decided I wanted to do something about it. In a way, Barcamp is a health indicator of its local communities. But unlike GDP, which indicates wealth (1), AQI for pollution, or HPI for happiness (2), this indicator is one where individual actions can make huge difference. I am doing my part.

Open space concept doesn't have to be limited to Barcamp. In fact it shouldn't be. It should be another option in every community builder's toolkit for growing their group of like-minded people. It reduces the stress to find speakers for the next meetup, and give new participants chances to shine. And by the time open space is adopted as a second nature, perhaps Barcamp can retired for it has accomplished what it means to :)

---

(1) Whether GDP can indicate economy growth is a controversial topic that I am not jumping into.
(2) In Zen And The Art Of Motorcycle Maintenance, Pirsig argued that quality cannot be defined. When one defines characteristics of quality, those characteristics cease to be quality and can't describe the whole, which is greater than the sum of its parts. Is happiness quality?



Sunday, June 30, 2019

Random thoughts on a job fair



Random thoughts from a tech expo that I attended just now, not in any particular order. And some thoughts might have nothing to do with a tech expo, I am not apologizing.

Image result for job fair
src: tlnt.com

  • Today I learned that there is career fair, and then there is job fair, each with a slight distinction from the other. The one I went to was probably more of the latter. But really, it was mostly about mascot costumes and freebies. So just.. fair?
  • If you are a company, and spend anywhere between some and shit lot of money for a booth, make sure your representative can represent something.
    • Recruiters should know about their company business nature, organization structure, and for what their job titles actually stand. The use of buzz words like partnership, innovation, or opportunities is bad communication and can't be used to replace solid understanding on business model, job description, or career path respectively.
    • Developers coming to support recruitment are great helps. But they should know that while being there, they are effectively salesmen. If they can't articulate, with a hint of passion, what their job is like in a day, a month, and a quarter, they are just wasting oxygen and space.
    • If you think that's a lot to ask for, you are right. It should be. Hiring is the most impactful task one can make to his organization. Bring your highest caliber executives in, because otherwise TinyPulse is bringing their Director of Technology and awe your potential hires with insightful thoughts and sincerity.
  • If you are a recruiter, you should have a plan to deal with people who have zero interest in your vacancies. The very best candidates are seldom between jobs, they are more likely to be employed and well-paid, you need to poach them to stand any chance. They might not be hooked in the positions, but you can still get them interested in the company. Getting one's contact info doesn't mean shit, people are just polite. Being accountable for answering queries on business model, offering career development path, or simply representing your culture are all significantly more important. And as far as I can tell, nobody is keeping tabs. Be different.
  • If you are an attendee, don't get annoyed if people shove flyers into your hands. They most likely didn't mean any harm. They are just trying to do a good job within their capacity, given the little or zero training they received before hand. Be kind, take flyers, and enjoy a small conversation. You might learn something new while making someone's day.
  • If you are looking for a job, reading between the lines of job titles and their descriptions is a great way to learn about a company's modus operandi, tech stack, and drawbacks. For example:
    • If one is hiring multiple data analyst positions, it has a data-driven culture.
    • Tech stack is revealed through job description and requirement is self-explanatory, but also pay attention to what is not written. Overwhelming mentions of batch processing indicates a lack of stream processing.
    • A company's drawbacks might get reflected in job requirements precisely because issues happen and the company is working on resolving them with fresh meat minds.
  • Similarly, if you want to follow a particular career path, however vague, look at a company's vacancies whose jobs rely on yours. The number of vacancies shows how mature the company is in your chosen field and how much support you gonna receive. For example, big data engineers can look for vacancies of analytics and ML; front-end developers, product and design; product managers, any sign of customer interaction. There should be a healthy combination of both business and technical vacancies for a good network effect. Nothing is worse than spending your time one something with zero impact on anyone.
  • People in outsourcing industry should get panic if they aren't working on hard problems. That you can code the same CRUD operation in 5 different languages is a waste of resource rather than something to be proud of. Local powerhouses like Ahamove or Tiki are solving hard problems that impact the life of millions of people. And it doesn't matter if they can do it in only one language. They are doing it.

PS: apparently, I wasn't the only one who thought JDs is a great medium to learn about a company. Paul Graham used job listings to learn and scale his potential competitors too. http://www.paulgraham.com/avg.html

Sunday, March 31, 2019

Do young developers have it easier?

Image result for dilbert intern


The world of computer programming is changing, fast. In the short 10 years of my career, I have had chances to witness industry standards emerged, demolished, and resurrected. Serverless, the latest abstraction upon abstractions that mankind call programming, has had its glorious days and is now probably on the peak of Gartner Hype Cycle. The time I spent on XML and its abomination of a sibling XSLT is one I would never get back, though the problems have not necessarily gone away. And everyone is deep learning left, right and center, after decades of hiatus.

As we get better at reinventing programming paradigm, streamlining development process, and specializing careers, new crops of developers come into the work force, with perspectives drastically different from their previous generations. But does growing up with an iPhone in their pockets necessarily mean these developers have it easier?

Like youngsters of any species, young developers, despite their non-existential social skills and blissful ignorance, are known for being fast, energetic, and tenacious. And I think this is where a lot of misperceptions come from. Where I give credit to young developers is their stamina. Programming is neither easy nor relaxing. It is a demanding job requiring intense concentration. Young people have the energy, especially when combined with pizza and coffee, to stick to her computers at 2 in the morning, working on intermittent quirks of an API she released earlier, and yet be delight for the new knowledge and that her work matters. Such work is harder when one gets older. He has a life he needs to keep up with. Actually, he is probably pissed that the API doesn't just work the way it should be.

That, however, does not mean young developers get shit done faster. They really don't, otherwise you would see me preparing my retire plan really soon. If anything, they tend to screw thing up faster than The Flash on red bull. I have had almost every interns accidentally drop a database, or delete something they shouldn't have, in their 3-month time. Neither do they learn faster. I am in the camp of believing as one makes progress in his career, he learns faster. Programming knowledge is cumulative. "New" ideas usually have popped up some time before in a slightly different form, in some other language or situation. Young developers, outside of school work, do not spend time tinkering assembly, distributed model, or the 7 layers of the Internet. They rip the benefits of other developers who worked out the details and packaged them nicely so that they are more approachable by others.

Does the fact that young developers rely on more layers of abstraction a bad thing? Of course not. I am glad that I can just sit here writing my post in plain English and not HTML nor CSS. That's exactly how we progress as a species, relying on abstractions built by generations before. In that direction, current mature technology favors quick iterations and shorter time to market. But wait, isn't that good old Agile, what's the big deal? Agile is about building one thing that is small yet works well, then a little more. Yet in an ecosystem with 600k apps in Play Store alone, builders aren't even sure if the one thing they are building gonna be a hit, or miss, till it is out. There are so many high quality reusable building blocks: authentication, real-time database, infinitely scalable database, etc. Writing a new software is now less about constructing and more about figuring out the right combination of gluing things together. The rise of function as a service means young developers can just build it. Work? No? Blow it up. Do it again. All before lunch starts. Older developers have been burned, they don't want to get burned again, they dread the concept of redoing till figuring out.

Though blessed with a beginner's mind, I think young developers still have a long way to go. I don't tend to find old developers that often. Part because IT is a new profession in where I am living. Part because many by their middle age move on to management level, or move out. The guys who remain hand-on throughout their career is really a force to be reckoned with. They are matured as a developer and have learned the art of leadership. They delegate appropriate work to junior people, balance between net contribution and learning something new, and thus saving both theirs and project time. People who have been around a while also see the bigger picture more clearly, both in terms of product scope and project life cycle, which problem can be delayed, and which shouldn't.

Then comes scaling. A new application gaining traction, at some point, would hit the scalability wall. Hard. Like Miley Cyrus on a wrecking ball hard. Scaling is a lot harder than throwing together a bunch of code one did not write *cough* StackOverflow *cough*, and duct-taping till it works. A scalable system takes real dedication, expertise, and a calling to learn more and better ways to be a great developer. And these don't come over night.

Young developers are intelligent, hard working, and excellent at solving the problems they are given.
Old developers are intelligent, lazy, and excellent at predicting problems in 6 months time and building the right foundation today to make it easy when time comes.

Friday, February 22, 2019

Simple example on why LIMIT is not always the best thing for SQL Database

Since our production database grew to the size where querying data without indices became a suicide mission, we have learned that LIMIT does not always translate into faster query time and less work on the machine. Today at work, we ran into a beautifully simple example to illustrate this point, which was perceived as counter-intuitive by more junior teammates.

Here we have a query over a 8M-row table, the condition fits squarely into an index.

EXPLAIN SELECT "record".*
FROM "record" WHERE ("record"."status" = 'not_found' AND "record"."updated_date" < '2018-12-23 15:48:23.008320+00:00');
                                                             QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on record  (cost=256890.59..3475874.26 rows=8448978 width=1740)
   Recheck Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
   ->  Bitmap Index Scan on not_found_records_idx  (cost=0.00..254778.35 rows=8448978 width=0)
         Index Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
(4 rows)


That was still lot of records, so we were hoping a LIMIT clause would shorten the execution time.

EXPLAIN SELECT "record".*
FROM "record" WHERE ("record"."status" = 'not_found' AND "record"."updated_date" < '2018-12-23 15:48:23.008320+00:00') LIMIT 1;
                                                              QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..0.46 rows=1 width=1740)
   ->  Seq Scan on record  (cost=0.00..3923250.74 rows=8448978 width=1740)
         Filter: ((updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone) AND ((status)::text = 'not_found'::text))
(3 rows)


Only that it didn't. Adding the LIMIT clause changed the query plan from Bitmap Index Scan to a Sequence Scan, which is about the worst thing we want to do on a 8M-row table. It is a typical "optimization" of the planner, who thought that the query with LIMIT clause was too small.

Operation wise, an index scan is more expensive than a sequence scan. An index scan would require to read the index pages first and then read the data pages for relevant rows. The sequence scan only deal with data pages. And so when the LIMIT is small, combined with the table statistics, the planner is tempted to believe there are enough (random) rows that match the filter condition, which makes a sequence scan cheaper.

In fact, somehow this table statistics suggests that every LIMIT is too small till it is half of the table!

EXPLAIN SELECT "record".*
FROM "record" WHERE ("record"."status" = 'not_found' AND "record"."updated_date" < '2018-12-23 15:48:23.008320+00:00') LIMIT 3000000;
                                                              QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..1393038.57 rows=3000000 width=1740)
   ->  Seq Scan on record  (cost=0.00..3923250.74 rows=8448978 width=1740)
         Filter: ((updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone) AND ((status)::text = 'not_found'::text))
(3 rows)

EXPLAIN SELECT "record".*
FROM "record" WHERE ("record"."status" = 'not_found' AND "record"."updated_date" < '2018-12-23 15:48:23.008320+00:00') LIMIT 4000000;
                                                                   QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=257234.59..1781198.16 rows=4000000 width=1740)
   ->  Bitmap Heap Scan on record  (cost=257234.59..3476218.26 rows=8448978 width=1740)
         Recheck Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
         ->  Bitmap Index Scan on not_found_records_idx  (cost=0.00..255122.35 rows=8448978 width=0)
               Index Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
(5 rows)


Adding an ORDER BY clause into the query brings structure to the search and guide the planner to use the index

EXPLAIN SELECT "record".*
FROM "record" WHERE ("record"."status" = 'not_found' AND "record"."updated_date" < '2018-12-23 15:48:23.008320+00:00') ORDER BY "record"."imported_date" LIMIT 1;
                                                                      QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=3518127.15..3518127.15 rows=1 width=1740)
   ->  Sort  (cost=3518127.15..3539249.59 rows=8448978 width=1740)
         Sort Key: imported_date
         ->  Bitmap Heap Scan on record  (cost=256898.59..3475882.26 rows=8448978 width=1740)
               Recheck Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
               ->  Bitmap Index Scan on not_found_records_idx  (cost=0.00..254786.35 rows=8448978 width=0)
                     Index Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
(7 rows)

Actually, any random ORDER BY would do

EXPLAIN SELECT "record".*
FROM "record" WHERE ("record"."status" = 'not_found' AND "record"."updated_date" < '2018-12-23 15:48:23.008320+00:00') ORDER BY random() LIMIT 1;
                                                                      QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=3539253.59..3539253.60 rows=1 width=1748)
   ->  Sort  (cost=3539253.59..3560376.04 rows=8448978 width=1748)
         Sort Key: (random())
         ->  Bitmap Heap Scan on record  (cost=256902.59..3497008.70 rows=8448978 width=1748)
               Recheck Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
               ->  Bitmap Index Scan on not_found_records_idx  (cost=0.00..254790.35 rows=8448978 width=0)
                     Index Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
(7 rows)


However, that is still far from optimal. In order to return the first row, the database first needs to fetch all rows matching the index condition, and only after that, sorts. This creates strains on the machine memory and maybe even disk swap.

Index is actually ordered structure (BTree). The most optimal query is the one using one of the indexed columns for sorting.

EXPLAIN SELECT "record".*
FROM "record" WHERE ("record"."status" = 'not_found' AND "record"."updated_date" < '2018-12-23 15:48:23.008320+00:00') ORDER BY "record"."updated_date" LIMIT 1;
                                                                QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.56..1.90 rows=1 width=1740)
   ->  Index Scan using not_found_records_idx on record  (cost=0.56..11280384.47 rows=8448978 width=1740)
         Index Cond: (((status)::text = 'not_found'::text) AND (updated_date < '2018-12-23 15:48:23.00832+00'::timestamp with time zone))
(3 rows)

This, in fact, is even more effective that the original no-order query, with or without LIMIT.

Friday, February 1, 2019

2018 - Shit am I getting old?

Roughly 4 years ago I put together The Transforming 2014. In retrospective, it was a great year. It felt exactly what youth should feel like, feel like I can afford to fail and bounce back, that opportunities are there to take, and that I am the master of my life. 2018 feels very different. The year followed a trajectory I have carved out over the last few years. It is not particularly eventful, the changes are there, but not exactly tangible. For the lack of eloquence, I would put it similar to when one cries, all the sorrows and memories and grudges build up inside, but till the instant everything bursts out in the form of tear drops, the entire thing is internal and invisible. If a tree falls in a forest and no one is around to hear it, does it make a sound?


Size and Duration matter

Before I got accused for having lewd thought, this is a note about Parcel Perform. That's what I do. I am a software engineer here. For the fourth year. I have never worked on a single project that long, and I definitely have been staying in Vietnam longer than my intention.

We build a product around the belief that logistics optimization is the next frontier of e-commerce war. And in that business, size matters. Specifically, dataset size, which grows by dozens of GB every week. At that speed, what worked a month ago, wouldn't work for the next. The job description is as pure as it can get, find a way to process incoming data most efficiently before the size squashes you like an insignificant insect in tropical storm, all while adding increasingly advanced features to deliver values. Or to build a train from the first material you find, all while keeping it running on a century-old rails, hoping you would make it to the next station, if you prefer to speak metaphors.

I can no longer just add a column with a default value to my database, because that would update hundreds of millions of rows and grind everything to a halt in the process. Everything I thought I knew about software is put into tests. At times, I feel like an imposter, a fraud. I feel alive every time anything breaks. Which is about every day.

This is also my third time being employee #0 and building a tech team from the ground up. I have a knack doing this. I know which minimal unit of work provides most impact. And I know what developers need to level up their career. But I hope I won't have to repeat the same thing in my next job. The first year of every startup is to build glorified excel sheets. The first engineer's day is always a constant juggle between development, test, and expectation management. It gets old.

I have hung around with Parcel Perform long enough to pass that stage. We get to work on interesting challenges unique to our business. Our tech stack moulded around us. We have a support network so that the weight of the entire system does not have to rest on a single shoulder. It takes time for things to come together, and so, duration matters.

Creativity Winter

As much as I enjoy seeing my technical skills grow in the last couple of years, the same can't be said about my creativity outside of work.
  • Between 2016 and 2018, I wrote 13 posts. I wrote 19 posts in 2015 alone. 
  • At some points, my photo app only shows content on white board I took post-meeting.
  • The last Barcamp in Saigon was in 2016.
None of these was an act of consciousness. Like, I never decided I didn't need this in my life any more. I noticed that my most creative period was when my life happens between airports and on MRT rides. Somehow the constant scenery change kept my mind alert and fresh. Though I successfully prevented my career from repeating itself, the life outside of work got stuck in an explore and exploit paradox. On the one hand, there must still be stuff out there to give me an adrenaline rush. On the other hand, comfort feels good. I long for a kick start to get out of this stage of limbo.

Not all hope is lost. I am writing this, albeit sluggish. A kid at work got into photography recently, perhaps I can get a partner in crime. And Barcamp is back in 2019. (Surprised? Me too!)

Pretty sure we are the only company throwing morning kayak sessions in the city

I was in a HackerX event in 2018. Basically speed dating for developer employment. And that was literally how I started my part of flirting duty. Getting a tandem kayak was pretty much an impulsive purchase. But it was a great one. I wondered why I didn't think of that earlier. In Vietnam, I get to pretty much drag the boat and pop it in any body of water I feel like. That my office is a few hundreds meters away from a pier also helps. The same can't be said for any other countries I have lived, due to either regularity or location. Be it a morning exercise before work, or a more adventurous weekend, it's good fun and brings friends together. One at a time. There are only two seats on a tandem kayak, damn it.


I wish 2018 was a grandiose. Instead, I just got lot of doubts. I had thing figured out, or my life just got boring? The progress I made in my career was solid, or I was making excuse and succumbing to familiar comfort? I've got the right balance, or work was slowly gulping my life? I still identify myself more as a 20 year-old kid scared shitless in his first job, rather than a 30 year-old I would be when this year ends. Well, I guess that's it right? Till this year ends, I have another year to live in my 20s and do stupid stuff. 30s uncertainty can wait, its time will come later :)