These days, it’s not hard to find a Silicon Valley startup that claims, not so modestly, that it’s changing the world. And while it’s true that some startups are doing just that, the not-well-kept secret is that most of them aren’t doing anything productive, much less profitable, but still somehow find ways to get funding. But one startup, Github, is unique: not only is it changing the world, but it’s changing the way startups change the world. Github’s about page claims it hosts over two million repositories, which include the likes of the Facebook SDKs, the popular JavaScript framework jQuery, and the open-source release of Doom 3. It was even the primary home to arguably the most important open-source project ever, the Linux kernel, when its usual home was compromised earlier this summer.

And while Github is making a huge difference in how people write, store and track their source code, it’s also starting to affect how people develop software. This is an important distinction, and failing to optimize the processes and philosophies that you and your team take while developing software can lead to productivity losses just as severe as bad developers or bad bugs.

Github’s most notable employee who has talked about their process is Zach Holman, who has written a few blog posts as well as given a talk on the subject. His overarching thesis is that optimizing your development process is much like optimizing a piece of software you write: minimize the your blocks by making them asynchronous. This means:

• no meetings, which require developers to synchronously stop what they’re doing, walk to the conference room, and meet about stuff which may or may not involve them for an indefinite amount of time,
• no deadlines, which sometimes require developers to synchronously stop what they’re doing to work on something more pressing,
• no pings, which distract developers and pull them away from what they’re working on,
• no hours, which require developers to start and stop synchronously, and sometimes starts or stops them at suboptimal times, and
• no managers, who in the best case scenario, try to schedule developers so that they’re working as asynchronously as possible, but in the worst case, simply get in the way.

There’s not a whole lot of “radical” in these ideas, at least not as far as I, a developer, am concerned. I know I work best when I’m uninterrupted and on my own schedule, and am happiest when I feel autonomous, or that I’m not depending on anyone else or waiting on anyone else for me to do my job. But hand this list to most traditional businessmen (or software managers) and they’ll have a different impression.

Why it works for Github

• Github works for themselves. As a developer, it’s pretty rare to work for a company that produces products for end-users, as opposed to a company that produces products for clients. Companies that produce products for clients not only have to do what the clients ask them to do (or risk not getting paid), but clients come from the enterprise, 20th-century world of business, which means spec sheets, pings, hours, meetings and deadlines. On the other hand, companies that produce products for end-users might solicit feedback, and they might even listen to that feedback, but in the end, they’re making product decisions based on their own interests.

  Github is in the unique position of not only producing products for end-users, but they’re producing products for developers. This distinction means the user base is very narrow, meaning that Github can stay focused on providing features for almost all their users at once, rather than features for business users here and home users over here. Additionally, not every feature has to have the smoothest edges right off the bat, so features can be released, tried, tested, and if they don’t work, can be put to bed. And since there’s no direct client relationships, there doesn’t have to be any deadlines except internal ones, and really, that’s just a choice.

• Github is full of really smart people who are all driving towards a similar goal. By creating a product that’s popular and well-liked by developers, Github has their choice of talent to hire. Not only can they find really smart developers, but they can (and do) find developers who have resonant beliefs to the rest of the company. Hiring developers like this means everyone can settle into their role and figure out how they can contribute best on their own, without a manager getting involved. If Github interviews a potential hire who doesn’t want to work really hard, and is only in it for the money, they can pass on him, assured that there are more desirable developers eager to take his place. Not all companies have this flexibility, because not all companies are in the position of having a really cool job to offer.

  And to be clear, that similar goal isn’t “making money” or “building value for an exit”. Github was founded to solve a problem of sharing code between friends, and today, their goal is simply to make developers’ lives easier by removing as many headaches that used to come from version control, issue tracking, and code reviews, as possible. If some employees’ goals were to simply make as much money as possible, then they’d fight with the more idealist employees who are trying to make a better product over what features need prioritized, and when they need them done (for example: a better ad-serving platform instead of fixing bugs with the code review process).

What the rest of us can do

It’s true that we won’t be abolishing software managers any time soon, nor will most of us be able to eradicate deadlines. But that wasn’t Zach’s point in his talks; his point was that Github’s methods are just an aggressive way of tackling the headaches and blocks that developers face every day. Most of us can’t take the same amount of steps that Github has, but there are certainly lessons from Github’s approach that we can apply.

• Software managers’ main goal should be to minimize developer interruptions to maximize their productivity. Joel Spolsky writes that developers should be solely focused on developing as much as possible, because the little interruptions add up and eventually lead to lost productivity, most of which can be avoided.

  Github sees software managers as getting in the way of the developers, but if you have to have them around (and you do, because most software teams require some management in order to get much done), then they should be trying to get themselves in the way of all the interruptions they can. This means intercepting pings which aren’t urgent but will knock the developer out of the zone anyway, making sure that each developer is working on something and isn’t waiting on anyone else, and in the best case, acting as sort of a surrogate developer that can interact with the rest of the company while the developers do their thing on their own time.

• Software development processes should be as simple as possible. Many of the headaches that come with software development are a result of the meta tasks: source control, bug tracking, deploying code, etc. Github’s rule (anything in the master branch is deployable) is simple enough to remember but powerful enough to let developers work on stuff without a fear of breaking anything. Rule #2 in The Joel Test is that developers should be able to make a build in one step, reducing the complexity and chance for human error when deploying code. Github uses their own issue tracking every day, so if something with bug tracking isn’t simple enough, they know about it quickly, and if they need to deploy code, all they need to do is ask their friendly neighborhood Hubot.

  The fact is that software development is not only complex, but it’s done by humans. Errors and mistakes are going to happen. But they should be avoided where they can, and software development processes are often way more complex than they need to be.

• Developers should be encouraged to work on their own stuff on the side. This has done wonders for Google, whose 20% time policy is now legendary for the products it’s incubated in its lifetime. Github’s policy is seemingly even more liberal, encouraging developers to work on whatever they want to work on just about whenever they want to work on it, even if it doesn’t turn into anything. This has led to a culture of automation, autonomy, and fun. Automation makes the software development cycle faster and more foolproof; autonomy and fun make developers happy and easier to retain. Keeping developers on a tight leash and not allowing them to experiment and innovate is a bad idea, and will only lead to turnover. The best solution is to encourage as much experimentation as you can afford.

While Github might still be a little ahead of the times with some of their ideas, the truth is that most of them are just common sense. And although their recipe to success might not work for your company, adopting some of their principles and ideas can only help.

We recently finished up the latest major version of a project at work, a web application that allows our clients to view Facebook Page analytics that we generate and empower them to craft their future social media strategy. The project has seen a couple iterations, but for this one, in an effort to make the whole thing simpler, we reworked most of it from the ground up, including a brand new user interface.

But while CSS is a very powerful tool, this web app was going to require a lot of it, using features from every version of CSS. And while “graceful degradation” was our methodology to some degree, the last version of this product didn’t support any browser except Chrome (because of time constraints) and it was made clear that this time, we would need to support all major browsers. This would mean hundreds of rules, nested rules, exceptions to rules, and fixes for The Browser That Shall Not Be Named.

So in an effort to simplify our CSS develop/test/deploy cycle, we decided to employ LESS, an extended CSS with support for nesting, variables, imports, and expressions.

LESS vs. Sass

I should first mention that we did look at LESS’s main competitor, Sass (sometimes known as SCSS). Sass has many of the same features, like nesting, variables, mix-ins, etc. The main difference between the two is the compiler: Sass’s compiler is a Ruby gem (ew!), and LESS’s compiler is a Node.js package. This might just seem like a personal taste at first, but the fact that LESS’s compiler is Node.js means it’s a version of Javascript, which means it can be run in the browser, which means compilation can happen on the fly, on the client side. This is great for development, although not necessarily a good idea for deployment, but we’ll get into that later.

In the end though, the biggest reason LESS won out for us was that its syntax isn’t a superset of CSS, like Sass. This makes writing LESS feel way more natural, like an improved version of CSS, rather than a whole new language.

Getting started

So what does LESS look like? At its most basic form, it’s just CSS: any valid CSS is also valid LESS.

But this isn’t very interesting, so we’ll improve it to something that makes the switch to LESS a little more worth our while.

Hopefully that code is a lot easier on the eyes. When it’s compiled, it produces the exact same CSS code as above, but rather than having to spell out each level of cascading CSS on each line so it makes sense to browsers, we can nest them in a way which makes sense to developers, with proper scope.

But we can make it even better.

And now you should start to see some of the power behind LESS. By making a border-radius function, we can avoid having to write vendor prefixes more than once. In addition, you’ll notice I wrote the same function twice (overloaded it), so we can choose to call border-radius with one argument if all the radii are the same, or four if they’re different. LESS’s mix-ins do much the same thing: you invoke it in a selector, some LESS takes its place, only mix-ins don’t have arguments.

Another cool thing about LESS is how you can do imports. We used this extensively in our project, by breaking up our style into a bunch of different LESS files and then writing one wrapper file that imported every LESS stylesheet it needed. The main difference here is that in LESS, imports don’t require an additional HTTP request; they’re simply loaded in and compiled (like the way PHP handles includes) and served or output as one big file. This is a nice feature to reduce pageload times, but it comes with a tradeoff, as you don’t necessarily need to load every single style you define for the entire site for every single page. Our technique was to load the styles that were part of the template as one <link>, and the styles that were specific to that page as another. (Potential gotcha: The Browser That Shall Not Be Named’s 4096 selectors “feature”.) Our project, as I look at the code right now, has about twenty LESS files which compile to only six CSS files, so we get the flexibility and organization of working with a lot of files, but the speed of loading a small amount of files.

Developing/testing/deploying

I haven’t even talked about variables, expressions or some of the useful built-in functions, but the official site does a nice job covering those so I won’t. What I’d like to talk about is how we used LESS in our development process and how we deploy it in a fast, low-friction way.

Including a LESS stylesheet in your HTML is pretty simple:

And this is fine for developing and testing. And it’d be fine for deployment, except it’s relying on the client to render the stylesheet correctly, and as we know, relying on users is never a good idea. This method didn’t work at all for some of our LESS sheets in The Browser That Shall Not Be Named, and even if a user is using Chrome, a rogue extension or the user’s disabling of Javascript might prevent this style from rendering. And in the best case, the Javascript renderer is slow because it has to run Javascript and then render the CSS, instead of just loading a static CSS file and rendering that.

So the preferred solution for deployment is compilation to static CSS files, and referencing those from the HTML. LESS has a command-line compiler, which you can install from the Node.js package manager (you can use these commands on a Mac, you’ll need different ones if you’re on Linux, and if you’re on Windows you’ll have to get crazy and use an installer):

And then, to compile a LESS file, you simply run one or both of these commands (shown here for Mac or Linux, but something similar should work on Windows):

The former command produces minified CSS and writes it to a file, while the latter produces inflated CSS.

Speeding up the workflow

So this is good, and it’s relatively simple. Having to install Node.js is sort of a pain, but it’s not that hard and you only need to do it on your development machines. The problem is remembering to do it. The workflow, right now, to push a simple style update, is to edit the LESS file, compile it to the CSS files, add them if necessary, commit, push and deploy; there’s a lot of room for human error.

I wasn’t happy with this, so I set about automating as much of the workflow as I could. I ended up writing a recursive LESS compiler/adder that knew which LESS files needed to be CSS files, and which were just components and so they didn’t need to be compiled separately.

This compiler makes a few assumptions:

1. That you can run PHP from the command line.
2. That you have lessc installed and in your PATH.
3. That your project uses Mercurial (this is fairly easily avoided/changed).
4. That the directory you run the compiler from is in a directory with two child directories, less and css, which are where your LESS files reside and where your CSS files will be compiled to.
5. That you (or the user that’s running the script) have permission to write to css.

It’s not the prettiest thing, and I plan to improve it, but for now, it works. If you review the code you’ll notice that it skips files that start with an _ (underscore), so your convention, if you wish to use this compiler, should be that your output files should not start with an underscore, while your includes or helpers should start with an underscore. It also adds files to your Mercurial repository if needed; if you use Git, you should be able to make the change.

To make sure this runs when it’s supposed to, I set up a pre-commit hook in my Mercurial repository to automatically compile everything:

This is a far-from-perfect solution, as it adds time and sometimes compiles unnecessarily, but it’s sort of tough to determine dependencies, so I figured it was good enough for now.

And finally, I wrote a function that lets you pass in the extension-less style you want to load, and depending on if the site is running in production or development mode, load the minified CSS file via <link> or load the LESS file via <link> as well as less.js.

Conclusions

So the final workflow is pretty simple, for me, the developer: make a change to the LESS stylesheet, commit, push, deploy. All of the stuff in the middle is automatic, and until browsers start supporting some form of extended CSS natively (there’s talk of this happening), it’s about as good as it gets.

As a hobby project, I’ve started thinking about developing a LESS compiler in C or C++ which doesn’t depend on Node.js, because a) dependencies are a buzzkill, and b) writing compilers is fun. With a working, fast, non-dependent compiler, you can move the compilation from a commit on the developer’s machine (what we’re at now) to the server and do a just-in-time compilation, with caching, sort of like how minify works now.

Hopefully this has helped a) convince you to check out LESS (or Sass, if you’re into that sort of thing), b) given you an idea of the problems and hurdles you might face, and c) given you an idea on how to overcome them. I know I don’t do many technical blog posts, but I’d like to start doing more of them and I’d like your feedback on what I could do better. Just leave me a comment, send me a tweet, or drop me a line. Thanks for reading, and happy Thanksgiving!

New look, same brilliant writing! ... Oh, don't make that face. It's not like you were paying for it.

Welcome to the new Cleveland, Curveballs and Common Sense, codenamed “The Experiment”! Go ahead and take a look around, then come on back and I’ll show you around.

Last year, around this time, I started thinking about redesigning my blog. I was working on implementing a WordPress theme from scratch at work; with Stephen Stanton (and his boss Josh Laney) providing the graphics and creative vision, all I had to do was write the code that powered a new WordPress site for our Chasing Trophy Whitetails brand. On my end, there were some neat technical things with the theme like an HTML5 image gallery and automatic generation of OpenGraph tags. It seemed pretty fun and pretty easy at the time, and so I quickly became eager to write a theme for my own blog and transfer some of that new knowledge over.

But it’s not even close to that easy: it takes skill and talent to create and execute a WordPress theme design, and so I flustered for almost a year, coming up with various ideas but nothing good enough to make me want to switch.

The change came with Grantland, a Bill Simmons-led sports site that launched in July. My first impressions of the site were incredibly positive, and as I thought about it, I realized that the reason I liked the site so much is that the content was very much the star. Article pages are simple and clean, and they make articles easy to read on every device I want: my iPad, my iPod, and my computers. Even the footnotes (which, in Bill Simmons’ fashion of writing, are must-reads and really add a lot to the article) are reformatted appropriately depending on your device and its orientation. So I started thinking: could I come up with a design that maybe isn’t as flashy as some others out there, but would perhaps make articles I write more attractive to look at and easier to read?

So the experiment here was to determine if I could visualize, design, implement and deploy an attractive, if simple, theme without any creative help whatsoever. Over the last couple weekends I’ve spent a couple sleepless nights coming up with a new theme, and to be honest, I’m really pretty happy with what I came up with.

All of the design (except the typography) was done by yours truly, with some structural inspiration from Lightword, the theme that graced this site for the last two years. I chose the typography based on what was easy to read and free, and so the two fonts I chose are available in the Google Font API.

I wrote a couple custom widgets: On BitBucket and Ballpark Resumé. Ballpark Resumé is pretty basic right now, but I hope to have time to make it better at some point, and maybe add graphics of some sort to liven up the list a bit. For right now, it’s just a better formatted link list with rankings. The On BitBucket widget I’m a bit more proud of, as it queries the BitBucket API for the user’s (my) activity on the site, and then my code formats the feed into a prettier list (with similar appearance to the Twitter widget right above it – I use the TimeAgo jQuery plugin to generate the relative timestamps). I hope to leverage the BitBucket API further when I get around to rewriting the projects page, which I didn’t get to this time.

Here are a couple other highlights:

• Search. The search field starts as dark gray, brightens up when you hover over it, and gets bigger and brightens up more when you focus.
• About Me. I did get around to reformatting this page, and I’m pretty happy with the way it came out. (I knew I bought that widescreen camera for a reason.)
• The social widgets. One of the goals with my redesign was to make the site more OpenGraph friendly, so now each post gets the right tags automatically instead of Facebook having to guess at them. The social widgets that now appear on the left hand side of the post move with you as you scroll, if you’re on a single post (the movement is a little glitchy right now, I’m working on it).
• Comments. It’s not that I was too lazy to write a comments form and skin, it’s that I was… well, okay, I was too lazy. But the fb:comments social plugin has been implemented by some major sites, including TechCrunch, and I’ll be darned if I’m not a follower. So I use Facebook for comments, although I believe you can comment through other channels if you want (and I think there’s a way to turn on anonymous commenting, I’ll look into that).

I have a couple other things I’d like to work on, including a new projects page, optimizing the JavaScript and CSS and better support for all the non-Chrome browsers. But I thought I’d rather release this now, 98% complete, rather than waiting six months when I finally get around to these issues.

As with most other things I’m working on on my own right now, I’ve open-sourced my theme on BitBucket. The code’s not in great, reusable condition right now but I do hope to improve it over time.

As I said, I’m pretty happy with what I came up with, but I’m always eager to hear feedback, good or bad. So leave a comment, tweet me or send me an e-mail with your feedback. Thanks, as always, for reading! I’ll get back to your regularly scheduled content in the next post.

If you look on my company’s team page, you’ll find my picture captioned “Overrater”. I take this caption somewhat in stride, because being involved in developing many of the analytic algorithms at our office means that I’m spending a lot of my days “rating” client’s Facebook Pages and presences. The reason the caption is there though, is that I have a strong tendency to not be impressed with things most people seem to like (“Shark Week”, “Avatar”, “Top Gun”, college football, to name a few) and call them overrated.

Which brings me to Google’s new, much touted social network called, simply: Google Plus. Google+ isn’t Google’s first entry into the social arena, but it’s their newest and inarguably their strongest. And while Google enjoyed excellent early reviews as well as an early influx of 10 million enthusiastic users, my impressions of Google+ are much less enthusiastic. My initial impressions of what’s wrong with Google+, after the break.

New interface, same network

One thing that Google+ certainly got right was its interface, which is, in a word, slick. The News Feed page is well laid out, the Circles page uses some HTML5 magic to enable drag-and-drop circle management, the Profile page is attractive and informative, and Hangouts and group video chatting are well put-together and unique.

But it’s not original. And this is what Google needs to be concerned about: there isn’t anything Facebook couldn’t replicate, if they wanted to, within a month. And until Google+ has more of your friends than Facebook, which is no modest feat, most users are willing to put up with some feature differences and deficiencies in order to reach more of their friends. The same theory applies to Android vs. iPhone, at least early on: most early adopters picked iPhone because, despite the fact that it was on AT&T, there were more apps and the platform was more mature.

In order to prove this fact, I set out to replicate Google+’s Circles interface using the Facebook friend lists API. I was able to do this pretty easily, and most of my development time was eaten up in a) synchronizing Javascript Facebook API calls properly, and b) revamping the user interface after deciding that a straight rip of Google’s Circles interface would choke under a large amount of friends. All told, I’ve probably sank about 8-10 hours of work into my copy, and I’ve deployed it here and open-sourced it here (update: this link is now fixed). The entire app is HTML, CSS and JavaScript, so feel free to grab a copy, install it on a server somewhere, and try it out for yourself. As I noted in the disclaimer, I only really tested the app on Chrome, but it should work in Firefox, Safari, etc., with IE being a bit of a long shot.

In the end, I feel like I came up with a pretty good lists manager, which shows that if someone at Facebook feels like it, they could make a much better lists manager than they have right now, in a short amount of time (and friend lists on Facebook, are, more or less, Circles on Google+). The same goes for every Google+ feature; no Google+ feature is paradigm-altering, it’s just a fresh take on an old idea.

No brand love

Make no mistake, part of the reason Facebook’s growth really exploded in 2009 was the introduction of Pages. For the first time, brands could have a legitimate presence on Facebook, and could graduate from the role of black sheep in the advertising blocks. As brands rushed to make their presence known in this new channel, they were quick to pollenate their page with fans of their traditional media advertisements, by including lines such as “Find us on Facebook” on a TV ad or the Facebook URL on a print ad. As those advertising pushes got more incentivized, non-Facebook users were convinced to join Facebook by the promise of free stuff, like sweepstakes entries, free coupons, etc.

This is an underrated factor in Facebook’s growth, but shouldn’t be forgotten. And the fact that Google+ failed to launch with not only a robust solution for brands, but that they launched with a controversial restriction against everyone except genuine, single users is a huge barrier to adoption.

Limited platform

The biggest reason Facebook’s growth exploded is that in 2007, Facebook launched a platform which enabled developers to develop applications for Facebook. Google+’s initial platform, while existent, certainly isn’t as substantial as Facebook’s and doesn’t allow the embedding of apps within the canvas like Facebook does – it simply integrates sharing links with your website, like Facebook’s social plugins. This is fine for now, but it’s not going to help Google grow the service as much as it’d like. In the future, Google has announced plans to keep games separate from the rest of Google+. But there’s a miscalculation here: Google+ users aren’t typically interested in games, at least not ones on their social network. So really, it remains to be seen how much even a platform will help growth.

Tumbleweeds

But perhaps the biggest problem with Google+ is that while a lot of people have accounts, but after the initial excitement, there’s really just not a whole lot of activity. Thus, users aren’t logging in every day, and the service becomes forgotten. One of the main reasons Facebook has succeeded the way it has is that, even early on, it has had exceptional retention. The lack of that retention is what’s hurting Google+ now.

There are a couple ways this can be addressed. First, figure out a fix for the people with multiple Google accounts (Google Apps for your Domain users) so they don’t see this screen:

Second, integrate Google+ with what is probably Google’s second-most precious asset right now: Google Chrome. To me, this is something that should have been done from the start, as it would have been a more compelling product and one that Facebook couldn’t have replicated directly, at least not using Google Chrome (it wouldn’t surprise me if Facebook was building a browser of their own based on Chromium, Google Chrome’s open source brother). As a Chrome user, it’d also keep Google+ in my face all day, almost forcing more activity and more awareness.

I’ve heard the argument that “Google+ isn’t competing with Facebook; they’re two separate products.” The problem is: the general public won’t see it that way. Most people don’t have two social network accounts, and even less have three. With Facebook, Twitter, and now Google+, the social networking field is getting crowded. Google getting 10 million users doesn’t impress me anymore; they’ve done that in the past with Wave and Buzz. Google’s big problem is that it doesn’t just need 10 million users; it just needs what Facebook has: 130 of your closest friends.

Just another day at the office.

When I was born, my Uncle Jim (who has since passed away), who was a newspaper columnist, wrote me a letter welcoming me to the world and introducing me to my family. It was a neat idea (and a tradition I plan to continue), and in the letter, he predicted that because of my genetic makeup, I’d be an All-American, All-Academic starting linebacker for the Ohio State Buckeyes.

My parents, who probably read the letter the night it was written as opposed to discovering it buried in family photos years later, probably read the letter and chuckled. Given the fact that my parents are both computer programmers, I can imagine one of them saying, “there’s no way that kid’s not a programmer.” (I’m not sure what this says about my sister, who will probably cure cancer one day but can’t defragment a hard drive to save her life.)

And if one of them said that, they were right. I’ve been fascinated with computers since I was in elementary school, launched my first website back when Albert Belle was slugging home runs for the Indians, started writing programs in middle school, wrote a full web app in high school, and never looked back.

Well, kind of. Because there was definitely a time over a period of the last few months and years where my computer science knowledge stagnated, where my interest in the field was at a low point, and where I just felt burnt out. But lately I’ve felt that drive again, that addiction to building awesome things that only software engineering can deliver.

The biggest thing I did is that I started learning again. One of the hazards of being in computer science is that since the field is advancing so quickly, you have to work your tail off to keep up-to-date. And sometimes, it’s nearly impossible, and that makes it discouraging. But you have to learn to live with the fact that you’ll never know everything, and the best thing you can do is always be learning. There’s a lot of ways to go about this, but here’s what I did:

• Reading. I’ve started to make more of an effort to read technical blogs, blogs from my favorite open-source projects, etc. Blogs like Joel on Software and Coding Horror are cool too, because they make programming seem a lot more glamorous and impressive than it actually is. Even non-technical writing, like books on business or books about your favorite Jeopardy-playing computer count. Heck, I was even inspired by watching The Social Network.
• Personal projects. I had some brainstorms for web apps, saw some neat things with new APIs online, and simply sat down and started working on them. There’s no better way to learn than by doing, and by the end of it (hopefully) you have something neat to show off to friends.
• Stack Overflow. This is a relatively new thing for me, but I realized that sometimes, while I don’t have the time or energy to dive neck deep into a bunch of coding, answering questions on Stack Overflow makes you feel good for helping someone out, challenges you for a few minutes while you think through a solution, and maybe makes you rethink why a certain feature works the way it does. There are a lot of questions that are really easy to answer, but there are even more “advanced” questions. And while you might not know the answer, chances are, it will get answered at some point by someone who does.

Everyone learns differently, but I think I can speak for all computer scientists when I say learning new stuff is fun and empowering, and a vital part of keeping your job interesting.

I also started, for lack of a better phrase, developing socially. Since early 2008 I’ve kept all of my work (homework, fun projects, whatever) in private Subversion repositories on my server. Since I was often the only one developing in those repositories, I didn’t really need the merging, branching or other features that advanced version control provides, just updates and commits. When I started at LoudDoor, we used Subversion too.

But earlier this year, we switched to Kiln, a hosted version control system based on Mercurial by Fog Creek Software. Mercurial makes stuff like branching and merging easy and cheap, and commits no longer had to be written to the central repository each time you committed, but instead were written to your own personal repository and pushed up at your leisure.

A DAG of the project our team is working on

For my personal projects, I switched to BitBucket, which is a Mercurial version of GitHub, which made the phrase “social coding” famous. And the same effect occurred: I was enjoying working on stuff again. And more than that, I now have a little portfolio of personal projects that I can be proud of. I had a code site before, but it wasn’t very pretty so I didn’t really promote it; it was more there for my own use if I needed access to code snippets for whatever reason. But the one on Bitbucket looks nice, encourages contribution, and is much more engaging.

But let’s be honest: most of your development work comes at the office. And a big part of the reason for my rut was that I was doing the same types of projects, often juggling two or three in a day, that really weren’t much different from one another and yet were different enough that I couldn’t automate the whole process. This kind of work would just beat me down over the course of a week so that by the time the weekend rolled around, I was so sick of programming I didn’t want to be near a computer. I think my immediate boss (our CTO) knew this, but I brought it up to his boss, and once we hired another developer, I was able to move on to longer-term, more fulfilling projects. Sometimes problems are solved that easily; other times, if it doesn’t look like things are changing the way you want them to, it might be time for a change. (And I get the feeling that the new developer, or “Binary Star“, will eventually feel the same way I do and will want to move up; good developers like being challenged.)

And finally, I got away from the computer and out of the office and house. It may seem counter-intuitive that the way you get back into programming is by getting away from the computer every once in a while, but getting out of the house, getting some exercise, and doing things that aren’t computer programming help you approach programming with fresh eyes when you come back.

If you’re a burned-out programmer and you’re reading this, hopefully some of these options will help. And if not, one of two things are true: either you’ll come out of it in time, or you’re not in the right profession. I hope it’s not the latter, because as I’ve recently rediscovered, this profession is pretty awesome.

The article kind of justifies this bug. After all, it states, it doesn’t affect you if you’re on an unlimited plan (because hey, if you have all that extra bandwidth, why not waste it?) and it only seems to occur if you’re viewing a motion-JPEG (which isn’t the most common file format, but it’s not unused either). So, fine. It’s a bug, it doesn’t really affect a ton of people that greatly, oh well, right?

Wrong.

The first comment on the article:

How is this a bug?

The website refreshes…it’s not apples fault the person would have a crazy bill, it’s the user for not closing out the page.

And here’s the real beauty of making an Apple product. No matter how bad it sucks, no matter what kind of problems it has, Apple users defend Apple products like they’re defending their children. This attitude either stems from or causes Apple’s ridiculous arrogance about its own products. Case in point, here’s one of the latest Apple commercials:

I’ll address the commercial first. Here’s the thing. Apple’s made a good operating system. It didn’t happen overnight. If you think this operating system has been rock solid from day one, look again. If you remember, OS X only really started even getting stable at around 10.3, and it got good at around 10.4. The OS has been really a work in progress since 2001, and it’s had its share of problems. That’s not to mention Mac OS 9 and below, whose codebase was, for all intensive purposes, abandoned when the company was on the brink of bankruptcy in the late nineties. But that’s an argument for another day.

Let’s get one thing straight: when you close a program, it should close completely or give you some indication that it’s still open: in OS X, an open program is a shiny light under the icon in your Dock, in Windows it appears in your taskbar or system tray, etc.  Not only does Safari not give you any feedback that it’s remaining open, it’s the only application on the iPhone to do so. It’s far from expected behavior, and when using an electronic device, users prefer devices that they can guess what’s going to happen based on their actions.

If any users get a bill in the triple digits (in some cases, as noted in the article, over $3000 for an hour of unknown downloading), Apple should pay it themselves. This isn’t user error. It’s either by design (for whatever reason), or it’s a bug. Apple should fix it.

• You may have noticed that blog.jimmysawczuk.com now redirects you here, to www.jimmysawczuk.com. I did this to create a more unified feel for my web presence, hopefully it’s more helpful for what you’re looking for. I’m still working on it, so let me know if you have suggestions or concerns.
• Because I moved some files around I needed to rebuild certain projects so that they could be downloaded from the server off the installer, so I rebuilt Invaders and George In Space!. If you haven’t checked them out yet, you should – they’re probably the two most useful programs I’ve ever made.
  

  Invaders

As always, thanks for your feedback, and above all, thanks for reading!

We ran into a problem at work last week that was, at the same time, a nightmare and exactly the kind of problem you want to have.

The culprit was our latest Big Prize Giveaways promotion, and the problem was that our app had metaphorically gone from 0-60 in about two seconds, and it experienced the same thing your neck feels when it accelerates that fast: whiplash.

This was my first experience with an app that was this big; even in my McJournal days, I rarely averaged more than 60,000 (well, take that number and divide by 10,000 and you have the real number) hits per day. So in the last week, I’ve learned a ton during our march to a million fans that I think can be useful to everyone, no matter how close your app is to that kind of scale.

• This is the first rule in Hitchhiker’s Guide to the Galaxy, so it’s the first rule here: don’t panic. My first (extremely narcissistic) thought was “what? Something broke? Our server sucks!”, and my second (seriously overdramatic) thought was “I tried my best when I was writing it, how am I supposed to improve it now?” Most scaling problems are definitely manageable, and even though (for me) they’re not much fun and can be stressful, there are worse problems to have.
• Have a plan. These types of problems aren’t quick fixes, you’ll need to know what you want to do, how you intend to do it, and when. Keep in mind that unless you shut down your app completely, the slowdowns will continue to affect you as you work through the problem, so having a plan is crucial so you avoid wasting time thrashing.
• Use EXPLAIN liberally. You should do this to every query you run and make sure nothing jumps out at you. Many of my queries were non-indexed, meaning that while the query would be quick to run with only 50,000 contest entries, as the entries piled up and became more frequent and less distinct, even fast queries slowed down. And when your app is doing 50 queries per second, an increase of even 10 ms to a query will start to snowball and drag your app to a crawl. Point is, you should run EXPLAIN on your queries to ensure they’re doing what you expect them to.
• Index intelligently. Our CTO, Jim Rubenstein (who was the one teaching me a lot of this stuff as we worked through these issues) mentioned that for each SELECT query you run, you should have an index defined. This is particularly true on high volume SELECT queries. Indexing costs a little when you insert and costs some extra hard drive space, but in a day and age with multi-terabyte sized hard drives, some extra INSERT work is easy to work around.
• Better than even EXPLAINing and indexing, you should write your app so it uses the fewest database queries possible. This doesn’t just mean reducing database queries per page load (although that’s important too), it means using tools like memcached whenever possible to reduce the number of unnecessary or redundant queries to the database. memcached simply stores stuff in RAM as needed, and while the concept is simple, intelligently caching your data greatly reduces the number of database queries you have to make. Many of our sites at work use memcached, and we are looking into using a tool developed by Facebook called Scribe to do the same thing with INSERTing data that memcached does with SELECTs. When I first started work a few months ago, I had never used any real caching algorithms or practices in any of my projects, but now it’s one of my favorite problems to solve and one of the most fascinating.
• Learn about configuring your web server to handle more traffic. Most web servers (including Apache) are configured by default to be able to run on a server that divides its resources among other software, like a database. If you have the flexibility to allow your server more space in RAM, more CPU cycles and more hard drive space, open ‘er up and let your server work harder. To do this in Apache, we had to alter the ServerLimit and MaxClients Apache directives, although it may vary for you depending on what version of Apache you have. Do some research on the web to find the ideal settings and set them appropriately.
• When all else fails, throw hardware at the problem. Without going into the details of our configuration, we scaled our webserver (which is a beast of a server, by the way) to four webservers that are load-balanced. Since implementing this scheme, along with the earlier fixes, we have had few problems. Let me say though, that unless your app or site is huge, there’s probably more optimizations to be done before this option.

I think the most important piece of advice I can give you is to not panic. As Jim and I worked through this last week he noted that it’s a good problem to have, and that’s true. After all, if you’re getting slammed, it means people are finding compelling reasons to use your app, correct? Our president (who’s had a lot more experience than us) said also that with these kind of problems, you face growing pains but you fix them on the fly and you learn. I think it’s also true that until your app is on the web, there’s no telling how it’ll perform, and no matter how much you test, no matter how much you benchmark, stuff is bound to go wrong – it’s just a matter of coming back and making it better.

UPDATE: Code and slides after the jump.

Code

Here’s the code: refreshcolumbia-demo. I commented it reasonably well, but if you have questions feel free to tweet, e-mail or leave a comment on this blog. Use it however you want, I’m not liable, yada-yada-yada.

Slides

Here they are, in PDF format: Developing Socially.

Hope everyone who was there enjoyed the talk, I enjoyed giving it. Please give me any feedback you have, I think it’d be kind of cool to improve it and give it again at another venue. Thanks again!

The second reason I don’t normally write about software design is that since most of my projects are small (projects at work are either designed in collaboration or already designed), I don’t waste much time on design. Today I modified a GreaseMonkey script Mike wrote to remove ads from GrabUp posts; he wrote it because he was sick of looking at ads, I modified it because I was tired of the refresh caused by redirecting to the direct image. I didn’t write out a vision and scope document, I didn’t create a design document, I didn’t diagram it – I just wrote it. Another example is my recent weekend project TooLongForTwitter.com. It’s a little larger in scope, but rather than figuring out how everything was going to work beforehand by diagramming it out, designing a database, etc., I just started writing it and it all just kind of came together. Even back when I was writing McJournal, I had an idea in my head of how the final product would look but I never wrote it down anywhere, I just started writing.

Point is, it’s pretty easy to skip that design process which can greatly influence the success of your product. As I thought about it this evening, I realized that all software products fall into two categories.

The first category are the applications that are designed not to suck. We all use software for many different purposes, but a lot of times, we’re using it for work or productivity. Hence, products like Microsoft Office, Quicken, GMail, TextMate, etc. are designed as software that stays out of your way. Either it lets you perform tasks the way you want, or it gently nudges you once and then leaves you alone. Nothing is more annoying in this case than the application that’s trying to do too much (Clippy: “It looks like you are writing a letter…” anyone?). Applications that are designed for productivity usually fall into this category, because normally you want to get your work done, then get off the computer and head out to the golf course. The key word with these types of applications is intuition: it should be intuitive for the user to use.

The other category is the applications that are designed to rock. As you might imagine, these are normally entertainment applications like video games or multimedia applications. These are applications that the user wants to use, applications that the user wants to learn, and applications where the user may want helpful tips. For example, take Halo 3. The game would have been a bestseller without adding a bunch of new weapons, a bunch of new gadgets and a bunch of new customization options in multiplayer mode, but because the game added those little features, it was smash hit and is still played today. Entertainment applications can’t be simply functional to be successful; they’ve got to be immersive.

Ever wonder why Twitter is emerging as a more popular social networking tool for professionals and celebrities compared to Facebook? It’s simple. Using it is as simple as sending an SMS message from your phone or typing 140 characters in one form field on the web. Want to share a link? No problem! Just copy and paste it in there and done. No captchas, no conversion to “shared items” like Facebook likes to do, just shows the URL and makes it a link.

On the other hand, Facebook is complex enough already, and it’s gotten more confusing for the average user over the years. Over the last couple of months I’ve had the pleasure of introducing my dad and my aunt to Facebook (seriously, Mark, I’m fighting for you here, how about throwing some of that money my way?) and I’ve seen the site through new eyes: even with the wizards, hints, etc., a cautious user may feel overwhelmed when visiting the site for the first time. Facebook realizes this, that’s why they’re rushing out Facebook Lite to their 250 million users. Interacting with friends, profiles, streams and comments is hard enough; adding Pages and Ads to the equation makes it even more confusing. Thus, professional users or less computer-savvy users are using Twitter for their business communication.

Another example is in web browsers. As many of you may know, Internet Explorer 6 is still alive and kicking on the web. As someone who has faced a ton of IE 6 errors and quirks, I am definitely in favor of getting this browser out of circulation. But generally, people are using IE 6 for one of two reasons: a) it’s an office requirement, or b) it works for checking e-mail, news, etc. and that’s all it’s needed for. For these users, a browser is a productivity application, not an entertainment application, and IE 6 (unbelievably) “doesn’t suck” too much for them and it requires zero installing, configuring or tweaking to get up and running.

On the other side of the spectrum, Firefox is more of an entertainment browser. Clearly, users use it for productive purposes too, but it’s clear that Firefox is used as an application that rocks rather than an application that doesn’t suck: tabbed browsing, add-ons, and a prettier interface are just a few of the reasons younger users tend to use Firefox.

I guess the point of all this is, next time you’re writing an application, no matter how big or small, ask yourself the following question: do I want my application to rock or not suck, or better yet, do my users want my application to rock or not suck? Hopefully it helps you iron out your feature list and make it one that your users will expect.