This is an enjoyable year. Working gradually goes into the fast track. It is nicer to be around with awesome people and to have made quite a few good friends. It becomes easy for me to either find someone playing tennis in the early morning, or grabbing a drink in the late night, or both:)
There are three more friends who became my ex-coworkers. I felt sad every time when someone left. The bad start came from GC one year ago – “hi Q, can I talk to you in private…. I think it is better to come from me than hearing from…”… I could not say anything but to hug that guy – and similar conversations happened three times (!!) this year. I love the people that I’m working with, but hate the feeling of seeing their left. It is not really ok though I’ve gone through it multiple times. Well… on the bright side, I have several more friends outside of the office, whom I can occasionally catch up with, and talk about something other than work.
It is very nice to have Donny, my coach, and Sean to play tennis with me. I basically take a lesson with Donny every other week. We’ve only been able to work on two aspects during the whole year: my forehand and backhand ground stroke. I still remember my 1st lesson with him. After hitting for about fifteen minutes, I asked him “how can I improve, coach?” He just smiled a lot and tried to sort out hundreds of answers in his head, “let’s just work from the very basic ones”. It was a long and struggling process to remove all unnecessary movements. Now my forehand is more consistent, and I am able to put much more force on each stroke and also maintain at my highest level for a much longer time. But my backhand is still half-baked… It is on and off even within a set.
Sean is a wonderful person. We’ve played 30+ times this year, and I won once (or twice?)…=P I’m very grateful that he is still willing to play with me. More importantly, my other tennis matchups might either show up late on the court or have a negative attitude now and then, since the match doesn’t matter at all. But Sean always arrives on time and tries his hardest to save every single shot and to win a point. I enjoy very much the competitive attitude he brings to the court.
Programming, as my biggest hobby, is hard to separate from my work. Besides, I agree with the assertion that one should treat self like a startup. And there is no better place to learn all relevant skills than actually programming in a rising startup =P. I put these two together. Here are several things that I’ve learned during the past year.
- Communication is vital, for both working individually and working in a team. There are three parts for one successful communication.
- Do the homework beforehand, to make clear the real target, possible conflict interests, who should be involved in the conversation and when, and etc.. Tech spec is an excellent way to arrange all thoughts, and to work as a checklist to make sure there is nothing major left behind.
- In order to be persuasive, it’d better to make all requests prioritized. There is normally one main goal to shoot at, but it is also great to take all the concerns and suggestions and put them into the backlog. We don’t know what we don’t know. This is the most dangerous thing that could happen in a project.
- Followups. No matter how hard the nature of a problem is, it can be divided into small fractions of actionable items, which are the smaller the better. The deliverables are the consequence of the actionable items. There is not at all valid estimations for either time or workload until there are tiny pieces of deliverables.
-
De-risk a project as early as possible. It is much easier said than done since every single project is novel and unique. In general, there should be sufficient time beforehand to research, lay out the strategic blueprint as early and detailed as possible, and to make it reach broad audiences. Meanwhile, it is always better to split one project into small pieces so that they can be delivered incrementally and to take rigorous validation in every iteration to decide if we are using the right approach to solve a problem that is worth working on.
-
Retrospective. It is similar to the post-mortem but on a smaller scale. I don’t like it because by the time I have such a thing in my calendar it means something has gone wrong. On the other hand, however, it is a good place to collect the afterthoughts: what happened, why this happened, and more importantly what can be done to prevent it from happening again.
- To debug some obscure issues, especially for those that are time dependent or happen in a probabilistic manner. The best way is to use the source code. This is the only way that has never failed. Documents get out of sync; comments might lie, and colleagues’ memory might not be reliable. The source is eternal. The best way to find out what the code does is
- Understand what it is trying to do
- Understand what the implementation should do
- Test this understanding with test code
- Repeat the three steps above as many time as needed…
- As a last resort, if nothing is making sense, fire up the debugger on the right piece of code, which can be only achieved if the underneath mechanism is actually understood, and see what you have misunderstood.
- See if the compiler is lying …
- Keep learning and keep an open mind. An incomplete list of what I’ve dabbled in during the past year includes the network structure of the internet service providers, design patterns, D3 and Javascript, the mighty and awesome Haskell, a little bit Julia, and the enjoyable competitive programming.
Resolution in 2017:
- Launch a project written in Haskell
- Win some more money from Topcoder (:
- Read at least one research paper (in any topic) per week
- Read three books in computer science
- Better at backhand and serves