Monday, August 18, 2014

Steve Yegge on Google's Engineering Culture

The ever-voluminous Steve Yegge wrote an interesting post back in 2012 about liberal and conservative elements in programming. By "conservative", he means practices that emphasize safety and rigor; "liberal", conversely, emphasize freedom and flexibility. He then used these labels to categorize programming languages, features, development practices, and cultures.

Here's what he had to say about Google's engineering culture:
Google -- Diagnosis: Conservative. They began life as slightly liberal and have grown more conservative ever since. Google was only software-liberal in the very very early days, back when the search engine itself was written in Python. As they grew, they quickly acquired a software conservatism driven entirely by the engineers themselves.  Manifestos were written about the dangers of using multiple languages, and strict style guides were put in place to severely limit "risky" or "hard to read" language features of the few languages they did allow.  ...  In internal surveys, Google engineers commonly cite bureaucracy, churn and complexity as core obstacles to feature advancement and rapid launches.  Google has made serious attempts on several occasions to reduce this bureaucracy, but they always get pushback from -- surprise -- the engineers themselves, who have grown so staunchly conservative that they actively (and even more often, passively) resist the introduction of more flexible stacks and technologies.  ...
Having seen Google from the inside, I can say Steve nailed it. I had expected Google to be sort of an over-grown startup, a really intense place where you had to work extremely hard, but where you had a lot of freedom to do things however you wanted, as long as it worked. What I found was something quite different: a culture that was incredibly strict[1], top-down[2], and bureaucratic[3].

If Steve is right, what I expected to find at Google is actually found at Amazon and Facebook.

[1]: Check out the C++ style guide (click "Toggle all summaries" to see the document in its full form). Then consider that the code review culture routinely enforces all of it. I remember having check-ins rejected for spaces at the ends of lines, for example.

[2]: I still think I should have quit or transferred the day my lead rejected the fifth rewrite of a design document.

[3]: The most prominent manifestation of Google's bureaucratic nature is the "promo packet", an elaborate document used to apply for promotion. It is typically at least a dozen pages long, with a long series of testimonials by the applicant's bosses and peers singing his praises for the promotion committee. It's like going up for tenure or a partnership, but it's done for every step up, not just once in your career.

Thursday, August 14, 2014

The Joy of the Trailing Edge

Today I signed up for Skype. For the first time.

I installed a webcam, downloaded the software, signed up for the service, and it all went without a hitch. No fiddling with drivers, no screwing around with setup files, no searching through FAQs. It all Just Worked.

Plus everyone I might want to talk to is already there. Including mom.

The joy of the trailing edge.

Sunday, August 10, 2014

Simple Fixes for Improved Mobile Web Browsing

I recently started reading Hacker News, and discovered to my frustration that a) the main site is not really useable from a mobile phone and b) they don't have a mobile version. I played around with the HTML, and found that it wouldn't be hard to improve the mobile experience significantly. These tweaks to the HTML make a real difference by letting the content wrap to the screen:
  • Add <meta name="viewport" content="width=device-width, initial-scale=1.0"> to the <head> element.
  • Remove the width="100%" attribute from the table (and maybe the width="85%" from the sub-table, too).
 As it turns out, several of the sites I visit regularly are hard to use on mobile devices:


But every problem is an opportunity, right? It should be possible to create a system that uses various transformations to reformat web pages to make them more useable on mobile browsers. It might boost text sizes, relax table specs, and push sidebars to the end of the page, for example. The result wouldn't match custom designs, of course, but might get the pages from bad to useable, particularly if the user has some input into what transformations are applied.

I wonder what tweaks would help those other sites ...

Building a Compiler, Briefly

During the last meeting of the Toronto Haskell group, we briefly discussed the question of how to build a compiler, and in particular the problem that building a real one is a daunting task.

I've done a bit of digging into various approaches and guides. There are a lot of them, because every respectable CS curriculum needs a compilers course.

The one I find most intriguing is by Niklaus Wirth, the guy behind Pascal and Modula-2. In his "Compiler Construction" PDF, he guides you through building a compiler as a series of exercises in a bit over a hundred pages. Given that other texts run well past 500 pages, a tractable treatment is quite a relief. I get the impression you could work through the guide in 2-3 of weeks full time or perhaps a quarter as a side project.


That said, Wirth does make some simplifications for pedagogical purposes. The source language is Oberon-0, which is a pared-down version of Oberon, so almost but not quite a real language. The target architecture is a simplified RISC instruction set, with an interpreter that fits in a page. You build the compiler from scratch, rather than using tooling like ANTRL, parsec, or LLVM, which you'd presumably leverage in an actual implementation. And the treatment of code optimization is brief. So, choices were definitely made.

But all in all it is possible to make building a simple compiler the work of a couple of weeks rather than a months-long slog.