Documentation and tutorials are often difficult to navigate. Products built with Python don’t put any thought into design. Blogging software written in Python helps create more ugly blogs about Python. Pythonistas just don’t care about presentation.

Let’s compare the usability and design of some different Python and Ruby sites. Ruby is a good reference point since it occupies a similar niche in the programming language ecosystem and is roughly the same age.

Above are online interactive tutorials for learning Python vs. Ruby. Learnpython.org isn’t ugly exactly, it’s just that Try Ruby is so much more polished. It’s obvious that a professional designer had a hand in Try Ruby, whereas the design of learnpython.org was thrown together by a programmer who later slapped a few ads on it and called it done. Which tutorial would you rather use?

Here are the homepages for Django and Ruby on Rails, popular web frameworks. Django’s homepage is poorly organized. The entire page is just a mess of links with no clear emphasis on anything. In contrast, the Ruby on Rails homepage does a good job of introducing people to Rails and pointing them to different areas of the site.

Homepage of Django co-creator Adrian Holovaty vs. Ruby on Rails creator David Heinemeier Hansson. Both are well organized, but it is obvious at a glance who places importance on professional design and who doesn’t.

Cloud hosting: Google App Engine vs. Heroku. Once again the Ruby side is sexier.

Python blogging software vs Ruby blogging software. The Python blog designs are uninspiring and unpolished, while the Ruby designs are striking. And who doesn’t love octopodes?

Some top Google search results for “python consulting” vs. “ruby consulting”. The Python results look painfully outdated.

Maybe Ruby has an advantage because it is more tightly focused on web programming? It seems likely that consultants for web apps would have nicer web pages than consultants working on, say, scientific problems. To eliminate any unfair advantage, below are some top Google search results for “django consulting” vs. “ruby on rails consulting”.

It doesn’t matter. Python is still the ugly duckling.

This wasn’t a scientific comparison – somebody could try show the opposite conclusion by cherry-picking a different set of sites – but I think the screenshots I used are pretty representative. I also think that most people who have spent a little bit of time in both communities will agree that Python sites are ugly compared to Ruby sites.

Why does this happen?

Either Pythonistas aren’t pairing with designers as often as Rubyists, Pythonistas have less design talent, or Pythonistas simply don’t care enough about design to spend the time to do it right. I’m not really sure which is the case.

Does it matter?

Yes! This stuff matters.

It’s not just that Python sites are ugly (even though they are). It’s that the uglyness makes sites hard to navigate and hard to use. It’s that nobody is inspired by uglyness and nobody wants to use ugly products when there are better options. Nobody wants to hire someone who builds ugly web apps. It is unprofessional and sloppy to be so ugly.

This damages the Python community.

How can we fix it?

If you are a Python coder (or any type of coder who doesn’t fully grok design), spend some time learning basic design principles. Try Design for Hackers, Bootstrapping Design, or Step by Step UI Design. [Edit: Also check out this lightening talk on attracting designers to your project.] Then make friends with designers and know when to call them.

So, there are natural born programmers. And there are natural born non-programmers.

Most natural born programmers notice this at some point (consciously or not), but often the conclusion they draw from it is overly general. Coders who can code may naively expect to found startups that, ermm, start. Or they may expect to be naturally good at other things that are only tangentially related to coding.

Lets take the example of a founder working on a software startup. Our founder is a programmer, at the top end of the programming bell curve. He is a really smart guy, he has done some reading on startups, but he hasn’t launched anything before, and he is entirely unaware that he has developed a severe case of shit’s easy syndrome regarding the non-programming tasks that need to get done before launch.

As programmers, we learn to be obsesively paranoid with our requirements analysis, timelines, and code otherwise the project will run off the rails. But we don’t apply that same rigor for business tasks, because well, that shit’s easy, right?

Turning a project into a product – that shit’s not easy

Packaging a programming project into a product that can be sold is a complex process. Assuming that the programming side is a beautiful finely-tuned instrument ticking along perfectly, there are still a behemothic number of things that need to be done to get it into the hands of paying customers, and each decision that needs to be made opens up into a fractally expanding rabbit hole leading to an infinite number of other decisions.

It starts off innocently enough: OK I need a website to sell this thing. How about a site with a free theme plus some marketing copy explaining the product tied into a simple shopping cart so customers can buy the product.

Which quickly turns into: How about a site with a free theme (which themes are optimized for SEO, which are optimized for conversions, how about some A/B testing, hey why is my site full of spam^[1] …) plus some marketing copy explaining the product (what kind of copy sells, OK “benefits” are better than “features”, but now what are the product’s benefits…) tied into a simple shopping cart (secure digital delivery, payment processing, cart software, should I write some of this myself, will this stack work with an affiliate program…) so customers (who exactly are my customers, what “tribe” are they in, how do I find them, should I try advertising, where…) can buy the product. And spirals out of control from there.

It’s becoming obvious how “hello world hooked up to a random number generator” requires a super-smart, full-time guy doing the business tasks.^[2]

Meanwhile, all of the startup guru expert guys are in my head screaming, “JUST LAUNCH! Iterate later,” but at this point I have lost all sense of what is absolutely necessary to prevent everything from blowing up in my face, what will just make me look stupid if it breaks, and what I can launch without and add later.

This launch paralysis is a problem for startups on down to micro-startups and coders that are just trying to make a bit of side money off of a weekend project. Programmers are probably more susceptible to launch paralysis because we are used to just naturally ‘getting it’ (remember, we have our own bell curve), and when confronted with mushy tasks like research or copywriting that don’t require the rigor of programming, we tend to fall into the shit’s easy trap.

A Tiny Example

My idea was to launch a weekend project, and use the experience to identify problems and iron out glitches in my workflow before tackling something bigger. I uncovered more than just glitches. Everything took drastically longer than expected, and some things I didn’t plan for at all.

The graph above is data from a tiny project that makes some head-smackingly simple changes to Amazon links so that WordPress blogs earn worldwide commissions instead of just US commissions. I assumed it would be easy to sell since the purchase is so easy to justify – once a blog has a certain threshold of earnings from amazon.com, the plugin is pretty much guaranteed to pay for itself. If you are interested, click here to see how the plugin increases earnings.

This wasn’t a startup. Calling it a micro-startup would be generous. It’s a WordPress plugin. We’re talking 700 lines of code, tops. But it still took 5 months to launch it. I was only working on it part time, but still, the number of hours spent getting ready to launch such a simple project is staggering.

Much of that time was spent researching different tools, not actually integrating them. Luckily, most of that knowledge will transfer to future projects. Now I have a standard toolchain that handles design, digital delivery, payment processing, A/B testing, etc. I will be able to put this type of site together much faster in the future.

So, it finally launched. Sheep or goat?

Sales so far have been lower than expected, and certainly less than spectacular. At times it feels a lot like a big goat failure. But there are still some sheep to be found. After stepping back for a bit of perspective, I remember that this little failure created some big wins. First, all of that research gave me a standard toolchain for launching mini software startups (see my toolchain here). Next time things will move much faster. Second, even though the plugin hasn’t earned much through sales, having it installed on my own sites has given a nice bump to passive income.

The launch isn’t really the end of the story. After launch comes a whole new rabbit hole of customer acquisition and iterating the product. It’s a bit too early to make a success or failure call. Everyone says that an overnight success takes years.

1. Why you should never search for free WordPress themes
2. This is in reference to Patrick McKenzie‘s Bingo Card Creator software, which is technically pretty unsophisticated itself, but is supported by complex mechanisms for A/B testing, scalable content generation, conversion tracking, and various other types of optimization.

Assuming you already have a working side project or product (no small feat in itself, but not difficult for a coder to put together), the biggest missing piece is a website for getting that project into the hands of customers. It’s easy to underestimate how much work it takes to do this part well if you have never done it before – design, conversion optimization, payment processing, secure digital product delivery, analytics, affiliate programs…

Researching this stuff is a huge time suck. Here are the tools I recommend for getting a professional site done quickly. This setup has no monthly fees and low per transaction fees, but does require some glue code to get working.

ThemeForest is an online marketplace for site templates and themes.

Even if you plan on moving to a custom design later, using a pre-built theme at first will save time and let you launch sooner. Plus the initial feedback from customers who bought the product on the themed site will help to guide the custom design.

I prefer ThemeForest because all themes are manually reviewed by the ThemeForest staff before being added to the store – this means no secret spam links or malicious code embedded in your themes. (This is a huge problem with free themes.)

Professional looking themes typically sell for between $8 and $15. Browse themes here.

A stock theme will still need some customization. For custom graphics, try Fivvr.

I add a few extra pages to the theme to handle checkout: a payment page, a verify purchase page, and a thank-you or payment received page. These pages contain a bit of custom glue code to use my preferred payment processor, digital delivery method, and affiliate program tracker. The other benefit of handling these pages myself, instead of passing control off to an external cart or payment processor, is that it allows more control over the checkout process. This is valuable for gathering data about cart abandonment rates, providing opportunities for upselling, and optimizing these pages for conversion.

Previously, writing or hosting those pages yourself would be a huge security risk and a PCI compliance nightmare, but with Stripe to do the heavy lifting it’s a secure option.

Stripe makes it easy to accept credit cards on the web.

Payments take place through stripe.js, so your customers never leave your site during the checkout process, and you skip most PCI requirements since the transaction itself happens on Stripe’s servers, not yours.

The API is a joy to work with, and there are Stripe employees hanging out in the Campfire room at all hours of the day and night who can answer integration questions.

Cost is 2.9% plus $0.30 per successful charge. There are no hidden fees. Earnings are transfered to your account an a 7 day rolling basis.

Unlike most forms of accepting online payments, the sign up process is painless, and you can start with the test API right away. Sign up for Stripe.

Once payment has been processed, FetchApp provides secure delivery of digital files.

Each purchase triggers the creation of a unique download link. You can configure the length of time the link is valid and the number of times it can be used.

There is simple online interface and an equally slick API to manage products, orders, and customers. The feature set includes the ability to send free trials and notify customers when a new version of a product is available.

FetchApp integrates with a number of shopping carts and payment providers out of the box, but my setup uses the API.

Pricing is based on amount of storage required, not number of sales. The free plan covers up to 1MB. FetchApp sign up page.

The above services mixed with some good marketing copy will get you up and running, but you will certainly want to setup a few extras like analytics, A/B testing, and possibly an affiliate program.

Google analytics is the standard choice for analytics – it is easy to setup and provides tons of useful information.

Google Website Optimizer provides A/B and Multivariate Testing.

There are a number of different options for this type of testing. I prefer GWO because it is easy to setup and the reports are simple to understand.

Another avenue for increasing sales is to set up an affiliate program, giving people who promote your product a cut of the sales. Companies like Commission Junction and ClickBank will handle this – they help affiliates find your program and track their sales.

However I don’t recommend either of those programs. Their fee structures are too complicated, and affiliates are often hit with hidden fees. Also, they use “hop links” to track purchases. These “hop links” don’t provide SEO value and look suspicious to customers (a typical link will look something like http://chdxsld.com/kdkd2002kdk before the customer is redirected to your site).

A self-hosted affiliate program will avoid those problems – you can customize the payout percent and affiliate links will look something like http://example.com/ref=ID, but the drawback is you need to publicize the program yourself and handle the affiliate payments.

At the moment, I use the open source idev-affiliates with some code customizations to make it work within my cart and payment stack. I’m not happy with it, and will be swapping idev-affiliates out for something else next time. It is written in fairly messy PHP, and idevspot.com offers a money back guarantee, however, they will not honor it if there is a problem with your purchase.

Anyone have recommendations for self-hosted affiliate software?

Bonus recommendation: if you intend to support a fledgling startup with contract work on the side, or if charging for support is part of your revenue model, Freshbooks is the best option I’ve seen for creating professional invoices.

The Freshbooks web app is an absolute pleasure to work with.

Pricing is based on the number of clients, with up to 3 clients on the free plan. Use this invite to sign up a free 30 day trial of Freshbooks.

You can see this software stack in action at Geotargeter for WordPress – a plugin for Amazon Affiliates.

Why Be Paranoid and Pessimistic

Being paranoid and pessimistic will save your ass constantly. Before even talking about actual code, backups, debuggers, source control, error logging, automated deployment scripts, and almost all tools of the programming trade are predicated on the pessimistic idea that stuff goes wrong often, and there must be procedures in place to identify, correct, and prevent errors.

Another side effect of being paranoid is coding defensively. No matter if you are coding against libraries, code written by other developers on your team, or code written by yourself, it is important to code defensively, because everybody and everything is fallible.

Defensive code makes fewer assumptions and carefully handles error cases instead of failing silently or producing undefined behavior. This leads to code that is easier to maintain and less prone to bugs.

Libraries are updated, frameworks evolve, requirements change. Programmers are constantly fighting against entropy. Defensive programming guards against the effects of software entropy by reducing the possibility that changes in one part of a system will cause subtle bugs somewhere else.

It is important expect the unexpected in all things.

It seems that there’s a mantra that every programmer must memorize early in his or her career. It is a fundamental tenet of computing, a core belief that we learn to apply to requirements, designs, code, comments, just about everything we do. It goes

THIS CAN NEVER HAPPEN…

- The Pragmatic Programmer by Andrew Hunt & David Thomas

Embracing paranoia and pessimism will automatically lead to wonderful things like:

• Explicitly stating preconditions, postconditions, and invariants
• If it can’t happen, using assertions to ensure that it won’t
• Always using source control
• Crashing early – a dead program normally does a lot less damage than a cripple one

All of the above are widely considered good practice, and techniques recommended in The Pragmatic Programmer.

When to stop being paranoid and pessimistic

You should never stop being paranoid or pessimistic, but when interacting with non-technical people, you need to change your game face.

Let’s say you get a phone call from your boss who is a search engine optimization guy. He is wondering if you can build a tool to check how a website ranks in the search engines for various keywords.

You are a good programmer. A paranoid programmer. A pessimistic programmer. You immediately start thinking about the most significant challenges involved. That to do this project right, you will need to account for differences in search results across geographic areas. That means a distributed architecture of some kind, and most likely reports with combined rankings plus rankings broken out by geographic area. Now, if we use too many geographic areas and check them too often, we will significantly change the search volume for a particular term, which can have indirect effects on rankings. Plus scraping results is probably against Google’s ToS…

Swallow those words.

Your boss is a marketer at heart. He is an optimist. He needs to be an optimist in order to sell stuff. He doesn’t want to hear about worst case scenarios or most significant challenges. He needs to know about them, but wrap them up in a language he is better equipped to understand.

“Hrmmm. There are already similar tools out there, so I’m sure this is something we can do. However, I don’t think creating this tool will be as simple as it first appears. The most straightforward way to collect the data is to do some searches programmatically and then scrape the page to get rankings, but I think this is against Google’s ToS, and could get us in hot water with Google. We will also have to account for things like geographical rankings differences. I’m sure there are ways around these issues, but I’m not sure what the solution will look like yet without doing a bit more research.”

See the difference? Instead of your boss getting what sounds to him like a litany of problems, he is now getting some reassurance that it can be done, it just isn’t as easy as he probably thinks it is, and will take some thought to get everything right.

The only problem with pessimistic problem solving is that it is often misunderstood by optimists (read: management, sales, marketing, etc.). You don’t want to be known as the person who spits out a list of problems at every new idea. Try instead to be known as the person who solves problems before anyone else realizes that a problem exists.

So unless you are communicating with optimists, go forth and spread paranoia and pessimism.

The promises of cloud computing

Its hard to do any reading on cloud computing without running into promises that sound too good to be true: “With the cloud, individuals and small businesses can snap their fingers and instantly set up enterprise-class services.”^[1] Or to hear people proclaiming that the cloud is the only solution: “The future is the cloud. Not because it is trendy but because only the cloud can scale.”^[2]

The reality

Despite the cloud being billed as the next evolution of the internet, the reality is that cloud computing has been around for a long time under different monikers: hosted services, Software as a Service (SaaS), shared infrastructure. For the most part, the cloud is made up of all the same technology that existed before the cloud hype got started. It is composed of standard operating systems, databases, load balancers, management tools, and so on.

The innovation isn’t in the tech at all – it is in the operations model.

The innovation is that individuals and small businesses now have access to resources on-demand and at scale without having to maintain the hardware and the expertise to run it in-house. It allows them to experiment and iterate cheaply and quickly.

Individuals have the ability to quickly provision a ruby on rails setup, deploy their application, and then crank up the power if the application becomes popular, or simply throw the instance away if it doesn’t work out. That is the true power of cloud computing. It gives individuals and small businesses access to resources that were previously only cost-effective for the enterprise.

Confusion and angst in the tech sector

There is tension in the tech sector because cloud computing is such a poorly defined concept, and it is usually defined in terms of the technology. When looking only at the tech involved, the amount of hype around cloud computing is completely disproportionate to any advancements in tech needed to create cloud products.

The cloud hype is getting thicker and smellier every day. All the cloud excitement is coming from those who hope to profit from it, the vendors and breathless tech journalists who can’t think of anything worthwhile to write about. They’re working very hard to make it sound like a wonderful thing, a miracle of rare device that will transform life as we know it.Carla Schroder, Editor – LinuxToday.com on Keep your cloud

Even worse, “cloud” has become just a catchy word that is sprinkled over marketing copy to boost customer acquisition and increase buy-in (or something).

The interesting thing about cloud computing is that we’ve redefined cloud computing to include everything that we already do. I can’t think of anything that isn’t cloud computing with all of these announcements. The computer industry is the only industry that is more fashion-driven than women’s fashion. Maybe I’m an idiot, but I have no idea what anyone is talking about. What is it? It’s complete gibberish. It’s insane. When is this idiocy going to stop? We’ll make cloud computing announcements. I’m not going to fight this thing. But I don’t understand what we would do differently in the light of cloud.Larry Ellison, CEO – Oracle Corporation

Anyway, that’s my take on the cloud. The innovative part has nothing to do with the tech and everything to do with the operations model. I suppose Cloud Computing For Dummies will tell you something very different.

1. Roy Stephan, Director of IT architecture and engineering – Intelligent Decisions in CNNMoney Why the cloud is now the hottest trend in tech.
2. Sean McGrath in ITWorld Only the cloud can scale

Always use source control

There is no reason not to use source control. Even for a solo project. Even for a toy project. Even if you never make mistakes. Just use it. Source control offers so many benefits like rollbacks, code diffs, backups, and commit logs that every project will benefit from it.

Don’t break the build

Don’t commit code if it breaks the build. You don’t want to force other people to sift through your code looking for the problem that broke the build before they can continue with their own work.

Commit early, commit often

Don’t go dark. Committing early and often gives you a backup, an incremental log of progress, easier merges, and lets the team know what you are doing.

Remove unused code immediately

Don’t commit code with large blocks of old code commented out or unused, deprecated functions. If you need to get this code back at some point, you can always get it from the repository. Keep the current working copy of the source as clean and cruft-free as possible.

Keep a good commit log

Leave good comments in the commit log. Searching the commit log should allow you to find which commits implemented a specific feature or fixed a specific bug. Skimming the commit log should provide a good history of the project and give some hints as to it’s maturity.

Whitespace

Don’t commit whitespace, formatting, or code style changes at the same time as other changes. If you must make these types of changes to the code base, commit them separately. This will keep the diffs vastly more readable.

Minimal Changeset

When doing bugfixes, make the minimal set of changes needed to fix the bug. If a rewrite of a module is really in order, do the rewrite, but err on the side of making the absolute minimal set of changes needed to fix the bug. This way the changelog will clearly reflect the exact source of the bug and the changes needed for the fix.

One bugfix per commit

Again, keep the changelog clear by doing only one bugfix per commit (unless multiple bugs are very closely related). One bugfix per commit makes rollbacks easier and leaves a clear track of how the bug was fixed that will be valuable later if a regression test fails or if the fix created unintended side effects.

Notify the team of new commits

Other team members working on the code base should be immediately and automatically notified of any changes that have the potential to affect them. This could be setup in different ways depending on the project and the workflow used by the team. One of the easiest and most effective ways to set this up is an automated email including the commit message and the diff to all members of the team working on that particular module. Notifications keep all team members appraised of the current state of the code and give them a heads up if they are likely encounter problems merging their own code.

Integrate source control with other tools

Source control should be integrated with other tools used on the project like bug tracking, continuous integration, and IDEs. This makes it easy to cross-reference the commit that fixed a bug, created a bug, or broke the build. Integration with an IDE gives you the option to do source control operations like diff, status, and commit within the IDE without having to drop to the command line or a separate tool.

The above basic principles of version control will make you effective with any type of version control system out there. Have more source control tips? Leave them in the comments.

1. The terms ‘version control’, ‘source control’, and ‘revision control’ are used interchangeably here.

The hosting platforms covered below provide a Rails environment right out of the box. It is certainly possible to run directly on AWS (or another cloud platform) with a bit more setup work, but that is beyond the scope of this article.

Engine Yard

Setup and deploy process: After creating an Engine Yard account, setup and deploy is as simple as gem install engineyard then ey deploy from within the app directory.

Starter plan: Engine Yard offers 500 free compute hours on a High-CPU Medium instance to test out the service.

Other plans: Plans are completely customizable. You choose the number and type of instances, and then pay per hour for instances, plus extra storage and bandwidth costs. Full pricing details are here.

Version Control: Must use Git for version control.

Conclusion: Engine Yard’s pricing structure is geared towards projects that require compute time, not 24/7 availability, making it most appropriate for data crunching. For web apps that need to be available all the time, but may be idle or nearly idle much of the time, another provider will be more cost effective.

Heroku

Setup and deploy process: Simple git based workflow. sudo gem install heroku then heroku create sushi will create an app called sushi. Deploying is as easy as git push heroku master.

Starter plan: The free starter plan includes one worker (a background process running your code and processing jobs from a queue) and a 5MB shared database.

Other plans: The number of dynos and workers can be adjusted dynamically to handle traffic spikes or provide more proccessing power. Dynos and workers are priced by the hour, and dedicated databases are priced based on the size and number of connections required. See the full pricing details for your particular situation.

Version Control: Must use Git for version control.

Conclusion: Heroku’s free starter plan makes it an ideal choice for bootstrapping a web application and scaling up as needed.

Winnie Cloud

Setup and deploy process: Push to a Git repo managed by Winne Cloud.

Starter plan: Free 30 day trial of the staging environment.

Other plans: Winnie Cloud offers either a production working instance or a staging working instance. PostgreSQL, MongoDB, and Redis are available at extra cost.

Version Control: Must use Git for version control.

Conclusion: It appears that Winnie Cloud started as an internal product of Rails programming shop Ragnarson. It doesn’t seem to be as mature as the other Ruby on Rails platforms, but might be a good option for those who are looking for both Ruby on Rails consulting and a cloud hosting platform in one package.

DotCloud

Setup and deploy process: After creating a DotCloud account, setup and deploy operations are done via the DotCloud command line interface. The CLI handles setting up the stack, deploy, rollback, and a number of other operations. The CLI integrates with Git and Murcurial.

Starter plan: DotCloud offers a free starter plan with two services, where a service is a single connection to a stack component. Or if you were lucky enough to get in during the private beta, there is a free VIP plan.

Other plans: The pro plan at $99 per month allows four services, and a flexible enterprise plan is also available with pricing depending on the requirements of the project.

Version Control: Works with all types of version control, although Git and Mercurial have the best integration with DotCloud’s CLI.

Conclusion: DotCloud is a more general platform than the others; it allows developers to mix and match stack components. Currently in beta: Java, PHP, PostgreSQL, Python, Redis, Ruby, and SMTP. There are a number of other components in alpha or on the roadmap for future support. It’s most appropriate for people who need support for a variety of stack components and don’t mind running on a beta platform.

Final Words

Each RoR platform has its particular strength, and picking the right one at the beginning will save headaches and money further down the road. This article covers the technical details of the different cloud platforms, but glosses over other important considerations like the reliability, transparency, and quality of support offered by the platform.

Please chime in with a comment describing your experiences if you have used any of the above cloud platforms.

There are a few different ergonomic keyboard designs, the most popular are shown below from left to right: the split keyboard, the angled split keyboard (sometimes called a Klockenburg keyboard), and the contoured keyboard.

So which of these will make you the most productive? The most likely to prevent carpal tunnel and other injuries dreaded by programmers? Probably none of them.

There is research showing that ergonomic keyboards increase typing speed. There is research showing that the same keyboard decreases typing speed. Studies show that ergonomic keyboards increase productivity, that they decrease productivity, that they decrease injuries, and that they have no effect on the number or severity of injuries. Whatever conclusion you wish to show regarding ergonomic keyboards, you are bound to find at least a few studies supporting that conclusion.

Sifting through the research, the only clear trend that emerges is that much of the research showing the benefits of ergonomic keyboards was done by manufacturers of ergonomic keyboards, by companies who are in the business of injury prevention consultation, or companies that have some other vested interest in the success of ergonomic keyboards. Further muddying the waters, Google Scholar search results on the topic of ergonomic keyboards are polluted by marketing documents disguised as research, such as this document by Goldtouch, a popular brand of adjustable split angled keyboards.

So which keyboard should you buy? Scientifically speaking, it probably doesn’t make a damn bit of difference as long as you are comfortable and have had sufficient time to adapt to any peculiarities of your keyboard. Test a few out and then get a keyboard that you like. No matter if that is an ergonomic keyboard, a cheapo minimalist keyboard, an old school mechanical keyboard with backlighting, a medical grade waterproof keyboard, or whatever keyboard makes you happy.

There are plenty of other tweaks you can make to your work environment that do increase productivity (and are backed by solid scientific evidence). Read more about how to increase productivity by reordering your office, but forget about ergonomic keyboards.

Bring Nature into the Office

Studies have shown that certain types of environments are restorative: they reduce mental fatigue, increase the ability to concentrate, and improve health, leading to an increase in productivity. One of the most effective restorative environments is nature. An office with a window that has a natural view is enough to trigger the benefits.

Those with a view of nature felt less frustrated and more patient, found their job more challenging, expressed greater enthusiasm for it, and reported higher life satisfaction as well as overall health.^[1]

Colorful, diverse landscapes with natural composition are preferred, and views of trees, water, and sky can increase the restorative effect.

Take action to increase productivity

Take micro-breaks throughout the day to gaze at the natural elements around you. If you aren’t lucky enough to have an office with a window, or if your view is a cityscape instead of a landscape, you can still bring touches of nature to your office. Live plants, tabletop fountains, or posters of nature scenes will do the job as well.

Use High Color Temperature Light Sources

Research has shown that working under light with a high color temperature has a number of benefits such increased mental acuity, vitality, and alertness, increased work performance, reduced fatigue, reduced daytime sleepiness, and improved mental health.

“Color temperature” refers to the color of the light produced; it is independent of the brightness of the bulb. Bluer lights increase productivity and alertness, while yellower lights promote relaxation. Most compact fluorescent bulbs have a color temperature of 2700K or 2850K, and the highest color temperature that is readily available commercially is 6500K.

Studies have shown that the 7500K light sources are correlated with higher mental acuity compared to 3000K light sources.^[2] 5000K sources are correlated with reduced drowsiness compared to 3000K.^[3] 17,000K sources are correlated with improved concentration and thought clarity compared to 4000K.^[4]

Take action to increase productivity

Choose light bulbs that have a high color temperature and a comfortable brightness. Try these 23 watt bulbs, or these 26 watt (equivalent to 100w incandecents) bulbs.

Use a Highly Adjustable Chair

A highly adjustable chair combined with ergonomics training has been shown to improve health by reducing the incidence of musculoskeletal pain an injury. A reduction in bodily pain was observed throughout the day, and the study found a significant economic benefit in investing in an ergonomic chair.

[...] the chair-with-training intervention is associated with productivity improvements of $354 per worker per day and has a benefit-to-cost ratio of 22:1^[5]

An ergonomic char is one of the more expensive workspace changes to implement, but the benefit-to-cost ratio clearly shows that it is worth it.

Take action to increase productivity

Invest in a highly adjustable chair and learn how to use it properly. Have a look at Herman Miller’s line of highly adjustable Aeron chairs. Use a chair with adjustable armrests in height, width, and pivot, adjustable chair height, a flexible back support, adjustable firmness support in the lower back, adjustable seat depth, and a gliding mechanism that allows the seat to glide forward as you recline.

Keep the Ambient Temperature Comfortable

There has been quite a bit of research on the effect temperature has on productivity. The graph below is taken from a meta-study which summarizes the findings of a number of studies on the relationship between temperature and performance.

There is a lot of variation in the optimal temperature in terms of productivity. This may be caused by personal variations in comfort zone temperature, seasonal variations, or climate differences between the locales where the studies were conducted.

Further muddying the issue is that some studies provide evidence that for optimal work performance the temperature should be in the comfort zone, but other studies show that temperatures outside of the comfort zone cause arousal effects that increase performance.

Based on our review, available data do not provide compelling or consistent evidence that temperature variations within the comfort zone significantly affect worker performance. However, performance decrements are more clearly established for temperatures outside of the comfort zone. Decrements are most clearly documented for high temperatures.^[6]

Take action to increase productivity

Maintain an ambient temperature that is comfortable or slightly cooler than your comfort zone. Avoid working in high temperatures.

1. Rachel Kaplan, The role of nature in the context of the workplace, Landscape and Urban Planning, Volume 26, Issues 1-4, Special Issue Urban Design Research, October 1993, Pages 193-201, ISSN 0169-2046, DOI: 10.1016/0169-2046(93)90016-7.
2. Deguchi T, Sato M: The effect of color temperature of lighting sources on mental activity level. Ann Physiol Anthropol 1992, 11:37-43.
3. Noguchi H, Sakaguchi T: Effect of illuminance and color temperature on lowering of physiological activity. Appl Human Sci 1999, 18:117-123.
4. Peter R Mills, Susannah C Tomkins, and Luc JM Schlangen, The effect of high correlated colour temperature office lighting on employee wellbeing and work performance, Journal of Circadian Rhythms 2007, 5:2 DOI:10.1186/1740-3391-5-2
5. Amick, Benjamin C. III, PhD; Robertson, Michelle M. PhD; DeRango, Kelly PhD; Bazzani, Lianna MPH; Moore, Anne PhD; Rooney, Ted MPH; Harrist, Ron PhD, Effect of Office Ergonomics Intervention on Reducing Musculoskeletal Symptoms, Spine, Volume 28, Issue 24, 15 December 2003, Pages 2706-2711
6. Seppanen, Olli, Fisk, William J., & Faulkner, David. (2003). Cost benefit analysis of the night-time ventilative cooling in office building. Lawrence Berkeley National Laboratory: Lawrence Berkeley National Laboratory. LBNL Paper LBNL-53191.

This is the third design since GrokCode went live in 2007. Unfortunately I don’t have a screenshot of the first design, but it was ugly enough that perhaps it is better off forgotten.

What’s different?

There are quite a few changes, but they all tie back to 3 main goals: keep the emphasis on the articles, include more information for prospective clients, and try not to be so ugly.

Emphasize the articles

The programming and software development articles are the heart of GrokCode, and I wanted that to be obvious. The article pages are now less cluttered and there are fewer distractions.

GrokCode has never been ad-heavy, and the new design further reduces the number of ads. Many pages are add-free, and there is never more than one ad per page. If you would like to support the continued creation of new articles, you can buy yourself a few computer science and programming books (or anything else) from Amazon.

Other tweaks to improve readability and keep the layout neat include cleaning up the sidebar, moving comments to their own page, and switching to a fixed-width layout.

Meet new clients

The old design had virtually no information for prospective clients. There was a portfolio of work, but no information about how I work, what I do, and nothing to even really suggest that I am taking new projects. The new design remedies this with new information on working with me, a better about page, and an updated portfolio. The idea is to make this info accessible and obvious, but not in-your-face.

Don’t be ugly

Even though I am not a designer or a frontend developer, I do all of the GrokCode designs myself from scratch to get a peek into how the other half lives. I was aiming for a beautiful, minimalist, and a slightly retro look, and I spent quite a bit of time reading and learning about logo design, color selection, typography, copy writing, etc. In the end I’m satisfied that it’s not ugly.

Design critiques are welcome in the comments.

What’s broken?

The switch went off without too many problems. Other than a problem with the feeds, all of the remaining issues that I am aware of are all “won’t fixes” or “can’t fixes.”

Feeds

The only lingering issue that I have on my list to fix is that the feeds aren’t working quite right yet. If you are subscribed to the feed via RSS or email, you probably saw that a bunch of old articles were marked as new and resent. You may also be seeing an excerpted feed. Sorry about that. If you haven’t yet subscribed to the feed, you can subscribe here; things will be back to normal shortly.

Details

A few of the details are “broken by design,” which is to say that some of the nice extras degrade gracefully on older browsers and some browsers don’t properly render valid HTML5. Since this is a personal site, I have the luxury of saying that I don’t care too much if things are a little wonky on browsers that don’t comply with standards.

If you are one of the 17% of GrokCode visitors using an outdated or non-standards compliant browser (*cough* IE) things just won’t look as nice. Have a look at Firefox 3.5 vs. IE 8.

The retro style is a bit spoiled by the boxy links, and the some of the finer details like rounded corners and transparency are lost.

Fonts

Again, the fonts aren’t exactly broken, but some people will have a better experience than others.

If you are one of the 32% of GrokCode readers on Windows XP, the fonts will be rendered poorly. This isn’t just a problem with GrokCode or web pages in general – Windows XP is just bad at fonts. I had no idea that the problem was this bad until doing cross-browser testing, and I used to use XP quite often. I had to modify the original design so that it would be readable on XP (I believe Vista and 7 are better).

Have a look at the side by side of Ubuntu and Windows XP. You are looking at the difference between aliased and anti-aliased text.

Other than that, I think everything is working fine. If you see anything strange or something doesn’t seem to be working, please let me know via comments or email. Friendly advice and constructive criticism on the redesign are also welcome.