Topic: Uncategorized

Building enormous websites means us shifting the burden of our mistakes onto every single user that visits our site. It’s us saying that we’re willing to build something that isn’t for some users, because that’s most comfortable for us—no different from “best viewed in Internet Explorer 5.5” or “best viewed at 600×800,” but much more costly.

I’ve been thinking a lot lately about how actual progress on a project doesn’t always match the impression of progress—sometimes a lot of code has changed but nothing looks very different, while other times a small change in code gives the sense that the whole project has moved leaps and bounds.

A couple of big announcements are making the rounds this week: Google advises progressive enhancement and the W3C publishes an official HTML5 recommendation.

About five years ago, I bought a cushy couch for my office. (Okay, yes, I did get the model that could flatten into an emergency nap station, but let’s just say that I plan for contingencies—it sounds more professional that way.) Our projects required a lot of office-to-office visiting to discuss situations in person, and eventually, said couch (and therefore, my office) became a veritable beacon, attracting anyone looking for an excuse to decompress. Such is the life of a one-couch, 50-chair business.

In client work, it’s our responsibility to ensure that our work lives beyond ourselves. Sometimes that means making sure the CMS can handle clients’ ever-changing business needs, or making sure it continually teaches its users. For clients with an internal development team that will be taking over after you, it means making sure the design system you create is flexible enough to handle changes, yet rigid enough to maintain consistency.

As a freelancer, I work in a lot of different code repos. Almost every team I work with has different ideas of how code should be organized, maintained, and structured. Now, I’m not here to start a battle about tabs versus spaces or alphabetical order of CSS properties versus organizing in terms of concerns (positioning styles, then element layout styles, then whatever else), because I’m honestly not attached to any one system anymore.

Part of getting comfortable with the command line is making it your own. Small customizations, shortcuts, and time saving techniques become second nature once you spend enough time fiddling around in your terminal. Since Git is my Version Control System of choice (due partially to its incredible popularity via GitHub), I like to spend lots of time optimizing my experience there.

I recently read Greg Smith’s piece on Bocoup’s blog about how they think about time tracking, including all the fascinating data about how your brain works to solve problems. It interested me a lot, since I’ve been thinking about not just how I track projects, but also how I structure my day as a freelancer.

On Saturday, Benjamin Hollway, a 16 year old front-end developer, wrote a post about his recent experiences attending industry events. He’s been coding since he was eight, and earlier this year he was shortlisted for Netmag’s Emerging Talent category. Yet none of the people in this category are able to participate fully in the sort of activities most of us take for granted.

A newly-discovered Linux flaw may be more pervasive, and more dangerous, than last spring’s Heartbleed.