Gordon Koo

14 Apr 2014

I used to think status updates and performance reviews were a waste of time. My thinking was: “In the time that I’m writing down the things that I did, I could be getting even more work done!” So I would spend the minimal amount of effort on updates and reviews. After all, the people with whom I work know the quality of my results. As long as they’re happy, everything will be fine.

Early this year, we had our performance reviews at work. I think this is the first time I’ve really come to appreciate the purpose of performance reviews. In the past, I thought about them from a negative perspective: Is this employee underperforming? Does the quality of his work hold up to that of his peers? Side note: Thinking back, this type of thinking may be a relic of my Asian American upbringing, during which my work was always under heavy scrutiny.

I now realize that performance reviews are a way of measuring progress throughout the year. What have I accomplished? How have I grown as a software engineer? And as the saying goes, if you don’t measure something, you can’t improve it. So ultimately, performance reviews are about improvement. What did you do right? What did you do wrong? How can you reach the next level?

It also helps your manager build the case for rewarding you for your good work. Most managers are not the ones making decisions about raises and promotions. However, they are the ones who have the most relevant input for those decisions. The VP of Engineering is not going to be familiar with very engineer’s work output and has to rely on information from team managers to issue raises and promotions. Your manager isn’t going to be able to give a glowing recommendation if all you write is, “I was awesome!” on your self-review.

I used to think that if you’re judged by merit, then your work should speak for itself. The reality is closer to: you may be judged by merit, but if nobody knows what work you did, it doesn’t matter. This is why the advertising industry exists.

In the past month, I’ve been keeping an Evernote notebook titled “Work Journal”, in which I jot down a few lines describing the work I do everyday, assuming I remember. (I’m still working on the remembering part.) I’m approaching status updates and performance reviews from a new perspective, and I think it’s going to make a big difference in 2014.

08 Mar 2014

Today I discovered, to my unpleasant surprise, that JSON.stringify does not stringify arrays
properly in Chrome.

JSON.stringify({ numbers: [1, 2, 3] }) // "{"numbers":"[1, 2, 3]"}"

I’ve tried the same thing in Node and Firefox, and they return what I expect:

JSON.stringify({ numbers: [1, 2, 3] }) // '{"numbers":[1,2,3]}'

It seems like this has been a problem for quite a while now!
This post is from October 2012 and
reports the same behavior of Chrome v22. I’m seeing the same issue today (March 2014) on Chrome v33.

Edit: I’ve discovered that the culprit is Prototype and how it supplies a toJSON
method for arrays. The reason I was seeing this on Chrome only is because I was testing JSON.stringify on a
different page in Firefox – one without Prototype.

24 Mar 2013

When my dad immigrated to America from Hong Kong, he carried everything he owned in his suitcase. By day, he was a college student. By night, he worked a night shift at the Ramada Inn. If he was lucky, he would squeeze in a few hours of sleep before the start of the next day. He would go from door to door, inquiring about work. Any work. Whatever the job was, he was ready to do it. Mowing lawns. Washing windows. If he didn’t know how to do it, he was willing to learn how. For him, work wasn’t about finding the best perks or a company whose mission he believed in. It was about surviving in a foreign world still rampant with racism where he played the role of the outsider. He would eventually work his way to becoming a city planner. He had lofty notions of giving back to the community that he had come to know as his home, but he found that workplace politics created a different reality than he expected. He held a very respectable job, but though he had come so far from when he first arrived, his work was the source of many frustrations. The day he retired was a day of relief.

When my mom immigrated to America from Cambodia, she had a hundred dollars to her name and the only family she had was her sister. The two of them were taken in by a pastor and his wife in Stockton. She studied at the University of the Pacific, and while she was there she met my dad through a mutual friend. Her dream was to be a teacher. She tried to follow this dream, but the only work she was able to find was that of a substitute teacher–hardly a sustainable career. My dad recommended she choose another line of work instead, and so she became an accountant. Being an accountant wasn’t her dream, but maybe it would help her achieve another dream of hers: the dream of providing a better life for her children.

Because of my parents’ hard work and sacrifices, my sister and I were able to grow up and get a good education at a prestigious university. I am now employed in an industry where I am regularly solicited by companies to work for them. Companies compete to provide the most attractive benefits to lure one of the most highly sought after contingents of this country’s workforce, of which I am a part. My biggest worries about work usually involve what kinds of things I’d be most interested in working on. I say this not with a sense of entitlement, but in awe of the options available to me.

One day, my parents were reminiscing about the past. My mom looked around at the house–at her life–and said, “I can’t believe how lucky we are.”

09 Mar 2013

Fill in the blank: eval is ____.

If you’ve been working with Javascript for any substantial amount of time, there’s probably no thought required in this task. For those who are new to Javascript, the completed phrase is: eval is evil. The phrase originates from Douglas Crockford, the Javascript guru whose words many regard as scripture. You can read more about the eval function on its MDN page.

The bad taste that eval leaves in the mouths of Javascript developers is so ingrained that the reaction is almost Pavlovian. Let’s parse this motto to uncover the real meaning behind such a powerful phrase.

Except we can’t. The only meaning we can extract from those three words is that the usage of eval is a no-no. While Crockford’s other recommendations are accompanied by rationale–some keywords result in confusing code, some coding practices produce evasive bugs—the admonishment of eval comes with no such explanation other than the decree of its nefariousness.

Until the machines rise up against us–and it’s only a matter of time before they do–I can’t seriously consider a programming keyword evil. The reasons for avoiding the eval function are well-known and fall into three main categories: security, performance, and maintainability. Perhaps Crockford’s well-known slogan could have been: “eval is an overly powerful function which produces code that is difficult to debug, with serious security and performance implications, commonly misused by many, for which there is almost always a better alternative.” I’ll concede that this phrase isn’t as pithy, and it doesn’t roll off the tongue in quite the same way, but it would have provided more information for the betterment of developers everywhere. I’m actually not opposed to the “eval is evil” phrase. It’s really easy to remember, as evidenced by the readiness with which it is recited, and gets its point across succinctly. I wouldn’t be surprised if there’s a tattoo out there of “eval is evil.”

Most Javascript developers already know why the use of eval is discouraged. But let’s face the facts: Javascript developers aren’t the only people who write Javascript code. A lot of non-Javascript programmers have written some Javascript at some point in their lives, due to its de facto status as the programming language of the web. And when these programmers are learning how to write clean, secure Javascript code, it’s in everyone’s interests to be upfront about the why’s behind the do’s and don’ts.

The “eval is evil” phrase is just one example of how criticism frequently tends to be too general. I’ve been guilty of giving overly general criticism myself, and I’ve been making a conscious effort to be more specific when giving feedback. There are benefits to giving specific:

You demonstrate that you actually know what you’re talking about.

You’re in a better position to suggest ways to improve the thing you’re criticizing.

You seem less like you’re whining. Or, you’ll seem less like an ass.

If you can’t articulate why you dislike something, or if you have no suggestions for improving the thing you’re criticizing, you’re in no place to criticize it. Even when you’re giving positive feedback, being more specific is always more valuable for the party receiving the feedback. In general, talking in specifics is the easiest way to start having more constructive discussions.

01 Mar 2013

This post was written for a technical audience, but its core ideas can also be applied to other fields.

There are many reasons for a software developer to work on a side project. It’s a good way to keep a pulse on technologies that are currently trending in the industry. It helps you keep your programming skills sharp. And it’s fun! Or, at least it should be.

But then there’s that thing we call “life” which can make it difficult to start a side project, let alone finish one. We’re often spending so much time trying to stay afloat in our hectic schedules that it can seem impossible to squeeze a side project in.

I started working on my first side project two years ago, so I am no expert on this matter by any means. During these past two years, I’ve made observations about how I got started on the side projects I’ve started and why I was able to finish some and not others. What follows is neither particularly groundbreaking nor an official guide to working on a side project, but merely the aforementioned observations I’ve made which you may find helpful.

Work on something that interests and excites you

I hesitate to write something that sounds so painfully obvious, but it’s very important. A side project should be something that you get excited about working on. When you wake up on Saturday and you start to go through your agenda for the day, what is your gut reaction when you consider the idea of working on your project? If your thoughts begin with the words “I should probably…”, you’re not off to a great start. If they begin with, “I get to…” or “I finally have time to…”, then that’s starting to sound a little better!

Take breaks

Your project should be many things. It should be fun. It should be something you look forward to working on. What it should not be is a chore. If you’re working on your project and you’re not enjoying it anymore, hit Save, get up from your keyboard, and go exercise. Play video games. Go shopping. Whatever it is you do to unwind, do it. Don’t come back until you feel ready to work on your project again, whether it takes a day, a week, or a month.

On finishing a project

The level of importance for completing a side project varies from person to person, and even from project to project. Some side projects serve as a means for experimenting with new technologies. It’s completely fine to leave those experimental projects unfinished. For the rest, however, having a goal to finish can be very beneficial. The desire to finish your project adds motivation to working on it, and it’s also a nice bonus to be able to show your work to others once you’re done.

Working on something you find exciting (point #1) is especially important for taking your project through to completion. If your project is even remotely substantial in size, you’ll be spending a great deal of time on it, and you may begin to feel fatigue from working on it after some time. The novelty of your project idea might diminish over time, and when that happens, you’ll want as much residual excitement to remain as possible.

One project at a time

While you work on your project, you may start to form other project ideas in your head and get the urge to work on them. That’s great! You can never have too many ideas. Write them down so you can work on them later, but don’t switch to another project until you’re done. Trying to work on two projects concurrently is the best way to ensure that you will complete neither. If you do switch projects, either have a concrete idea of when you’ll pick up where you left off with the original project, or acknowledge that you probably won’t finish the project.

By the way, it’s perfectly fine to end a project without finishing it. That just means that something about the project changed from the time that you started it. It might be technically infeasible. Maybe you’ve learned that your idea doesn’t make sense. Or maybe, for whatever reason, it’s just not fun anymore. Whatever it is, the important thing is to take that information and learn from it.

Find a time that works

Working a slot into your regular schedule is the best way I’ve found to sustain progress and motivation for a project. Make it a ritual. For me, it’s the first thing I do when I wake up on the weekends. I’ll go to my local coffeeshop for a couple of hours, sit and write out some code, and I’ll be done before lunch. This has worked great for me because there are very few social obligations that begin before noon. Furthermore, I’ve found that finding a reoccurring time where I work for a smaller chunk of time (one or two hours) has been more effective than finding those larger chunks of time (three to four hours).

Have fun!

If you’re not having fun, then there’s really no reason to be doing it. Creating something new should be fun and exciting, and when you do it right, it can be one of the best feelings in the world.