allenc allencheung

Recounting a 14-Year Career in Software, Part I

A couple of months back, someone asked me about my career in software development and the various lessons along the way. I have relayed individual stories in the past, but I never got around to writing it down in full. Here is one such attempt.

Along the way, I’ll bold insights and lessons I’ve picked up from those experiences.

A Tough Job Market

I always like to start the story in the early 2000s, a time when the computer science major first enjoyed the hype and popularity from the software industry. The dotcom boom was happening, but by the time I was ready to graduate, we were 2–3 years after the party had stopped. These unique conditions meant that lots of smart people1 pursued a CS degree only to face a dry and unfriendly job market.

I’ll admit that I started out with an advantage here; I made it into the CS program at Cal, which is still one of the top computer science universities in the world, and did well in my coursework. I was interested in computer graphics2 and briefly considered a career at nearby Pixar, but eventually ruled it out due to their reputation of grueling work hours with below average pay; industries like graphics and video games will intrinsically attract new and young talent and will use that to their fullest advantage. Though my GPA wasn’t an issue, internships weren’t as prevalent a decade ago, and I spent my summers doing part-time work on campus and playing video games. My profile as a new grad hire was iffy at best.

A number of my classmates tried to find a job, had every prospect fall through, and ended up enrolling in Ph.D programs as a backup. I had interviewed with some of the big tech companies—Microsoft, Amazon, Applied Materials—and a smattering of startups and mid-sized companies as a backup. I hated the process back then, and it hasn’t improved much since; new grads are gauged largely on their technical acumen, and that’s defined to be the ability to pattern match algorithms and data structures to toy problems under time pressure. I hope that my mediocre performance on those kinds of interviews proves that you don’t have to be great at HackerRank to be a good software engineer, or to have a successful career in tech. That said, without substantial work experience, the only way companies can really gauge ability is via highly technical interviews correlated with academic concepts.

I ended up accepting an offer to go to a little-known fintech company called FactSet Research Systems.

Our Own Browser

FactSet is a company that sells aggregated and normalized financial data to finance professionals; it is meant to be an alternative to the industry standard Bloomberg terminal. It was started in the 70s, and the technology stack that the first engineers used carried itself into the 21st century: the servers ran an old OS called VMS, while the client was Windows program started in the early 90s.

I landed on a team responsible for maintaining and slowly evolving that Windows program. The architecture was largely server-based, where all of the data, business logic, and UI layout were defined on the server and then have the relevant bits sent to the client to be rendered within our program. In practice, our team had to maintain an SDK for the rest of the company, enhance the proprietary protocol for client/server communications, and keep the client compatible with each successive version of Windows3.

But even back in 2004, there were already glimpses of the level of complexity and interaction web apps would eventually have: Gmail wowed its beta users both due to the 2GB storage limit and the richness of the client within a browser. Many a time, I ended up trying to port a standard browser component, only to implement an inferior facsimile with half the functionality and only usable on a VMS system implemented in C++. Software, especially if it works, lasts much longer than you’d want.

To Build on the Web

Motivated by what others were doing with websites and a startup revival now a couple of years away from the big crash, I started to spend my nights and weekends picking up web development. In some ways, it was easier than my day job; HTML and CSS are declarative languages, and JS was and still is somewhat rudimentary compared to the complexity of C++ and Microsoft’s evolving programming frameworks4. I didn’t do anything fancy, even by 2005 standards: I just wrote my own blog engine and kept on rewriting it to pick up new skills. I think forced myself to learn CSS, JavaScript and DOM, AJAX, and design principles, in that order, with each new version of my now-defunct blog.

I didn’t know it at the time, but I was following a well-trod path of self-taught front-end development, one that would define my career for the next 5 years. My skillset—a formal CS education, an interest in graphics and UI/UX, years of experience professionally building UI toolkits, and side projects that targeted the latest technologies—turned out to be fairly unique. And when I figured out how I was different from a typical software engineer, I leveraged that difference to new opportunities.

I ended up staying at FactSet for 3.5 years, which was probably a year longer than I should have. I did meet some good friends in my time there, but I was tired of just reading about the exciting world of startups and decided that I should try to participate. I got referred by a friend to a nascent social network, and made the jump to the San Francisco waterfront.

Part II

I realized about halfway through this post that this’d be way too long for a blog post, so I’m splitting it into multiple parts. Startup hijinks forthcoming!


  1. Plus a bunch of people who weren’t that smart, but saw the ridiculous salaries—by those days’ standards—new grads were getting.

  2. I was one of the early students that established the UCBUGG group at Cal.

  3. We had a full-time engineer whose main responsibility was maintaining the Windows installation program. Really.

  4. I had used win32, MFC, ATL, WPF, OLE, and a bunch of other Microsoft-specific tech, relying on thick reference manuals and the Visual Studio debugger.

By allen
allenc allencheung

Elsewhere