Subscribe: Warpspire
Added By: Feedage Forager Feedage Grade C rated
Language: English
code  css  design  don’t  github  good  idea  ideas  it’s  i’ve  make  new  people  product  that’s  time  work   
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Warpspire


Updated: 2017-10-21T04:19:53+00:00


Your community is what you make it


I know of a man who owns land in Montana. His dream is to prove a theory about design. For a small sum of money, you can lease some of this land — about a week’s worth of San Francisco rent will get you an acre for a year. Build a house. Plant a garden. Raise some pigs. And you can use his tractors, too. But you can only do these things under his rules. His rules are somewhat strange to most people. You cannot use paint. You must listen to 200+ rambling podcasts. You cannot import compost from outside the property. You cannot use plywood. You can’t smoke pot. His dream, his rules. It has been slow recruiting people to join his effort. But that’s okay. It’s his rules, and he wants a community after his own design. He has chosen exactly what he wants his community to look like: people like him. Can you imagine having an acre of land for cheaper than a week’s rent in San Francisco? There has been much hand-wringing in the software community as of late as to what role product companies have in shaping their communities. Reddit struggled with hate groups organizing themselves in their forums. Because if we kick one group out, where does it end? Facebook has become the place that foreign powers manipulate US elections through advertising. Because what is the difference between opinion and facts, anyway? And Twitter, of course, has become a favorite home of white supremacists and nazis. Because you’ve got to be objective. In each of these cases, the companies have vehemently defended the rights of these obviously-bad people to use their service, while the vast majority of their users tell them to kick these obviously-bad people out. “It’s complicated,” they claim. A silly excuse for a company with thousands of highly creative intelligent people. Despite what the executives of these companies may say, this shit is not complicated. Your community is what you make it. If you choose to make no rules, you have still made a rule. If you choose to give nazis a voice, you have chosen to make your community nazi-friendly. Rebranding that decision under the guise of free speech or objectivity makes no sense. When you make an environment friendly for nazis, it is a nazi-friendly environment regardless of the reasons it happens to be friendly for them. There is this dream often used as justification. A digital platform that connects all with absolute freedom of speech. A modern day utopia of radical ideas being exchanged in a completely free environment. Executives say they have a moral responsibility to make this idealistic dream a reality. It’s a very Ayn Rand idea. It is important to remember that Ayn Rand wrote fiction. In the real world, we often sacrifice our ideals because of the messy nature of reality. Capitalism… except for those subsidies. Freedom of religion… except no suicide cults. Second amendment rights… except no automatic weapons. For every ideal, there is always a reality. A reality where you have to draw the line — a subjective line — in order to preserve our morality, integrity, and way of life. Your community is exactly what you make it. The man in Montana has lost members of his community because of his rules. Twitter has lost members of its community because of their rules, too. In fact it’s much worse — good natured people aren’t so much leaving as they’re getting poisoned and becoming toxic. The only thing worse than losing a user is turning them into a toxic user. Twitter believes that somehow allowing everything means they’ve created an environment that’s friendly for everyone. But often times it’s important for a community not to have a person in it. Imagine a party with ten of your best friends. Now imagine a party with ten of your best friends and one nazi. That is the really important thing about communities: they are made both of what you include and what you exclude, and each of those have equal weight. Not having a particular person is just as meaningful as having a particular person. It is the same with music: without rests, music is just noise. I[...]



So, what is it you do all day? I sort of disappeared a few years ago. I had a simple but difficult decision: stay and help GitHub to help grow the company or leave and help my family when they needed help most. In the space of a couple of weeks I quit my job, packed up my belongings, and moved out of San Francisco. Ever since then, I’ve struggled to describe how it is I spend my time to my peers. Discussing the practicalities of caring for someone with a neurological disorder is not exactly small-talk worthy, nor is it something I particularly want to discuss with strangers. There’s also the unfortunate culture in technology that devalues everything unrelated to militant capitalism. If you’re not trying to make money, what are you even doing? Now add on to that the few that saw my vulnerability as an opportunity for leverage — and indeed — leveraged the fuck out of me. It’s all added up to be an interesting couple of years. So when people ask what it is I’m doing, I’ve mostly kept it light. I tell people I’m semi-retired. It’s not entirely untruthful — I’ve spent a lot more time outside and doing fun things — but it’s a lot less than the whole. That being said, I’ve been working hard for the past few months to find more space for me again. Which also means I’ve been thinking more about what’s next. A lot of people talk about passion with regards to work — that feeling of endless energy one feels when their inner desires meet application. Work no longer feels like work, and all questions of is this worth it? and am I doing the right thing? feel silly and irrelevant. I used to have a lot of passion for software. Whatever I have now is different. I feel torn between the endless opportunities I see in software and the disgust for what our industry has become. The rational part of my brain tells me you don’t have to be like those terrible people to work in software, but the emotional side of me sees what our industry is doing in practice and doesn’t want to be associated with it at all. You can still do good work and be employed by Exxon, but at the end of the day you’re still working for the oil industry. Is that who I want to be? I’ve spent a lot of time asking myself why I am so frustrated with our industry, and I think I’ve narrowed it down to two common themes: The routine manipulation of employees, gig or otherwise, through complicated legal structures (1099’d full-time employees, stock option agreements, expensive lawyers, employment/termination agreements, etc). The routine manipulation of customers through complicated technical structures (selling data without permission, outright spying, bricking expensive hardware to avoid liability, etc). To work or participate in the technology industry is an exercise in minimizing manipulation (or, if you’d like to be rich, maximizing it). This feels shitty in a tremendously heavy way. What happened to the idea of building great stuff that people are happy to pay for? What happened to the idea of treating employees as people and not legal entities to extort? Were these fantasies of a naive 20-something Kyle, or a reasonable idea of how our industry should act? Why do the needs of the corporation always seem to outweigh the needs of people? Honestly, it’s all driven me a bit crazy. But more relevant to this essay: this shitty-ness has eroded my enthusiasm for building software. That’s a bummer. Something I have been very enthused about as of late is permaculture, or at least many of the ideas that circle around that particular label. What I love most about permaculture is that it transforms the laborious step-by-step annual process of contemporary gardening into systems design. Instead of remembering to water each of your plants every day, you set up systems to capture water so you don’t have to irrigate. Instead of measuring out fertilization schedules, you design plant systems that provide the nutrients each of them needs. The end result is that it mak[...]

Ad Supported


In a few weeks time, iOS 9 will launch with Safari Content Blocker. This technology allows the general public to use content blockers (better known as ad-blockers) on their iPhones. It’s kind of a big deal. Ad-blockers allow users to remove annoying advertisements from web pages in real time. It’s as if the ads don’t exist. A lot of publishers think this spells the end of online content, as publishers will no longer be able to earn enough revenue to support their staff. I think they’re probably mostly right. Online advertising won’t be a viable business model for long. Many existing publishers will go out of business. It will be a difficult time for many in the industry. But I don’t think the web is going to suffer with a little less content. We’ll do just fine. Online advertising is on its way out as a viable business plan. But there’s a twist in this story. It’s ad-supported publishers that created the market for the ad-blockers which are spelling their doom. It’s kind of poetic if you think about it. Loglo I remember the first time I read Snow Crash and came upon the idea of loglo: As the sun sets, its red light is supplanted by the light of many neon logos emanating from the franchise ghetto that constitutes this U-Stor-It’s natural habitat. This light, known as loglo, fills in the shadowy corners of the unit with seedy, oversaturated colors. That passage gave me chills. This wasn’t so much fiction as much as an amplified view of what is already happening. Today, many American freeways are lined with bright, colorful LED advertisements that give the landscape a supernatural coloring. I remember my city once had to issue regulations for brightness after several accidents were caused near a particularly bright ad. A similar story has been playing out online. The only touch of color and animation on most publisher’s websites are advertisements. The ads are bright, loud, and everything the content is not. They have become so egregious that they often overwhelm articles, creating an environment where content fades into an infinite sea of ads. Loglo lights the streets of Snow Crash. Content floats upon an ad-sea online. Annoying Newspapers have had ads for a long time. They’re usually in black & white (unless the whole page is color) and they sit in their little boxes next to the content. There exist many situations where ads are fine. But online, it’s a different story. Ads expand, pushing your content out of the way, automatically playing video & sound, forcing you to interact with them to continue. All in all, ads have been as annoying as technically possible, and there’s a lot that’s technically possible now. With this technical race comes a severe performance handicap on our computers. Much of our processing power and battery life today is spent rendering ads, not doing the work we set out to do. Under the surface, they have intruded deep into our personal lives, robbing us of our privacy. Ad networks have built complicated mechanisms to track us and store information about our personal lives. How old are you? Do you own a home? What’s your income? Ad networks collect this type of information and share it — with a fee — to other companies without our consent. The saddest part is how deceiving ads have become. They deceive in message, claiming the improbable/impossible (one weird trick…), and they deceive in appearance, pretending not to be an ad. There is little quality control in advertisements, and deception is the name of the game in majority. Ads are downright predatory to anyone who isn’t tech-savvy (and even then…). Publishers play their part too. They constantly seek new ways to inject advertising in & around their content — whether it be turning the entire background into an ad, or disguising advertisements as journalism via native advertising. When users stop paying attention to the low-quality ads, publishers blame the users for “forcing” them to implement more invasive ads.[...]

Lost in Your Vision


Dustin Curtis recently wrote about Fixing Twitter — most of which I can’t say I agree with — but he did touch on an idea I like to call being Lost in your Vision. This affliction affects employees and non-employees alike, and boils down to two major symptoms: The belief that good performing products are nearing certain death The belief that companies are emotionless machines directed by a singular Visionary I call this Lost in your Vision because you become obsessed with the idea that if the product only had “Vision” everything would be perfect. Markets will open up, customers will cry with joy, and champagne will rain down from the heavens. And the person to deliver the Vision is clearly a Visionary. If only the company had a true Visionary, it would be saved from certain death. I know this feeling. I was this person, and let’s be honest — I still am this person often. It’s an easy mindset to fall into. I think Twitter badly needs to do at least five things to address imminent existential threats–things which its current team has tried and spectacularly failed to accomplish. — Dustin Curtis Unfortunately, this is tunnel vision and serves only to blind you from seeing the most lucrative territory: small gradual improvements to existing features and cranking out good-enough ideas. Also known as boring work. Microsoft vs. Apple Microsoft is an example of a company that’s been focused on Big Ideas for the past decade or so. They look at existing markets and try to jump ahead as far as they can see. The Microsoft Surface was a peek into the future of tablets, much like the HoloLens is a peek into the future of VR. Microsoft is not doing well. Apple on the other hand is an example of a company that’s been focused on small ideas for the past decade or so. Every year, iPhones have gotten a little better. Their laptops get a little better. iPads get a little better. And every few years, the Apple TV gets a little better. Today, Apple announced three new products: iPhone 6S. It’s like the iPhone 6, but everything is a little better. iPad Pro. It’s like the iPad, but everything is a little better. Apple TV. It’s like the old Apple TV, but everything is a little better. These aren’t revolutionary ideas. The iPad Pro is almost exactly the same idea as the Microsoft Surface, but 3 years late. I don’t think they’re worried about it. Apple is doing extremely well. Big companies thrive on small ideas. The soul of a product I once gave a presentation at GitHub titled Good Product in which I tried to distill what a good product meant. My intro was focused on the idea that Product as an idea was a connection: People ⨯ The product of the two was our Product (get it, the product?). It wasn’t just the software we delivered, it was how our customers used the software that mattered. In order to deliver impact, you can increase the number of customers, or you can increase the usefulness of the software to existing customers. In large customer bases, customer growth is almost entirely fueled by network effects — existing customers getting new people hooked. It is not fueled by new features or new functionality. Changing your product in dramatic ways has a higher chance of distancing existing customers than opening it up to new markets. This means it’s almost always a better idea to focus on small improvements to existing workflows in large companies. How can you make your core feature smoother? How can you make it easier to get started for new customers? These aren’t sexy ideas, but they’re impactful. Big companies thrive on small ideas. Software is made by people Twitter has over 4,000 employees. That’s a lot of people no matter how you slice it. The flow of ideas through large companies is a phenomenon we don’t entirely understand. If you haven’t ever been in the shit, you might assume that ideas flow from the Visionary (CEO) down. But much like rivers, they twi[...]

Million Dollar Products


The mid 2000s were a crazy exciting time to be a hobby programmer. We’d suffered through a decade or so of trials to test our merit — The ASP/PHP Wars, The Trouble of Tables, DHTML, WAC-FR & sIFR, and of course — IE 5.5 for Mac. But things were finally looking up. We had a free database that was easy to administer, hosting was becoming affordable, broadband was becoming the norm in middle-class households, browsers could render CSS half-competently, web frameworks were becoming accessible to novices, and best of all, we could finally use transparent PNGs. The web was coming of age, and the barrier to entry was falling fast. If you had a computer, internet, and some free time — you could help build it. As for myself, it felt like I had accidentally accrued the skills to turn dirt into gold. The blogs I followed trended toward product launches, and it felt like everyone around me was succeeding. The formula for success seemed simple: Pick a task that people already use software for (communicate, organize, write, etc). Build a better piece of software to accomplish the task. Iterate on it with customer feedback. Build up enough revenue to quit your job and work on it full time. I can’t help but feel our industry doesn’t think this way anymore. It feels like the hobby programmers of today are only interested in building Unicorns — a really stupid name for companies valued at a billion dollars or more. People don’t start hacking on projects anymore, they become CEOs and start looking for funding. If it doesn’t capture the entire market, what’s the point of showing up? This shift in mindset has made Silicon Valley feel like some kind of Wall Street 2.0 Incubator. We’ve attracted the worst kinds of people to our industry, grown our companies recklessly fast, insulted our customers with security breaches & poor quality, exploited our employees, and signed away most of our winnings to professional executives and venture capitalists. We stopped building products that allow people to do more. Now we build products that make people use more. Working in software isn’t as exciting as it used to be. Reasons to be excited are drowned out by assholes announcing how busy they’ve been fucking people over to make themselves rich. It’s embarrassing. I don’t think Unicorns are good for our industry. I’ve grown to love the concept of a family business over the past few years. Operationally speaking, they’re the same as any other business. But philosophically, they’ve made decisions about how to run the business such that it benefits & reflects the values of the family running it. I like these businesses because they tend to treat their customers much better than traditional growth-focused businesses. We don’t really have a concept of family owned software businesses yet, but I do think we can try to emulate the best parts of them. What would that look like? Treat People Well + Make Money + Build Rad Shit In most software businesses, revenue is looked at as a metric of unlimited potential. With unlimited potential comes unlimited opportunity costs. Almost every decision feels like it weighs against future maximum revenue. But what if you purposefully put a target on the amount of money you want to make to one million dollars a year? Instead of worrying about opportunity costs at every turn – taking funding, hiring that sketchy VP of Sales, partnering with that company you hate — you can focus your effort elsewhere: employees, customers, and product. Employees You don’t need a lot of employees to run a million dollar product. I’d say you can do it pretty well with about five1: 1 person focused on the business/company 1 person focused on customer support 3 people focused on product development Five people is a small enough number to treat very well as a company. You don’t have to worry about getting tangled in communication struggles, manageme[...]

Measuring emotion


One of the most important responsibilities for managers in tech companies are having regular one-on-ones with their team. The idea is to meet with each member of the team once every week or two, face-to-face, to talk about whatever the team member wants. And the face-to-face part is crucial. Our brains process an immense amount of information during a conversation — eye contact, facial expressions, intonation, body language — everything that’s beyond the content of our words (what an email might convey). This information trains our intuitive reasoning, building understanding and perspective — allowing us to better understand what the other person means when they say something. Yet there is an entire class of managers in software today that avoid face to face interaction with those they manage: product managers. It’s common for a product manager to be running multiple experiments every week, but how common is it for a product manager to spend face time with multiple customers every week? Why is that? The vibe I get from our industry today is that product managers believe measurable data and analytical reasoning are king and result in superior decisions. Many even believe with enough effort, they can measure emotion. They see emotions in their analytical world view: as a (difficult) metric to be measured, tested, and improved. This is how we end up associating ideas like Churn (an artifact of your billing data) with an emotion like Frustration (something a human feels). But emotion can’t be measured, it must be felt. I recently listened to a great Planet Money episode on Spreadsheets! that discusses the history of spreadsheets and how it’s changed the way we make decisions. The episode was inspired after an article written in 1984 about the significance and danger of the advance of spreadsheets: The spreadsheet is a tool, and it is also a world view — reality by the numbers. — Steven Levy on A Spreadsheet Way of Knowledge Many of us don’t use spreadsheets today, but we do use tools that came from spreadsheets and promote the same world view. We compare competing Facebook events by the number of RSVPs hoping to optimize our party enjoyment. We sort by rating on Amazon hoping to optimize our dollar. We scour Yelp and Foursquare to optimize the enjoyment of our meals. And product managers crunch numbers and run experiments to optimize their product decisions. Take a minute to think about how the spreadsheet has changed your life. How often do you make a decision without researching how to optimize something? This is not to say we shouldn’t use “spreadsheets” to optimize our decisions. We often do make better decisions through data analysis. Rather, what I think is interesting is just how significant our bias toward analytical reasoning has become. Our hammer is the spreadsheet, and now we’re making everything in product management a nail. I’ve long been a believer that your environment significantly shapes the type of products you can build. Have nothing in your houses that you do not know to be useful, or believe to be beautiful. When you’re building software, your environment is primarily made up of the tools and processes you use. And when I look at the processes that dominate our industry today — Agile/XP, Lean, Data-Driven — they have a common trait. They assume a lack of emotion — an overriding rationality of our customers. Think about Agile/XP User Stories. The original purpose of a User Story was to produce an estimate for work. But the unintended consequence is that User Stories have become a popular tool for product managers who believe they are communicating the perspective of customers. Why describe functionality when you can communicate what the customer wants? But this is reality only by the numbers. I guarantee you that no one wants to purchase a parking pass. Many people want a parking pass, but no one want[...]

The Moral Bucket List


As someone who’s recently struggled with the pace of my work and where to focus my energy, I really related to David Brooks’ recent essay The Moral Bucket List:

But I confess I often have a sadder thought: It occurs to me that I’ve achieved a decent level of career success, but I have not achieved that. I have not achieved that generosity of spirit, or that depth of character.

On passions:

Commencement speakers are always telling young people to follow their passions. Be true to yourself. This is a vision of life that begins with self and ends with self. But people on the road to inner light do not find their vocations by asking, what do I want from life? They ask, what is life asking of me? How can I match my intrinsic talent with one of the world’s deep needs?

Yes! I’ve struggled with how to describe this feeling for a long time — this feeling that while it’s probably good advice to follow your passions, you may find more fulfillment following where you’re most needed. This essay is based on his new book The Road to Character, which I’m pretty excited to dive into here soon.

Pairs well with this fantastic answer on How can I be as great as Elon Musk? by his ex-wife, Justine:

These people tend to be freaks and misfits who were forced to experience the world in an unusually challenging way. They developed strategies to survive, and as they grow older they find ways to apply these strategies to other things, and create for themselves a distinct and powerful advantage.

Do your priorities lean toward being as great as Elon Musk, or achieving a depth of character? I think it’s a good question to ask yourself, especially if you work in power-hungry environment like technology.

Taste and The Zen of GitHub


There’s a lot of interesting things that happen the first time you really grow a company. Most are exciting, some are challenging, and a few are downright confusing. Every organization (and individual inside) experiences growth differently, which makes for some great stories. This is one of mine. The only problem with Microsoft is they just have no taste. They have absolutely no taste. And I don’t mean that in a small way, I mean that in a big way, in the sense that they don’t think of original ideas, and they don’t bring much culture into their products. — Steve Jobs I’ve always loved this quote. And to be honest, I’m not sure why. It’s an empty statement. What does having no taste mean? How do original ideas and culture factor into taste? Microsoft has always had plenty of original ideas (designers tend to mock and ridicule these especially), and — well — of course they have culture. That’s not a thing you can get rid of. It must be that their original ideas and culture were the wrong type. What makes Apple have taste and Microsoft have no taste? About two years ago, GitHub’s product development team was growing fast and I found myself thinking about these questions more and more. We were getting an influx of new points of view, new opinions, new frames of reference for good taste. One thing that challenged me was watching design decisions round out to the path of least resistance. Like a majestic river once carving through the mountains, now encountering the flat valley and melting into a delta. And the only problem with deltas is they just have no taste. So how do you build taste? I’d argue that an organization’s taste is defined by the process and style in which they make design decisions. What features belong in our product? Which prototype feels better? Do we need more iterations, or is this good enough? Are these questions answered by tools? By a process? By a person? Those answers are the essence of taste. In other words, an organization’s taste is the way the organization makes design decisions. If the decisions are bold, opinionated, and cohesive — we tend to say the organization has taste. But if any of these are missing, we tend to label the entire organization as lacking taste. Microsoft isn’t lacking taste — they have an overabundance of it. This is one of the biggest challenges a design leader faces. How do you ensure your team is capable of making bold, opinionated, and cohesive decisions together? It was certainly challenging me. With new employees came different tastes — often clashing against each other, resulting in unproductive debate and unclear results. We needed some common ground. Idiomatic code and The Zen of Python As dynamic languages have become more popular, so have the phrases idiomatic code and good style. With dozens of ways to write each line of code, developers are expected to not only know how to accomplish a task, but in which style they should to accomplish it in. unless cookies? if (!cookies?) if (cookies? == false) unless !!cookies? run_away_to_the_woods! There is no Chicago Manual of Style for Ruby. We are instead asked to absorb good style from others who have good style. But who has good style? Matz is nice so we always raise exceptions in unsuccessful calls to methods ending in a bang‽ Unfortunately these kinds of decisions are easy — what isn’t so easy is to know when a class is too big, you’ve chosen poor names, or exactly how much meta-programming is too much. To make it worse, each of these decisions change over time as the taste of the Ruby community evolves. Style guides are often tied to specific organizations and people, not to the Ruby community itself. Cool. This may explain why I was overcome with a feeling of jealousy the first time I read The Zen of Python. I’m not usually one to get into religious[...]



I remember the first time Bitbucket straight up stole one of my designs. The layout. The borders. The shadows. The exact information on the page!

I was angry.

This is my design. I was the one who put in the time. I spent the hours in a dark room with all the stuff that could be until I had the stuff that should be. I was the one who designed five wrong iterations until I got the right one. And it was good. People loved it. And these — these barbarians just stole it. Every last bit.

I was real angry. I wanted to start a scene. I wanted to get real angry, real public.

But my customers didn’t care. They didn’t even notice.

Because they were my customers. They loved it. They were happy. They got something nice to use. Customers love that shit. They eat it up. Nice to use? Into it.

Ego is such a hard thing. I struggle with it constantly. I struggle with it right now as I’m writing this. I know at my core that when I design software, the most important thing to me is that people are pleased — that they like using my product and it makes their life a little bit better. And I know — I know — that has everything to do with the product, and nothing to do with me.

But here I am. And I want it to be about me.

And to be honest, that’s still the hardest thing about designing products. Design is a job. If I want people to celebrate me, this isn’t the career. My job is to make good shit that people like. And there isn’t room for me in that equation.

There’s the product.

There’s the team.

But more than anything else — there’s the customers.

Those people who make products real. Real life humans with emotions and opinions and happiness and sadness and money. Money that puts food on my table.

So you know, I have to remind myself: it’s about them. It’s about the customers. It’s not about me.

Dumb systems are obvious. It’s obviously doing something dumb — too much work, too inflexible. But the work is predictable. It’s obviously doing too much work. I can see everything.

Dumb software can do great things. It put humankind on the Moon. It got us to Mars. To me, it feels like the dumber the software, the more it accomplishes.

I want to create great things. And sometimes it just feels right to build a simple little static website with HTML, CSS, and JavaScript.



American service constantly presses on its diners. Can I show you to your seat? Here’s some menus. How’s the meal? Would you like the check?

Would you like the check? American servers always ask you if you’d like the check. Sometimes they’ll even bring you the check before you’re done eating.

It’s all about turning tables. More tables, more tips (it’s not all greedy — servers are paid less and rely on tips as part of their salary in America). And diners have places to go and people to see, right?

The pace of meals in America is a reflection of this service style. People come in for dinner, eat, and leave.

Many European cities have a different view on service — a very opt-in style. It would be rude for your server to ask if you’d like the check. It’s up to you when you want to leave.

In Barcelona, once you’re done with the meal your server comes by to take your plates away and asks if you’d like some coffee. Encouraging you to stick around and enjoy the surroundings.

The pace follows. Meals last longer. More conversation, more time at the table. There’s no pressure to move on to the next item on your task list.

A lot of people I talk to label this change of pace as “european cafe culture”. But I think it’s really just a culture of people comfortable staying at restaurants without eating/drinking something as fast as possible.

A few weeks ago I was in Barcelona taking a break from life. At one point, my friend was sketching out a tattoo and I was reading while we enjoyed an after lunch coffee. We were both doing things I often hear people say they wish they had more time to do.

I hate that phrase. We all have the same amount of time. We choose how to spend it.

Pace. I want to spend more time conscious of the pace of my life.

Peepcode Play by Play


I sat down for a while with the excellent PeepCode folks and recorded a Play by Play — a real time video of me solving a design problem. A bit terrifying, a bit fun. Check it out if you’d like to see me bumble around.

Choose Your Adventure! slides


Slides from my presentation I gave at Úll - Choose Your Adventure!

Knyle Style Sheets


So I’ve been writing CSS for somewhere around 13 years now. Some might think I’ve learned the right way to write CSS in that time — but if you ask me all I’ve learned is the most efficient way to drive someone insane. CSS is complicated. It’s not object oriented. It’s not hierarchical. It’s a specificity based cascade applied to a dynamic hierarchical data structure that few people truly comprehend. Trying to impart this knowledge on someone is a very difficult task with extremely minimal rewards. I used to think that imparting this knowledge was the path toward writing maintainable CSS within a team. Maintainability comes from shared understanding It’s hard to define maintainability. In my eyes it has to do with creating a shared understanding. Anyone who has owned an aircooled Volkswagen knows how to adjust valves on any other aircooled Volkswagen. This is because of one of the best technical books ever written: How to Keep Your Volkswagen Alive. Everyone I know who owned a Bug, Bus, Ghia or Thing owns a copy of this book and understands how to work on their car. This book is in large part responsible for that shared understanding. How can we create a shared understanding with CSS? Documentation For all of the talk of Object Oriented CSS, SMACSS and pre-processors like SASS/SCSS & LESS… no one is talking about documentation. Documentation is the key to shared understanding. Enter KSS Inspired by TomDoc, KSS attempts to provide a methodology for writing maintainable, documented CSS within a team. Specifically, KSS is a documentation specification and styleguide format. It is not a preprocessor, CSS framework, naming convention, or specificity guideline. This means it works great with ideas like OOCSS, SMACSS, SASS, and LESS. I’ve created a specification for KSS as well as a ruby gem to parse the documentation. In a nutshell, KSS looks like this: /* A button suitable for giving stars to someone. :hover - Subtle hover highlight. .stars-given - A highlight indicating you've already given a star. .stars-given:hover - Subtle hover highlight on top of stars-given styling. .disabled - Dims the button to indicate it cannot be used. Styleguide 2.1.3. */{ ... }{ ... }{ ... } The idea is to write simple, yet machine parseable documentation such that you can automatically create a living styleguide like this one: KSS aims to create a shared understanding I’ve tried really hard to make sure that KSS is flexible enough to work with as many styles of CSS development as possible. It’s purpose is to create a shared understanding through code documentation and styleguides. Not to tell you how to write CSS. And well. I think that’s an important idea. Hope you like it. [...]

Knyle style recruiting


Otherwise known as Kyle Neath’s guide to hiring the best people in the world: an examination into why recruiters are useless piles of humanflesh hellbent on destroying the souls of good designers and developers across the world. Too harsh? Most likely. But here’s the thing: recruiters do not give a fuck about doing good in the world. They do not care about making people happy. They do not care about building a good company. They do not care about treating email addresses as human beings. They only care about their percentage. Employees are the best recruiters At its core, the idea of a recruiter never made sense. Are they going to be working with their hire? Are they a designer, developer, copywriter or someone who knows what kind of skills and personality traits to look for? No. They’re salespeople. And I bet they’re great at hiring other salespeople. It just seems so obvious to me that employees make the best recruiters. Recruiters have nothing to gain from a good employee, but employees have everything to gain. If you consider yourself a manager, don’t you want to be responsible for building the team of people you’re going to manage? If you’re a developer, don’t you want to work with other great developers? How I hire people I happen to think I’ve become pretty good at recruiting over the years. We’ve built a pretty amazing team at GitHub, and I’d like to explain how I go about finding the next GitHubber. Friendship If you want to hire great designers and developers, you should be friends with them. Be interested in who they are and what they do. This is not rocket science. When you’re friends with someone you’ll notice when they’re frustrated with their job or know when they’re looking for something new. And even if they’re not looking for something new — maybe they have a (designer/developer) friend who is. Research Take time to look up potential hires online. If you’re hiring in the tech industry, they’re almost certain to have an internet presence. Look up their current job. See what they do. Take a look on dribbble, browse their code on GitHub — look at their work. More often than not, it’s completely unnecessary to interview for skills. You can find that out with a half hour online. Who knows, you might even find someone new to hire in the process. Research is the proper tool to understand whether someone has the skills to work for you. Grab a beer It’s vitally important that you sit down face to face and grab a beer with every potential hire. Or sit down for dinner. Smoke a joint. I don’t care what it is — you need to sit down in a relaxed environment and figure out what kind of person they are. Talk about their family, friends, hobbies, current job, dream job — anything you can think of. Some good things to figure out: Is this person a good human? Do they have a drive to build good things? Do they want to work on the things you want them to? Grabbing a beer will help you figure out if someone will fit in. Job boards, Twitter, and advertising I always try and use my personal connections to find potential hires first, but sometimes I come up empty handed. When that fails, you need to stretch out and get some new blood. There’s no shortage of Job boards out there: GitHub Jobs, Dribbble, 37Signals, Authentic Jobs — the list goes on. Pick a few and post some ads. Maybe sponsor a local meetup. But remember you’re posting an advertisement. This isn’t a fact sheet. Make that shit sexy. Make potential hires read it and think I want that job. Explain specifically what they’ll be doing day to day, what they’ll be responsible for, and who they’ll be working with. Explain what your co[...]

Mustache, ERB and the future of templating


There are days that I feel like I’ve spent the better part of my life inside templating languages. I’ve rocked hundreds of different styles of templates over the past 8 years. Smarty, vBulletin templates, generations of Wordpress, J2EE, XSLT, CFML, ERB, HAML, Mustache and every form of in-house bastardized template language that exists. So when I say that {{ mustache }} is my favorite templating language I’ve ever worked with, I mean it with a great deal of sincerity and experience. It’s syntactically elegant, focused on output (HTML), encourages documentation, and discourages unmaintainable magic. I want to use it everywhere. I mustache you, why mustache? (image) Mustache is more than a syntax. It’s a different approach to traditional templating — mustache templates have no logic. The template files themselves are HTML and mustaches:   {{#developers}}              {{/developers}}

{{ name }} ({{ github_username }})


{{ languages }}

{{ location }}
You cannot modify variables. You cannot apply filters. You can only output variables or a collection of variables. Everything else happens inside of a view. A view can be written in any language of your choosing: C, Objective-C, Ruby, Python, Javascript, etc. I’ll use Ruby since that’s what we use: module Jobs module Views class Developers < Layout def developers do |hit| name = hit["fullname"].empty? ? hit["username"].capitalize : hit["fullname"] { :name => name, :github_username => hit["username"], :location => hit["location"], :show_url => '/developers/' + hit["username"], :languages => hit["language"] } end end def developers_count @results.total_hits rescue 0 end end end end It’s just a good old Ruby class. Oh the wonder you can do with a class! Include modules, extend classes (such as that Layout class), and define any method you so desire. With any documentation your heart desires (something that’s missing from every templating strategy I’ve ever used). I thought I loved Mustache a year ago, but over time I’ve learned just how revolutionary separating templates from views is toward maintainability and collaboration. Anyone who knows HTML can edit Mustache templates. And all the magic that happens on the whole V side of MVC can be fully documented and separated into re-usable Ruby classes and modules. You want me to switch templating languages on my legacy app? For all this talk, the application I spend most of my time working on is still ERB. In fact, the rails app that powers GitHub has over 500 erb templates. We have dozens of people throwing hundreds of commits a day at the codebase in over 150 branches. Switching to Mustache would be a disaster requiring everyone to stop development, switch patterns, and introduce an unknown number of bugs to our customers. A shitty trade. I don’t want to stop new feature development, but I do want better templates. And I know that Mustache is the directi[...]

Brew Methods


A wonderfully simple site dedicated to the art and style of creating fine coffee. Learn how to use that Chemex properly!

Design Hacks for the Pragmatic Minded Video


The Ruby on Ales folks got around to publishing the video of my Design Hacks talk. The audio is a little weird in the begining, but hang on — it clears up a few minutes in.

Relentless Quality


If there’s one thing I’ll remember about Alex Mahernia, it’s footer spacing. Here we are at 10pm in the office and we’d be trying to launch a site. The only thing left is an A-OK from the creative director. And without fail, he’d yell at me to come into his office and point at his screen. “The footer spacing is too big on this page.” So I’d go back to battle the CSS until every single page on the site had consistent footer spacing in every browser. Motherfucking footer spacing. And what did it matter? Are our clients really going to lose customers because there’s an extra 10 pixels of footer spacing in IE6 on one of the pages? Is the client going to refuse payment because of these pixels? HOW MUCH BLOOD ARE THESE PIXELS WORTH? But it was never about the footer spacing. It was about quality. It was about cultivating a culture of relentless quality in everything we produced. Quality versus the Ego Every time Alex called me into his office and showed me a page with an extra 7 pixels of spacing my blood pressure went through the roof. I took it as a personal insult. But he wasn’t insulting me. It was about producing a quality product. Quality has no room for egos. Other people will have better solutions. You are going to miss things. You are going to break things. You are going to make mistakes. And people are going to point it out. And I think it’s okay to get upset. Take that feeling and turn it inwards. Vow to make things better. Make sure you’re always producing the best quality product you can. Move fast and break things If you take a look at any of Facebook’s recruiting marketing, you’ll see a phrase repeated over and over: Move fast and break things And with good reason — the idea it embodies is fantastic. Unfortunately I see a lot of people interpreting this quote as something like this: It reminds me of another misinterpretation that’s always bugged me: Quality isn’t something to be sacrificed. Move fast and break things, then move fast and fix it. Ship early, ship often, sacrificing features, never quality. Embrace change. Ship. Never cut corners. Quality is contagious Which reminds me of the broken windows theory: Monitoring and maintaining urban environments in a well-ordered condition may prevent further vandalism as well as an escalation into more serious crime. Broken windows are the reason most large software projects suck to work on. A little technical debt here, a few shortcuts there, and pretty soon you’ve got a codebase so full of broken windows that no one even cares if they throw another pile of broken glass on the heap. But just as broken windows are contagious, so is a dedication to quality. Carve out a little piece of a messy codebase and clean it up. Sharpen the edges, polish the surface and make it shine. The caveat here is that you can’t half-ass quality. Dedication to “semi-quality” isn’t dedication at all. High-end design coupled with mediocre engineering can only produce a mediocre result. And I don’t know about you, but I don’t dream of building mediocre. I dream of building the best. So I’m thankful to Alex for instilling this idea of relentless quality in me, even if I still have footer spacing related nightmares from time to time. [...]

Deploying: Then & Now


A couple months ago I got up on stage during lightening talks at CodeConf 2011 to talk about our friendly robot, Hubot.


Inside of five minutes I logged into our Campfire room with spotty WiFi, asked Hubot a favor, and he deployed a major new feature to our site — Issues 2.0. A deploy spanning around 30 servers that changed a major feature for 800,000 users. It was pretty awesome and kind of a ridiculous thing to do.

Rewind the clock 7 years ago and I had just landed my first steady job in the tech industry — a front end developer for a big interactive agency.

I remember one of our clients had a static HTML website that I was in charge of maintaining. We had a 45 minute window occurring once a week where we could deploy their site.

Once a week, I generated a list of files I’d changed since the last week so a System Administrator could FTP the files over to production. Any changes to production I needed that occurred outside that 45 minute window required manager intervention.

Recap time.


  • System Administrator time required to deploy every website.
  • Deploys scheduled by managers once a week.
  • Manually generating lists of changed files.
  • Simple deploys take 30+ minutes.


  • Deploying on stage for the hell of it.
  • System Administrator probably drinking whiskey.

2011 is pretty fucking awesome.

Deployment is an art. And the style in which you deploy impacts your company culture more than you think. Deploy with style.

Designing GitHub for Mac


A few days ago we lifted the curtains on a project I’ve been deep into for a long time now: GitHub for Mac. This is the first OS X app I’ve designed and thought it might be interesting to share some of the process and things I learned throughout development. Why should we build it? For a long time I assumed OS X developers would see the immense market for an awesome Git application. Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons. Clients claiming to be “simple” choose to redefine “simple” as fewer supported Git commands rather than simplifying the interaction with Git. It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home. Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub. And since we all use Macs — we should start off with an OS X application. Build what you know/use, expand from there. What are we building? Personally, I had some big goals: Death of the SSH key. People should be able to connect to GitHub with their GitHub username and password. Make it obvious that there is a distinction between remote and local. Make it clear what commits need to be pushed before others can see them. Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local. Fix the local/remote branching problem. Get rid of this tracking idea — interact with local or remote branches as if they were no distinction between the two. I didn’t want to replace the command line. I wanted to build an awesome version control client. As it happens, Git is the perfect backend to do that — and GitHub is the perfect central server to collaborate. Sketches & early ideas The first thing we did was to start populating an internal wiki full of ideas. Lots of words, lots of sketches. Incomprehensible pages from my Moleskine Scott created a bunch of mockups with Balsamiq Let’s get some designers on this I’d been using OS X for years, but I didn’t feel comfortable designing a native app. My previous attempts at OS X design weren’t too fantastic… In the end, we hired Eddie Wilson to come up with some wireframes and some comps while Joe and Josh cranked away at the Cocoa backend. His first comps were a great start, and influenced the end product tremendously. Unfortunately right about this time is when we learned how much we suck at working with contractors. We’re extremely opinionated, really bad at expressing our opinions, and change our minds all the time. We asked Eddie to hold off while we re-grouped and figured out what we wanted from the app. We sat down and had a lot of discussions about how we wanted this thing to work. Brandon Walkin helped out quite a bit, and even sketched up some wireframes & notes for us. Eventually we figured out what we wanted to design — but now we didn’t have anyone to design it. Eddie had since taken up other work and pretty much every Cocoa designer on the planet was inundated with work. In the end, I decided that GitHub for Mac was the thing I wanted out of GitHu[...]

Excellent embedding markup


I was playing around with Twitter’s new Follow Button and I couldn’t help but notice that the embedding markup is some of the best I’ve ever seen.

I love the idea of using regular HTML with feature-flags in data attributes combined with a common script. Can’t wait to play around with this style on Gist.

Build your business around an idea


Living in San Francisco and working in tech right now is absolutely insane. Employers and recruiters battle for employees while VCs rain down millions of dollars without meeting founders or even knowing what kind of company they’re building. It’s a crazy world to live in and can feel like money is growing on trees and the only spending limit is your imagination. If you have just a little bit of initiative, you can take any idea and start a company with absolutely zero personal risk. And that’s one of the biggest reasons San Francisco is so special to me. Everyone out here knows they can do anything. Spend a few weeks hanging out in bars and cafes asking what people do and you’ll hear some of the most idiotic business ideas in the world. A lot of journalists use this argument to call San Francisco an echo chamber whose sole purpose is burning money. And you know, they’re right. This city does burn through money on terrible ideas. But that’s a tradeoff for fostering a city of people who believe they can do anything. And that spawns an incredible number of amazing companies — so it doesn’t bother me. What does bother me is the lack of imagination most startup founders have. Build something incredible Most founders I talk to are pretty complacent building something mediocre. They won’t admit if you flat out ask them — but try pressing them to describe what makes their company special. Most cop out and give you an answer like: We’re building [technology x] because [company y] hasn’t built it and [people z] need it. Want a more concrete example? How about something like: We’re building a cloud sync solution for iOS because Apple hasn’t built it and almost every iOS application needs sync. There are thousands of people building products like this. They’re filling holes. Filling holes is mediocre and boring. Dare to build something incredible – something unique, something lasting, something special. Ideas are lasting, products are not The easiest way to build something incredible is to base your business around an idea. Products are just the manifestation of the idea. This is something I think about at GitHub a lot. We’ve built an amazing product ( — but when you ask us what the company is about we say: We make it easier to collaborate with others and share your projects with the universe. There’s a lot of interesting things you don’t see it that description: Git, version control, issue tracking, wikis, or website. We know that our product (a website hosting git repositories with built-in issue tracking & wikis) is great — but if it doesn’t serve a higher purpose, it would be mediocre. So we focus on the idea. That means looking at version control, wikis, and issue tracking as tools for collaboration. It means that as important as it is for our website to be easy to use — it’s equally important for Git to be easy to use. Or to create tools that let people use Git without even knowing they’re using Git. If I look into the future, I know that the idea of collaboration is lasting — but Git? That’s a hard bet to make. I know that if we focus our business on collaboration we can build something lasting. If we focus our business on being a Git host we’re doomed. Ideas are sexy One of the more awesome things about building your business around an idea is how easy it is to pitch to others. Ideas are sexy and draw people in — they invite passion and commitment. And pitchi[...]

Infinite Scroll + HTML5 History API


Something I’ve been meaning to do for a while — here’s a little experiment using the HTML5 History API and infinite scrolling to kill off “next page” links and still maintain real URLs that persist across page views.

In my perfect world, this is how Twitter, Facebook and Tumblr’s infinite scrolling would work.

Product design at GitHub


Product design is easily the hardest aspect of building software today. Technology, hiring, funding, aesthetic design, and press are all minuscule in comparison. When I talk about product design I’m referring to the process by which you decide what your product does and does not do. I happen to think we do a pretty good job of this at GitHub, and I’d like to give you a bit of an insight into our process and hopefully shed some light on why it works so well. I should warn you that I am not a “Product Designer.” We don’t have titles at GitHub — we let employees pick their own. I like to call myself ~designer since I mostly focus on the look & feel of our product. But then again, I spent the past weekend building an application to track & distribute binaries and updating some of our reducing functions to support a newer version of MongoDB. So, yeah. I’m ~designer. But maybe that leads me to my next point… Everyone is a product designer Every employee at GitHub is a product designer. We only hire smart people we trust to make our product better. We don’t have managers dictating what to work on. We don’t require executive signoff to ship features. Executives, system administrators, developers, and designers concieve, ship, and remove features alike. Having the role of “Product Designer” or having a CEO who says they’re going to “focus on product design now” never made much sense to me. Aren’t you hiring smart people who use your product? Don’t you trust your employees? Doesn’t everyone at your company want to make your product better? Doesn’t that make everyone product designers all of the time? Along these lines, my two favorite questions to ask in an interview (or to people who don’t know they’re interviewing) are: What would you like to see in GitHub? What feature do you think we messed up / should remove? It brings out the passion in people and instantly highlights problems you might have with their decisions. Some people just don’t have the same vision for your product as you do, and that’s fine. Write down ideas like crazy Our internal wiki is filled with ideas. Old ideas. Bad ideas. Good ideas. Half-baked ideas. The point is that we have a place to share our crazy with each other. This wiki page discussing compare view eventually became Pull Requests 2.0 — arguably the best code review tool I’ve ever used. Most of the time when someone adds an idea it’s nothing original. It’s something we’ve discussed in person, seen in another product, or maybe thought about ourselves. But that’s really half the point — seeing someone else write down the same idea you’ve had makes you twice as excited about the idea. As others chime in saying they’d love to see the feature, excitement about it grows and grows. Eventually you’ve got 4 developers hacking on something at 11:30pm because they want to see it happen so badly. Constantly experiment and iterate Right now our main repository has 65 branches. This doesn’t count the dozen or so other repositories that collectively represent what is or the 139 repositories under our organization. Needless to say, there are a ton of features, anti-features and half ideas in these branches. Sometimes they’re really pretty features that aren’t functional and sometimes they’re really ugly features that are completely functional. We’re always sending pull request[...]

Design hacks for the pragmatic minded


Slides and references links from my presentation I gave at Ruby on Ales - Design hacks for the pragmatic minded.

Documentation is freaking awesome


Slides and references links from my presentation I gave at Magic Ruby - Documentation is freaking awesome. Check it out if you’re curious.

Speaking at Magic Ruby


I’ll be giving a talk about documentation (no, not just code comments and RDoc) at Magic Ruby February 4th-5th. Oh, did I mention it’s in Disneyworld? And it’s free?

URL Design


You should take time to design your URL structure. If there’s one thing I hope you remember after reading this article it’s to take time to design your URL structure. Don’t leave it up to your framework. Don’t leave it up to chance. Think about it and craft an experience. URL Design is a complex subject. I can’t say there are any “right” solutions — it’s much like the rest of design. There’s good URL design, there’s bad URL design, and there’s everything in between — it’s subjective. But that doesn’t mean there aren’t best practices for creating great URLs. I hope to impress upon you some best practices in URL design I’ve learned over the years and explain why I think new HTML5 javascript history APIs are so exciting to work with. Why you need to be designing your URLs The URL bar has become a main attraction of modern browsers. And it’s not just a simple URL bar anymore — you can type partial URLs and browsers use dark magic to seemingly conjure up exactly the full URL you were looking for. When I type in resque issues into my URL bar, the first result is URLs are universal. They work in Firefox, Chrome, Safari, Internet Explorer, cURL, wget, your iPhone, Android and even written down on sticky notes. They are the one universal syntax of the web. Don’t take that for granted. Any regular semi-technical user of your site should be able to navigate 90% of your app based off memory of the URL structure. In order to achieve this, your URLs will need to be pragmatic. Almost like they were a math equation — many simple rules combined in a strategic fashion to get to the page they want. Top level sections are gold The most valuable aspect of any URL is what lies at the top level section. In my opinion, it should be the first discussion of any startup directly after the idea is solidified. Long before any technology discussion. Long before any code is written. This is top-level section is going to change the fundamentals of how your site functions. Do I seem dramatic? It may seem that way — but come 1,000,000 users later think about how big of an impact it will be. Think about how big of a deal Facebook’s rollout of usernames was. Available URLs are a lot like real estate and the top level section is the best property out there. Another quick tip — whenever you’re building a new site, think about blacklisting a set of vanity URLs (and maybe learn a little bit about bad URL design from Quora’s URLs). Namespacing is a great tool to expand URLs Namespaces can be a great way to build up a pragmatic URL structure that’s easy to remember with continued usage. What do I mean by a namespace? I mean a portion of a URL that dictates unique content. An example: In the URL above, defunkt/resque is the namespace. Why is this useful? Because anything after that URL suddenly becomes a new top level section. So you can go to any / and then tack on /issues or maybe /wiki and get the same page, but under a different namespace. Keep that namespace clean. Don’t start throwing some content under /feature// and some under ///feature. For a namespace to be effective it has to be universal. Querystrings [...]

My TextMate Snippets & Triggers


A while ago I put up a collection of some of my handcrafted TextMate snippets. mostly focused on front-end stuff: HTML shortcuts, CSS gradients, jQuery plugin bases, commenting helpers, etc.

The Geek Talk Interview


A quick interview I did over at The Geek Talk. Mostly covering my daily routine and whatnot.

RSS Feeds for Warpspire


I was going to try and fix some bugs in GitHub Pages (that’s how this site is hosted) — but I think I’m going to give up that fight. If you’d like to subscribe to Warpspire, you can find the feeds at

Rethinking Warpspire


I think it’s always a good idea to take a step back and ask yourself why you’re doing something. So right now I’m taking a step back to rethink Warpspire. Getting rid of cruft The other day I followed a link to a blog post on Mint. I was presented with this screen: I hate what most designers have done to the web. You’d think people would be taking cues from things like Readability and Safari Reader, but they’re not. People are throwing more and more crap onto each page and making things harder and harder to read. Anyways, it got me to thinking about sites that I continue to enjoy reading in the browser. One site that immediately came to mind is Daring Fireball. The format and presentation has lasted for years without feeling tired or hard to read. So it should come as no suprise that this new layout mirrors DF in a great number of ways. (Alas, my logo features the same unicode character as DF — something which has now turned from a funny coincidence to a long boring story. I hate logos.) This new layout is the simplest layout I’ve ever had on one of my sites. The goal was to create a focused place for my ideas. Abandoning old baggage There was a lot of crap on Warpspire. WordPress tells me the first post was published August 15, 2004. That’s six years ago. To say that the web is a different place now is an understatement. I remember debugging that initial site on IE5 for Mac. Six years ago, I was in my 2nd year of studying Civil Engineering at Cal Poly. I had no concept of the value of the web or how important it would be come. I was also twenty years old, angsty and wrong about many things. So I deleted most of my posts. What’s left? The most popular posts (traffic wise) along with a couple of ones that I particularly enjoyed and still felt relevant. I’ve also edited them all, and rewritten some. Almost certainly a bad idea for my traffic, but probably a good idea for my readership. And I’ll value readers over pageviews any day. On the subject of comments The thing about comments is that commentors tend to be a bunch of crazies wandering the internet like it’s a zombie apocolypse. It’s a striking contrast to the rational human beings whom I have sensible arguments with here in the meatspace. The thing is, I’ve met some of the smartest people on the planet through my site and I don’t want to lose that. So here’s the deal: you send me email, and I send you one back. If I think others might be interested in what you have to say, I’ll post it here on Warpspire. A comment should mean something to you and it should mean something to me. Typical blog comments just stopped meaning anything to me a long time ago and that sucks. So I’m hoping this is a move toward fixing that. [...]

What's your focus?


Every great website has a focus. If you can’t summarize the purpose of your website into one sentence, ten words or less – your idea will almost certainly fail. Talking to founders, I’d say this idea is pretty well established. Now let me reveal a secret that is not so well established: your website’s design should follow this same focus. Learn by example: source hosting sites Let’s start off with a field I’m pretty familiar with: source hosting sites. I’m talking about GitHub, BitBucket, SourceForge, Google Code, Launchpad and the likes. These sites all have a common focus: sharing code. I’m going to show you why GitHub is the only site who’s design follows it’s focus. If your site’s focus is sharing code, the design should focus on sharing code. If you ever talk to any of us GitHubbers, we’ll always say that the site is all about the code. Let’s look at project landing pages in each of the above sites. GitHub When you visit a GitHub project page, the first thing you see is the source code. Right below is the README pulled straight from the code. BitBucket BitBucket chose to highlight the shortlog (recent commits) on the project page. If you want to see the code, you need to go to the 3rd tab. SourceForge Sourceforge chose to highlight downloads (in this case, a compiled jar file — not the code) on the project page. If you want to see the code, you need to click Develop, and then fish around in the sidebar for the correct VCS and click browse. Google Code Google Code chose to highlight the wiki on the project page. Getting to the code in Google Code is probably the most interesting of the bunch because many projects don’t even host their code there (example: redis). When you click the Source tab you actually get a wiki page which many projects use to point to another repository. If the project hosts it’s code there, there is a sub link under Source that is labeled Browse that you can finally see the code. Launchpad Launchpad decided to highlight everything but the source code on the project page. If you want to see the code, there is a tiny link in the middle of the page that says ’View the branch content.’ Great examples from other fields Source code hosting is just something that I’m extremely involved with. That doesn’t mean that focus is limited to code. Flickr Flickr is all about sharing photos. Facebook Facebook is all about connecting with your friends. Daring Fireball Daring Fireball is all about John Gruber’s writing. Sites that have lost their focus There is a huge genre of sites that seem to have completely forgotten their focus. I’ll see if you can guess the genre. MSNBC NYTimes Rolling Stone It’s no wonder news sites can’t get people to pay for their content. You need to focus on your content to get people to pay for it. Charging for your focus Many sites don’t want to give away their focus for free. That’s perfectly fine. But it doesn’t change a thing. Replace what people are going to pay for with an opportunity to pay you. PeepCode’s focus is great tutorials. But the tutorial is not the focus of the product page — instead a t[...]

Optimizing asset bundling and serving with Rails


I wrote up a pretty lengthy post over at the GitHub blog explaining how we do asset bundling and serving. Well worth the read for anyone who’s interested in front end performance and works on ruby apps.

It's not about how many hours you work


My favorite discussion amongst web professionals is when people start talking about work/life balance and how many hours they’re working. There’s been no end of interesting ideas to pop out from this – everything from 4 hour work weeks to 100 hour work weeks. And everyone thinks that they’ve got the answer. But I think everyone’s just arguing about an irrelevant metric: the hour. Let’s talk about that work/life balance thing Most of this discussion always seem to revolve around the idea of a work/life balance. The basic idea is to keep yourself sane. Don’t abandon your real life for your work. That makes sense, until people start attaching hours to it. I’ve had discussions with people where they try and argue to me that 40 hour work weeks keep them balanced. But I have to wonder, where does that magical number 40 come from? The fallacy here is that people are thinking in black and white terms of “work” and “life.” I never really understood that, and I think I’ve gotten to a point in my life where I can see why: it’s a bunch of bullshit that employers made up to promote 40 hour work weeks. If you really think that there is a certain number of hours you can work a week to balance your life, you’re doing it wrong. So let’s ditch this idea of a work/life balance, because it just doesn’t make sense. It’s about creating a creative environment in your life It’s just that simple. If you’re in the creative field, you need to make sure your life promotes a creative environment. There isn’t one catch-all formula to do this. There isn’t a number of hours you need to work. You just need to experiment and find out what works for you. What I will do is try and offer some advice. Find your passion in life and try to make money from it If you hate your job, it’s unlikely that you’ll be successful in fostering a creative environment. Try your best to fix this. Find out what you’re good at, and try to make money from it. You’ll be producing better (more valuable) work and enjoying life more. Explore projects that are explicitly not for profit Money taints things, there is no denying this. So I suggest to find an outlet that you purposefully can’t/don’t make money from to help exercise your brain. That might mean creating websites, making music, or hacking on an epic perl script that no one but yourself will use. It doesn’t have to be something different from your work – it just has to be separated from your work. Something you can change or destroy without worrying about what others think. Stop working if you’re producing crap The only thing worse than being unproductive at work is forcing false productivity. If you find yourself at your desk and you can’t come up with anything useful, just stop trying. Leave your desk and go do something else. Maybe for a few hours, maybe for a week, maybe for a year. Accept that there is no way you can be productive for 40 hours a week The 40 hour work week is completely unsustainable. Human beings are not meant to sit down and really focus for 40 hours a week, 50 weeks a year. Our brains can[...]

Joining GitHub


I still feel like it was last week I decided to give up my “safe” job at Web Associates Level Studios to play around with the ENTP crew. Well, it’s time for another move. Last week I was given an offer I just couldn’t refuse–to join the amazing GitHub team (my GitHub profile). For those of you who don’t know who GitHub is: shame on you. GitHub has taken something as boring as source control and made it something that brings people together. Social coding, indeed. A brief look at the past couple years The past couple of years have been a crazy blur of projects for me. Most of what I did for ENTP was for [redacted], so you won’t be seeing most of what I did, but I thought I’d spend a few minutes to archive (for my own good) some of the public-facing projects I completed. Tender By in large, the biggest project I worked on ENTP was Tender – and I’ll be honest, it’s going to hurt to let this go. Tender was my baby, and I did all of the IA, design and front-end work for the site as well as some marketing and analytical work. The shining side of that tunnel is that of course GitHub uses Tender for their support, so I’ll at least get to use it and see how ENTP shapes the product. Lighthouse iPhone Designing an iPhone optimized interface was one of my first projects at ENTP. It doesn’t benefit from any of the OS 2.0+ features (HTML5, CSS Animations, Etc) since the code was created before these came along, but it gets the job done. It was a great exploration in turning a complicated interface and trimming it down to the bare essentials. I designed this in collaboration with Justin Palmer when ENTP decided they needed a new site. It’s got a few interesting features (like pulling in our current GitHub projects on demand in the footer), but it’s mostly just a brochure site for the agency. Hoth Hoth is ENTP’s blog. This design accompanied the new design and added in a bit of tumble-like functionality to the templates. On to the next chapter So now I enter the third dream job I’ve had in the 4 years since I graduated college (none of which have been slightly related to my degree). I’ll be diving into a design/front-end role for the team and help clean up and take the product to the next level. I’ll see ya’ll at the next GitHub drinkup. [...]

Installable apps


I’m getting kind of tired of all these web developers complaining about the time it takes to get updates to their apps up on the iTunes App Store. The truth is this complaining has some merit. But you have to realize that these people are not making web applications, they’re making installable applications. The problem is not Apple. The problem is lack of QA testing. Your application will have many bugs The first rule of development: your code is going to have a lot of bugs. I don’t care if you’ve got 3 days experience or 30 years experience in the industry. Your code will have bugs. This isn’t a pride issue, it’s a fact of life. Good developers know this and rely on testing (code, user-acceptance, performance) to expose bugs so they can fix them. Bugs will appear after your code is deployed Whether it’s the Y2k bug, deprecation of a technology, or your application getting blacklisted from a web service – some bugs are going to show up after your code is deployed. This is something you should expect. Again, this is not negotiable. It is going to happen. The web makes us lazy The truth is, developing web applications makes us lazy. I can fix a bug, deploy, and it’s fixed in about 15 seconds. This is why I love working on hosted web applications. You’ve got such immense power over the deployment process. Some things that rock about web apps: You can be really lazy with UAT (User Acceptance Testing). Users will do your UAT for your and you can fix it on the fly. You can be really lazy with bugs that will appear after deploy. If a web service changes, you fix it and redeploy. Done. You only need one computer to test your application. No need to purchase multiple hardware platforms, video cards, or install multiple operating systems! You can’t be lazy with installable applications I once worked on a desktop application that was being sent out on millions of machines. This application was going to be the first thing that started up when the user booted the machine. It also meant we didn’t have the option to issue updates for the application after deployment. We spent tons of time doing user testing on dozens of machines. And then the client did user testing. And then the client’s QA department did even more testing. And then the client’s QA department did more testing throughout the whole time they were writing hard drives. Remember the days when you updated applications with CDs or floppy disks? My god, for a while there it just wasn’t feasible to update installable applications over the internet. The end result? Software development firms spent a lot of time and money on QA. Same goes for game development companies. My point is: if you know that one of your restraints is updating can be slow or impossible, you spend more time testing the application. The App Store is slow It’s true the App Store is slow when it comes to delivering updates. To me, this is just a known variable. Wouldn’t it be awesome if they had 24 hour turnaround? Sure would be. But it’s one of those tradeoffs you[...]

Xcode window management sucks


Hi, did you come here to tell me that Xcode offers "all-in-one" editing? Please, don't send me an email. This is addressed in this article if you take time to read it. I posted some thoughts to twitter last night about how much the Xcode window management drives me insane. What I got back was a huge reaction of “it’s perfect” and “this is how OSX works” Suddenly I was wondering, am I just insane for thinking the window management is absolutely horrible? No, no. I’m not. It’s horrible. Just because Apple built it, does not make it perfect. Tabs are the future (actually it’s been the standard for years) Tabs have clearly proven themselves to be a superior method for editing multiple code files. Why? Because the most recognizable thing about code file is it’s filename. Not the look of the text. Let’s look at this through some examples. Case #1: Window-based management FTW, Photoshop Example of window management in Photoshop Window management in OSX defaults to a new window for each document. This works wonderfully for most applications when you can see the differences visually. Photoshop is a great example. Using Exposé, I can see which document I mean to be working on at a glance The visual representation of the document is the unique identifier. Some more points on why this works so well: Image documents are the only windows you will ever see in Photoshop. Everything else is a panel. This functionality is the same for all five-star document-based apps. iWork, iLife, etc. There is a really good reason Apple chose to hide panels when activating Exposé. Photoshop is a document immersive program. It’s unlikely you’ll be working on more than one PSD at a time. The document is all that matters. Conversely with code, the project is all that matters (not one code file). Case #2: Tab-based management FTW, Texmtate Example of window management in Texmate Window management for Textmate is handled via tabs and a persistent sidebar. At a glance, you can see all files you’re currently working on. In the case of Cocoa, you are often switching between interface & implementation files, but this is easily handled via cmd-opt-up, so long as you have the name of the class right, you’ve got the right file. Some points on why this works so well: Windows provide a way to group files in a meaningful manner. Each window is a unique project. Remember, the project is the important thing – when coding in Cocoa, you’ll need to edit multiple files at once to make them work with one another. I can quickly move between individual files via the keyboard. Considering coding is almost purely typing, keeping my hands on the keyboard is killer. Case #3: WTF-based management FTL, Xcode Example of window management in Xcode Window management for Xcode is handled via a combination of this thing called a Project window, which morphs depending on it’s toolbar state, windows for each document, and windows for ancillary programs (like the model editor). Please note I ha[...]

Top reasons your CSS columns are messed up


I believe the recent surge in popularity of CSS frameworks comes from a lack of basic understanding of the CSS box model and how it’s implemented across browsers. I wanted to share with you some quick tips on how to avoid easy pitfalls so you can create your own CSS framework in no time flat, without all the cruft of having ten thousand column combinations available. Keeping these quick tips in mind at all times will allow you to do something I like to call defensive coding – and really that’s all CSS frameworks are: defensively coded snippets of CSS. Your margins are doubled in IE6 Here’s a super common pitfall: IE6 will double margins facing the direction of the float. Example problematic code: .sidebar{ float:left; margin-left:20px; } This sidebar will have a 40px left margin in IE6 – almost certainly throwing the sidebar down below the content, and not next to the content as it should be. Easy fix: add display:inline; No side effects in any browser, and IE6 obeys margins perfectly. .sidebar{ float:left; margin-left:20px; display:inline } Why it works: By declaring float on an element, you implicitly demand that it must be rendered as a block element – thus rendering the display:inline inert. However, due to IE6’s awesome CSS engine, it fixes a bizarre bug that is the #2 reason I see CSS columns fail in IE6. Your content is wider than your column Let’s pretend you’ve got this simplistic setup of code: .columns{ width:500px; } .columns .main{ float:left; width:400px; } .columns .sidebar{ float:right; width:100px; } HTML: ...
... Harmless right? You might view this in Firefox and everything will be fine. But then you look at it in IE6 and your sidebar has mysteriously dissapeared below .main. WTF? You look at the HTML, the CSS, and everything’s fine. What could possibly be wrong? A common problem here is if awesome.gif is 510px wide. What this does is push out .main to 510px, and suddenly there’s not enough room for .sidebar inside .columns any longer. Ack! Easy fix: add overflow:hidden to your columns. This forces the width restriction to crop any extruding content. New magical CSS: .columns{ width:500px; } .columns .main{ float:left; width:400px; overflow:hidden; } .columns .sidebar{ float:right width:100px; overflow:hidden; } Your margins extend past your container So you’re building out a simple product listing template out, and you throw it in an unordered list: ul.listing{ margin:0; width:400px; } ul.listing li{ list-style-type:none; float:left; margin:0 20px 0 0; width:85px; } HTML: ...
  • Product #1
  • Product #2&l[...]

Why I don't use CSS Frameworks


CSS Frameworks seem like an awesome advancement at first glance: speed up your development, normalize your code base, and eliminate those nasty browser bugs! Hot damn, where do I sign up? Unfortunately there’s some pretty strong caveats that go with those statements. The frameworks themselves are very good I’d like to start this off by saying there’s nothing inheritly wrong with any of the CSS, HTML, or ideas put into these frameworks. I also think it’s an absolutely fabulous idea that people are writing them – it gives newcomers an easy way out to create professional looking designs using semantic XHTML and CSS. Advantages of Frameworks Most CSS frameworks offer three primary selling points: Speed up your develoment (don’t have to write all that HTML/CSS) Don’t worry about those nasty IE bugs! Normalize your code/class base Speeding up your development For those who have intimate knowledge of the framework, I do believe the frameworks will speed up development. But for the average user, I think that the time required to understand the architecture of the framework far outweighs the menial task of coding it from scratch. Over the past three years, I’ve built unknown dozens of layouts, with most of them being extremely visually complex. On average, it takes me about 8 hours to build out a Master design into a functioning bug-free template. Of that time, I would have to say that doing the basic layout & typography (framework material) takes less than 20 minutes. That’s less than 5% of development time. You may save time, but the question quickly becomes how much time, and at what cost? We’ll cover that later. My point being that frameworks do not solve the hard problems in CSS – the ones that pop up when you’re knee-deep in HTML and suddenly the goddamn box doesn’t show up in IE6. These are the problems that take the majority of time when developing a website. Don’t worry about IE bugs Well, gee that sure would be a wonderful thing if that were the case, wouldn’t it? The truth is the frameworks do eliminate some bugs – but they’re the easy ones to pick off. The ones solved by a quick display:inline or height:1%. The frameworks don’t solve bugs where none of the public hacks work. Or where IE inexplicably adds a 30px top margin to your element, but then dissolves in when you hover over your main navigation. It doesn’t solve the problems when IE displays the same HTML and CSS differently on two different computers. It doesn’t solve the hard problems. Normalize your code base This is one area I think frameworks are great at: getting a large team of people all using the same code structure. But then again, I think this can be solved by an internal styleguide just the same. Disadvantages of frameworks There are a few pretty severe disadvantages of frameworks in my eyes: Familiarity with your code’s architecture Inheriting someone else’s bugs Not learning Familiarity with your code’s a[...]

MooTools Javascript Classes


One of Javascript’s major blunders when it comes to Object-Oriented design is the lack of true classes. Lucky for us, we’ve had every library author out there have their whack at creating a class structure. What is a class? A class is kind of a template. One of the big concepts of OO is treating your code as real world objects. Let’s say you want to have three variables for different dogs: ollie, rowdy, and killer. Each of these variables should be an instance of a class. That class’s name would be Dog. Each particular dog is an instance of the generic Dog class. I won’t go into much more detail here: there’s plenty of reading to do on what classes really are, and how to use them best. MooTools = <3 Out of all the class systems I’ve used, I’d have to say MooTool’s class system (spanwed from Dean Edward’s Base) is the cleanest, most extensible system yet. Creating and extending classes is ridiculously easy. Create a class var Animal = new Class({ initialize: function(){ this.text = "Animal Runs!"; }, run: function(){ alert(this.text); } }); var pet = new Animal();; // ==> "Animal Runs!" (It’s also fair to note that MooTools supports Prototype’s Class.create method as well) Extend a class var Dog = Animal.extend({ initialize: function(){ this.parent(); }, bark: function(){; alert("Woof! Woof!") } }); var pet = new Dog(); pet.bark(); // ==> "Animal Runs!" // ==> "Woof! Woof!" You’ll notice you still get access to parent methods (through this.parent()), as you can see where this.text gets initialized when a new instance of Dog is created. The syntax is short, sweet, and to the point. Furthermore it allows me all the flexibility I need… well, almost. MooTools team gets bonus points for the next section. Javascript mixins… kinda There are two common actions that many Javascript actions have: options, and callbacks. MooTools have created a sort of ruby-style mixin for classes to handle these functions. MooTools calls these mixins Utility Classes. To enable these, add this line to the code above: Dog.implement(new Options, new Events); Options What does this do? First off, it allows for quick, easy, extendible options. All you do is set your default options in an options property, and then call the setOptions method inside your class. Here’s an example: var Dog = new Class({ options: { age: 5, type: "Jack Russel Terrier" }, initialize: function(name, options){ // Here's the magic! this.setOptions(options) = name; }, bark: function(){ alert("My name is " + + " and I am " + this.options.age + " years old"); this.fireEvent('afterBark', this); } }); Dog.implement(new Options, new Events); var ollie = new Dog('Ollie'); ollie.bark(); // ==> "My name is Ollie and I am 5 years old" var rowdy = new Dog('Rowdy', {age:15}); rowdy.bark(); // ==> "My name is Rowdy and I am 15 years old" By mixing in the O[...]

Using TextMate's TODO bundle


If you use TextMate, you should really think about using the TODO bundle more often. It’s a simple, low-maintenance bundle that adds tremendous value to your code. Setting TODO, FIXME, and CHANGELOG Using the bundle is pretty easy. In any language, just type in a quick comment with the prefix TODO, FIXME or CHANGED like so: def view # TODO: different display for different types of clips: active, processing, etc @clip = Clip.find(params[:id]) # TODO: Make a real related clips dealieo @related_clips = Clip.find(:all, :limit => 6, :conditions => ["clips.status = 'processed'"]) end Using this syntax lets you keep pushing ahead at full steam and leave the hard stuff for later. For example, in the above example I wanted to get a quick functional prototype out the door. It wasn’t mandatory that the Related Clips actually be related: it was only mandatory that there was content present. You can also use the keywords FIXME or CHANGED throughout your code, like so: def view # FIXME: This totally breaks if an invalid ID is given @clip = Clip.find(params[:id]) # CHANGED: @related_clips now uses a model method related_clips @related_clips = Clip.related_clips(params[:id]) end This lets others working on the code let you know that you know something is broken and/or changed, but you just don’t have time to get to it. Getting the information back Well, that’s all fine and well.. but how do you know what needs to be fixed/changed/done ? Just hit Ctr+Shift+T and TextMate will pop up with a pretty little list, hyperlinked and all Ctrl + Shift + T brings up a list of all your todo's I use this bundle practically every time I open up Textmate. It allows me to keep on a focused track of development, while still keeping a lot of “ooh, I need to do that sometime” kind of tasks on the radar. [...]

Predictions for the future


I thought it might be fun to say where I think the web, technology, and music are going in the next few years. I really feel 2006 is going to be some kind of renaissance for technology as a whole. As this whole ‘Web 2.0′ craze dies down, the ideas inherit in the movement will spread elsewhere. 2006 is going to be big. Web standards what? People will finally stop caring about web standards. It’s just how you make websites, plain as that. I think this actually happened last year in the professional world–but the amateurs are close to follow. People will finally stop becoming standards evangelists and realize they’re designing web sites. Not just building them. And that, the surface is in fact more important than the foundation. Automattic will change the shape of blogging I see an extremely bright future for Automattic. With a guy like Matt at the reigns great things are bound to come out. Change the face of blogging? Hell yea. How? I don’t know — and that’s why it’s going to be so big. I’m sure these guys have at least one more killer idea in the oven just waiting to come out. Many people may balk at that statement and wonder what reasoning I have for it. Matt is, in my opinion, the largest contributor to what blogging is today. He’s done more towards creating a community than anyone else out there. He’s got the idea. He’s got the people. He’s got the means. Akismet works. Akismet is pure genius. Well, maybe not pure genius (as the idea is nothing but new). However, it works. It works damn well. Those using the heaven known as Akismet don’t know what comment spam is anymore. That’s how good it is. (Remember, Akismet = Automattic) works. is a great service, like blogger but infinitely better. This thing is taking off like no one could imagine. It’s going to continue to take off and gain influence. Automattic are the people behind Automattic and Wordpress will drive the internet in 2006. What this also means is that Symphony and its army of clones will not be the biggest thing to hit web publishing since the keyboard. Hosted applications will rise I don’t think that 2006 will see the decline of hosted applications. Perhaps ‘07, ‘08 we’ll see them crash back down. This year, we’re going to see more dynamic web sites out there than you ever thought possible. Social this, tagging that. But I don’t think this trend will last long. Soon people will realize that they really don’t care about tagging and discussing their sex life and will stop using these services. Shortly after, the services will fail and start to thin out to a few select sites that are actually useful–like Basecamp. Vista won’t matter Windows Vista won’t launch in 2006. The whole world won’t care. Slowly the average computer users are leaning towards OSX. As the iMacs and Mac Minis start invading re[...]