Archive for the ‘Work’ Category

It’s been a while…

Wednesday, August 27th, 2008

I realized that it’s been quite a while since my last update. Unfortunately it seems like the amount of interesting stuff I have to write about is inversely proportional to the spare time I have available for writing… ;)

Anyway, I figure I’ll try to get back into the habit of publishing smaller posts, but hopefully more regularly. Let’s see how it goes…

Ever since I went back into startup life four months ago, I’ve had the chance to play with a lot of exciting technologies, so there’s plenty of stuff to write about. Below are just some quick notes and mini-reviews, but I’ll be writing more about the various topics in the future.

  • Merb
    • This is quickly becoming my web framework of choice. It is well-thought-out, highly modular, and ideally suited for both small webservices as well as large scale websites.
    • The default application layout is very similar to Rails, making it easy for Rails developers to get up to speed on Merb. However, it also supports highly compact app layouts that are ideal for smaller webservices.
    • I’m sure I’ll write more about Merb later.
  • DataMapper
    • An awesome ORM framework, and one of several supported by Merb. Like Merb it is still pre-1.0 and therefore still evolving a lot, but it is already quite solid and very powerful.
    • More on this later…
  • RSpec
    • For my new projects, I have been using RSpec exclusively, and after a small learning curve it has really grown on me. Granted, I’m probably not taking advantage of all its features (for example I haven’t actually written my own matchers yet), but with a bit of discipline (and a heavy dose of mocking and stubbing), specs written in RSpec are probably an order of magnitude clearer and more readable than with Test::Unit.
    • I took the opportunity to get rid of test fixtures as well (and good riddance!)
  • Ruby in general + Rails
    • Right now I am working with a mix of Merb projects, Rails projects, and standalone Ruby apps.
    • I’ve had the opportunity to build a Ruby based framework for SMS based mobile apps, consisting of a processing pipeline with several independent services that communicate via asynchronous message queues, with some DSLs and meta-programming thrown in for good measure. This has allowed me to become much more familiar with Ruby than I was back when I just played with some Rails apps.
    • There’s definitely a right language for every task, but I have to admit that I find it harder and harder to imagine ever going back to Java…
  • Amazon Web Services (EC2, SQS, and S3)
    • Using Amazon AWS as a deployment platform is a whole new experience for me, and I am very impressed with the various services. They were already solid when I started working with them, but in the past few months Amazon managed to launch several major features (such as static IP addresses and persistent storage) that significantly lower the barrier of entry.
    • EC2 is particularly well-suited for the type of loosely coupled architecture we are developing, and I envision eventually being able to dynamically start and stop instances to adjust both to general growth over time, as well as fluctuations throughout the day (as mobile apps tend to exhibit certain usage patterns.)
    • SQS is a convenient way to tie the different components together (albeit with some limitations, such as an 8KB maximum message size), and of course S3 is available for any storage needs.
    • I will definitely blog in more detail about various AWS strategies and recipes.
  • Git
    • We’ve been using Git (and GitHub) for all new applications. We’re definitely not exploiting it to its full potential so far (given that we’re only a few developers that mostly work on different products, we haven’t had much of a need to leverage Git’s distributed nature), but I am definitely growing quite fond of it.
    • It is extremely fast, I love being able to commit code and browse the revision history even without a network connection, topic branches are convenient and powerful, and more.
    • Tool support is definitely still a weak point, but for the most part I’ve been happy using Git on the command line.
  • Lots of sysadmin / deployment stuff
    • System administration is definitely not my forte, but I get by (at least on Linux; Joyent’s Solaris servers still manage to throw me off occasionally…).
    • I have had a chance to get more exposure to deploying Rails apps (including Mongrel, Monit, Passenger, etc.), as well as building a deployment framework for AWS from scratch.
    • Deploying applications to such a cloud based architecture is quite different from a typical Rails or LAMP stack, but I’m quite happy with the initial version of the deployment framework I’ve built. I’m essentially using S3 to store versioned app packages (which correspond directly to a Git tag) as well as third party gems, and a configuration file (also in S3) for each environment (such as production or staging) defines which version should be deployed on it. Each service regularly polls S3 for configuration changes and updates itself if appropriate. We use a single machine image and configure each instance via user data upon startup, which allows the instance to pull down the appropriate files from S3 and start running the service it is intended for. A small set of Rake tasks manage deploying releases and promoting them from one environment to another one.
    • There are still some challenges ahead, though, such as a proper logging system (I’m planning to migrate our apps to log to a central syslog server.)
  • Various web based services, including Google Apps, GitHub, Lighthouse, Scout, and Ylastic
    • All of these are great utilities.
    • Google Apps is a must-have; any startup should use it at least for email and calendaring, as well as collaborating on documents or spreadsheets. We also use Google Sites as our Intranet / Wiki.
    • I have briefly blogged about Scout before and will likely blog about various Scout plugins in the future.
    • GitHub is an amazing application, not only for hosting our own source code, but also for following the various open source projects we depend on (such as Rails, Merb, and DataMapper.)
    • We haven’t had a chance to really dive into Lighthouse yet, so the jury is still out on it. I do believe that its refreshingly simple, tag based approach should work pretty well, though.
    • Last not least, Ylastic has been invaluable and a great way to manage our EC2 instances, images, debug SQS based apps, browse S3, and more. I’ll probably write up a more thorough review soon.
  • Honorary mention: Pandora and Airfoil
    • For keeping us supplied with music and allowing us to stream it to our Airport Express. :)

That’s it for now. Hopefully it won’t be two months before my next post…

On Leaving Google

Sunday, April 13th, 2008

As some of you may know, I have decided to leave Google and go back into the startup world. Friday was my last day at Google, and even though I normally don’t blog much about my job, I figured I was due for an update.

First off, Google is an amazing company. Especially for a company of this size (and impact), it is highly impressive that they have managed to maintain this kind of work environment, company culture, and integrity. On the most basic level, there are all the perks, from great health benefits to free food (there are about 15 cafeterias on the Mountain View campus alone, many of which offer breakfast, lunch, and dinner), micro-kitchens with free snacks (including fresh fruit or fresh cut carrots and celery), on-campus gyms and a beach volleyball field, and more. Another great thing are the many tech talks (usually there are at least a couple every day), which feature both internal and external speakers. There are also many opportunities for training. In the one year that I have worked at Google, I had the opportunity to take a one-day class on Agile Estimating and Planning, as well as an excellent four-day workshop on Design Patterns and Refactoring, and numerous Google and product specific classes. Then there are the various off-sites and team building events, which probably take up another good week each year. Not many companies send their employees to Disneyland for three days… And of course there’s Google itself, with its various products that have become so ubiquitous and synonymous with the web that life would be difficult to imagine without them. Anybody remember the web before Google Search came along? Let me give you a hint: it sucked! But even newer products like Gmail, Google Reader, or Calendar have caught on quickly and become established as best-of-breed applications, and I definitely felt proud to work at the company that has built all of these applications. And speaking of work, the actual work environment is also nice in many ways: Every engineer gets either two 24″ or one 30″ monitor, as well as a company laptop (either MacBook Pro or Thinkpad). Depending on which project you work on, you might get to work with innovative internal tools and frameworks (such as BigTable), and I have definitely developed an entirely different perspective on scale, which humbles any project I’ve worked on before. Then there’s the community. In general, Googlers are a great bunch, and very smart. There are internal mailing lists on pretty much any subject, and you can pretty much guarantee that you will be able to get a solid answer to whatever question you might have (work or non-work related). In fact, this reminded me quite a bit of Usenet, back when it was still popular and usable, and not totally overrun with idiots. Of course, keeping up with all of this can become quite a time sink as well… Google is highly engineering-driven, and engineers enjoy a lot of trust and power, which is a very different and refreshing experience from working at a more product-driven company.

So if everything is so great at Google, why am I stupid enough to leave? And part of me does indeed feel a bit guilty about not being able to fully appreciate and enjoy working at Google — after all, there are many people out there in the world that have dreary and monotonous minimum-wage jobs, without any benefits or perks to speak of. But in the end, I have realized that I am just much more of a startup person than a big-company person. Perks and everything are great, but this is ultimately not what motivates me. At an early stage startup, every single individual has a tremendous impact on the company (good or bad…), along with a much broader set of responsibilities (everybody has to wear many hats). Then, there’s the pioneering spirit, which is extremely energizing and contagious. These days, it seems like a lot of the true innovations are made at small startups, which have the benefit of being orders of magnitude times more agile and efficient than a large company will ever be. Sure, many ideas don’t go anywhere, but every once in a while, something new comes along that leaves a big footprint (and let’s not forget that even Google started out like this). Last not least, there is of course a significantly bigger upside to working at a startup. Of course the harsh truth is that most startups fail, but at least there is that 1 in a 10 chance of being tremendously successful (and the sense of actually being able to contribute to this chance). As a recent Google employee, I would have never gotten rich there, even if the stock had doubled or tripled in price.

There are a few other Google-specific problems I should mention as well. For one thing, it is unlikely to initially be able to work in an area that one is passionate about. Many of the Google products are exciting, but unfortunately I was unable to be passionate about my particular product area. That is not to say that there weren’t any interesting aspects about it, and I do have a lot of respect for the team I worked with. Overall this is less of a problem later, as it is generally encouraged to switch projects every 1-2 years, but this first year makes a big difference, particularly for experienced engineers that have a good understanding of what kind of things they enjoy working on (or perhaps more importantly, don’t enjoy working on) or what kind of environments are a good match. I feel that the hiring process should be improved to better take this into consideration, although this is admittedly a difficult logistical problem at Google’s scale. Another scale-related problem: Due to the sheer size of the code base and the vast number of Google-specific tools and frameworks, it also takes a very long time to learn how to actually become productive at Google, which can be frustrating at times.

But overall, I feel privileged that I had the chance to work at Google. I’m sure they will still be around for a long time, and 20 years from now I will be able to tell my grandchildren “Oh, Google, yes, I worked there once…”. I will certainly miss the Google campus, which had the vibrant feel of a University campus. I will also miss many things about the Google culture, and hopefully be able to take many of these inspirations with me into my future career.

Which brings me to my new job, which I am enormously excited about starting this Monday. I can’t say too much, as the company is just getting founded and still in stealth mode, but I am going to be a co-founder of a brand-new startup in the Social Networking / Mobile space, two areas I am very interested in. I have worked at small startups, but so far I’ve never had the opportunity to come in on the ground floor like this, so this should be a great adventure. My role is going to be that of Director of Engineering, but I expect to be wearing a lot of hats, ranging from architecture and implementation to being involved in the product direction, taking care of hosting and other IT stuff, and ultimately building a great team and helping define the company culture (although we will initially be a small core team). We will be working with some exciting technologies, including Ruby and a sprinkling of Ruby on Rails, which I am strongly looking forward to as well. Besides using a bit of Ruby at my previous job, I have mostly played with Ruby in my spare time, and I am glad about being able to finally use it again at my day job as well (though we will be pragmatic and use whatever tool makes most sense for the job at hand). I think I am officially done with Java at this point (but never say never… I am pretty sure I will at least use it again as a platform at some point in the future).

Well, this blog post turned out a bit longer than expected. But don’t worry, I am sure I will be busy enough at my startup that I won’t have a chance to bug you with any additional long posts for a while. ;)

My new gig

Thursday, April 5th, 2007

I’ve been negligent about updating my blog for the past two months… I’ve also been told that I really need to post an update about my new job, so here you go:

A few weeks ago, I joined Google! Due to the sheer size of the company and the corresponding infrastructure, there’s a huge learning curve, so I can’t post anything specific about my concrete job yet. However, the environment is truly fantastic. Google very much feels like a college campus, and the collective brain power in this place is pretty amazing. But what is even more amazing is the degree to which engineers are empowered at Google, which has a strong bottom-up culture. Not to mention the quality of the many gourmet food cafeterias across the campus (I haven’t even had a chance to try half of them yet…).

I’ve mostly worked at small startups (although some of these ultimately ended up as part of a somewhat larger organization due to acquisitions), so Google is definitely a big change. But this is not your typical rigid and formal large company, and in many (good) aspects it still reminds of a startup. In other ways it almost feels like its own autonomous ecosystem. For example, for whatever question you might have or whatever topic might interest you, there’s bound to be a mailing list with plenty of experts on it. Almost like good old Usenet when it was still working… There are extensive training sessions, self organizing user groups for various topics, etc.

It feels good to be part of a massively successful, impactful company like Google.

Joel Spolsky on Hiring Software Engineers

Thursday, November 16th, 2006

Joel Spolsky recently posted an excellent series of articles about hiring software engineers. I don’t always agree with Joel’s opinions (particularly on topics like Ruby on Rails or agile development), but he definitely has a strong perspective on hiring software engineers.

Click on the headings below to get to the original articles on the Joel on Software website.

Finding Great Developers

Joel convincingly argues that the great developers are never on the market, whereas the bad programmers are always looking for new jobs. So job boards (like Craigslist) and recruiters are some of the least promising methods. He describes great success with internships. As a relatively small company, we have not seriously explored this option ourselves, but Joel makes a compelling case. Another good option is to seek out qualified candidates at the places they hang out, such as conferences or virtual communities.

Sorting Resumes

This is another tricky topic. After reviewing more than a handful of resumes, they all start looking the same (this seems to be especially true for resumes sent in by recruiters, who ensure that no buzzword is left out…). Joel presents some strict but fair criteria for filtering and sorting resumes based on passion, brains, communication skills (and English language skills in particular), “hard-core”-ness, diversity, selectivity, and the candidate’s desire to work for the company (as expressed in a custom cover letter). He concludes that resumes provide a very weak signal for judging candidates, but the criteria described in the article sound like an objective way of filtering and ordering potential candidates.

The Phone Screen

In this article, Joel outlines a good phone screen strategy. We always go through a phone screen before inviting a candidate for an in-person interview, but I will start incorporating some of the ideas from this article to better screen for people who are both smart and passionate and whose communication skills go beyond reciting low level technical details…

The Guerilla Guide to Interviewing

Last not least, we come to the actual in-person interview. Again, Joel presents sound advice for this stage of the hiring process. The main goal is to find people who are smart and get things done, as opposed to people who are smart but don’t get things done (such as the PhDs who prefer to mull over theoretical issues), the people who get things done but are not smart (who more often than not turn out to be a liability), and of course the people who are neither. He also stresses the importance of making a “no hire” decision if there is any doubt whatsoever, as a potentially bad developer is a much bigger liability than potentially losing out on a decent developer. I like to think that we have a high bar ourselves, and while it can sometimes be frustrating to turn down candidate after candidate (although phone screens help to filter out the obvious non-matches), I agree that it does not make sense to compromise on this.

Interestingly, Joel seems to have come around with regards to puzzle questions, even though he used to be famous for only hiring people who were able to figure out a logic puzzle involving pirates and treasure.

Job Update

Sunday, November 7th, 2004

The first two weeks at my new job have passed very quickly. I am still very happy and confident that I have made the right choice. The people are smart and pretty easy to get along with, both on my team and in the rest of the company (at least as far as I can tell so far). I attended the first bi-weekly company meeting on Friday and was reminded of the fact that we are still a small startup, where the CEO updates the company every week or two, the entire company discusses new products, shares other news, etc. It’s been about 5 years since I last worked in a similar environment.

In terms of the actual work, I wasn’t disappointed either. Besides getting up to speed on the existing software, in the last two weeks my work consisted of implementing a few new features, fixing a few bugs, and doing some research on potential technologies and architectures for an upcoming project. This is a nice mix of responsibilities. Of course I spent some time setting up my Linux work environment as well. I have some thoughts on that as well, which I will blog about in a separate post. The collaboration is good, we have had several brainstorming sessions, and engineers are very involved in the actual product design. We have many exciting products in the pipeline, and I am glad that I am in the mobile industry at this point in time. I believe that the killer app for the mobile space has yet to be invented, and it sure would be nice if we could play that role.

I am also positively surprised by how well our development processes appear to work, particularly for a company this young. We have a solid build process with nightly builds, a good deployment process, pretty good unit test coverage, various CVS statistics on the intranet, etc.

For now, I think I’ll shut up about my job and continue to blog about technology and other topics.

First day at new job

Monday, October 25th, 2004

Today was my first day at my new job, and it looks very promising. The company has some great ideas and there are many interesting projects coming up. The environment is refreshingly different from my last two companies, partially due to the entirely different space (mobile entertainment and applications), as well as the fact that I am not working on a shrink-wrap product per-se, but on the server-side infrastructure for mobile applications. This is the first company I have worked at that actually uses Linux workstations for development, which is another nice change. All of my previous companies used Windows workstations, although the resulting software was often deployed on Unix (or compatible with both Windows and Unix in case of the enterprise software companies I have worked at). This is also the closest I have come to Extreme Programming (XP). In fact, they consider themselves to use XP, even though (like many of the companies who I have interviewed with) only use select practices. For example, they don’t use Pair Programming, arguably the most unique but also most controversial of the XP practices. They do however have a highly iterative process, involve the whole team in planning each iteration, define and track features in form of stories, put a lot of emphasis on unit tests (even though they don’t use test-first development), generally try to keep things simple, encourage refactoring and collective code ownership, practice continuous integration, and maintain and check coding standards. For a company that is less than a year old, they are also very well organized. They have a nice Wiki-based intranet with many documents that help new developers get started, each developer maintains a blog, etc. Very nice indeed. :)

Got a new job!

Wednesday, October 20th, 2004

After a good 5 weeks of interviewing, I finally accepted a job offer. Towards the end, there were three jobs I was very interested in, and for some reason all three job offers came in yesterday. It’s funny how these things work out sometimes…

I don’t usually write anything specific about my company on my blog, and I’ll keep it that way for now. I will however say that my new job is at an early phase startup in the mobile entertainment industry. I am extremely excited about this opportunity, as I will be able to help build a business in this growing field pretty much from the ground up. My position is on the server side, where I will be able to leverage my Java and J2EE skills, while at the same time being exposed to this new mobile domain, which is a great combination.

Just wanted to share this little bit of good news. :)

Job Hunt and Fable…

Friday, October 8th, 2004

Please excuse the recent lack of updates on my blog. This has several reasons:

  1. I am currently seeking a new job, which takes a fair amount of time. (On that note, if you know of a challenging opportunity as a Lead Software Engineer or Software Engineering Manager, please leave a comment).

  2. As I mentioned in my previous post, I bought an Xbox… I spent the first few weeks playing with a few mods (upgrading the harddrive, etc.), and have to say that this is a great piece of equipment – certainly for $150. Lately, most of my spare time has been sucked away by Fable. If you like action-oriented RPGs, you’ll love Fable. In addition to the basic elements of this genre, it clearly bears Peter Molyneux’ handwriting, with a highly unique character development and reputation system. It also offers great open-ended gameplay, and you can choose a truly good or evil path, or anything in between.

No more instant messaging?

Monday, June 21st, 2004

My company just instigated a complete ban on instant messaging clients, supposedly for security reasons. While I agree that instant messaging applications may not be the most secure and probably should not be used internally for sensitive information (for which an internal instant messaging deployment of some sort would be preferable), I feel that instant messaging has become such a commodity for personal communications that removing this privilege is a highly significant and intolerable restriction. Ultimately, this can’t be in the company’s interest either, since a couple of unobstrusive instant messages (for example to keep in touch with the spouse) are now replaced by several phone calls with a lot more overhead.

Time to start looking into web based instant messaging applications, such as WebMessenger