Quite possibly, the single most important action undertaken by Tim Cook as CEO of Apple was when he fired Scott Forstall. There were likely many reasons for this move, but the overarching one is well-documented: Cook demands collaboration – and Forstall was not known to share the glory nor the information. Cook would have none of it. He wants the company  free of politics, fully focused on its mission, everyone working together.

At Apple, mission trumps everything. At Apple, mission trumps diversity. This is why the company succeeds so famously.

While many may insist there are corporate benefits to a diverse workforce – both in quantifiable and qualitative terms – the fact is that Apple, most valued, most successful tech company in the world proves this wrong.

Apple shows us that to do the very best work, to make the very best products, to create something out of  nothing that magically appeals to everyone requires not a diversity of thought or viewpoints or race or gender. Rather, great people with a singular cause, a focused leadership, and unwavering faith in what they are doing.

Apple was founded by two white American males. In its fifth decade of existence, it remains run by mostly white American males.  Yet, it succeeds – famously so.

Apple Executive Leadership Team

Could the company really do better if the picture above looked more representative of American society?

Already, Apple is the world’s richest tech company. It has amassed the most cash. It makes the very best smartphone, tablet and laptop in the world. It is the global leader in personal computing. The company has over half a billion users and is growing, particularly in developing markets.

It is also a global digital media conglomerate.

Would it be any more so if Apple’s leadership was, say, half women and/or 25% people of color? Would their products be any better? More appealing?

Is there a better person – man or woman – to run Apple right now? Certainly, Steve Jobs had the vision. It is Tim Cook, however, who clearly possesses the skills to transform Apple into a global empire.

Might Apple be better served if, in developing its products, it brought in a true, diverse cross-section of America to test and advise? Nonsense.

Diversity justly celebrates our differences. But differences can get in the way of purpose. Cook understands this. It is why he has repeatedly talked about the value of collaboration. He wants people with similar views and habits, committed to the same larger mission.

Too often we hear from various parties who insist that “tech companies” or “Silicon Valley” has a race problem, a gender problem, a diversity problem. This is backwards. The companies that succeed in Silicon Valley are typically highly focused, comprised of people of highly similar backgrounds and educations – all focused on a singular mission. The last great Silicon Valley success story, Facebook, came straight out of a Harvard dorm – chock full of well-to-do white males. It’s nearly impossible to be less representative of American society than that.

There are good reasons why so many of us believe there are societal benefits to diversity and inclusion, of course. Likely, everyone of us benefits – culturally and economically – when everyone’s talents, creativity and dreams are afforded the opportunities to be fully realized.

But such larger social benefits simply fail to pass the results test when it comes to individual company success. Venture capitalists certainly aren’t going to fund a start-up or an idea because it flows from a “diverse” group of people.

Should Apple hire women to help it better understand a “woman’s market” for iPhones? Apple’s products are deliberately designed to be universal. And they succeed at this.

Attempting to argue the merits of diversity – at the company or even the funding levels – invariably misses the mark. Making Apple more diverse will not make it better. Walk into any Apple Store today and see young and old, black and white, male and female all testing, using – coveting – the company’s many amazing devices. Apple’s success proves once and for all that mission – not loose, feel-good terms like diversity – are what drives corporate greatness.

No, this does not mean we should not have nor promote diversity. But for those leading the diversity charge, they need to show, specifically, how inclusion will directly benefit a particular company, for example, or increase a VC’s potential return. If they can’t, then their efforts must be shifted elsewhere.

If Steve Jobs left the business world a grand legacy it is thus: mission trumps diversity. Apple continues to bear this out.

Yesterday at CSSConf, we launched Pure – a new CSS library. Phew! Here are the slides from the presentation:

Although it looks pretty minimalist, we’ve been working on Pure for several months. After many iterations, we have released Pure as a set of small, responsive, CSS modules that you can use in every web project.

You can learn more about Pure on its homepage, or through the GitHub repo.

Pure is 100% CSS, but as front-end engineers, we don’t only deal with CSS. Much of our time is spent writing JavaScript as well. One of the advantages of Pure is that it doesn’t force you to use a particular JavaScript library. However, we have thought quite a bit about how Pure and YUI can work together now and in the future. Let’s dig into that.

How It Started

To really understand why we made Pure, let’s talk a bit about how the project was conceived. Looking at YUI, we felt that there was a lot of really useful CSS in our library, but it was tightly coupled with our JavaScript. YUI has historically had CSS modules such as Grids, Fonts, and Reset, but they aren’t exposed well enough to non-YUI users, making them hard to find unless you explore all of YUI’s components. In addition, we had some really useful CSS for styling widgets such as table CSS for DataTable, and menu CSS for node-menunav (and now SmugMug’s Y.Menu). It didn’t make sense to keep this tight coupling between CSS and JavaScript, so we decided to break the CSS components out into their own YUI modules. In fact, we had already set a precedent for this with CSSButton.

Once we started upon this path, we realized that instead of just creating new CSS modules, it would be better to split out the CSS entirely into a new project, independent of YUI. There’s no reason why someone couldn’t use that CSS with jQuery, vanilla JavaScript, Bootstrap, or some other library. That’s how Pure came about.

Fitting In With YUI

Not only is Pure compatible with jQuery or Bootstrap, but you can also use it with YUI. In the near future, YUI will be depending on Pure. To make this easy to understand, let’s take an example such as DataTable:

Currently, DataTable has its CSS stored in its assets/ directory. This includes base DataTable styles, along with styles for DataTable plugins. In the future, the core DataTable styles will be pulled in from Pure (Pure Tables, to be specific). We envision doing this in the following way:

1. Creating a CSSTable module that pulls in Pure Table CSS via Bower.
2. Renaming of prefixes (.pure-table changes to .yui3-table)
3. Letting DataTable depend on CSSTable

You could imagine this working for all current YUI widgets that have a CSS dependency in Pure.

Benefits

There are a few benefits in having YUI depend on Pure in this way. First, it allows Pure to stay independent of YUI. We believe it’s important for Pure to have its own identity, and we are accomplishing this by letting Pure have its own release schedule and not be bound by a dependency on YUI.

In contrast, it gives YUI the flexibility to pull in specific parts of Pure that are useful for the library and then tweak them as necessary. By creating YUI CSS modules we’re able to loosen the coupling between a JavaScript widget, and the CSS required to render it. This also makes a great progressive enhancement story: You could imagine having a regular <table> element styled through Pure, until JavaScript is loaded. From a style perspective, the way the table looks will not change since the same CSS rules are being leveraged by YUI.

Thoughts

We’re really excited to see what happens with Pure over the coming weeks and months. As it matures, we’re looking forward to building it out through a thriving open-source community. Although Pure is independent of YUI, our improvements to it will be fed back into YUI through the steps mentioned above. We think this is the best way forward when it comes to YUI and CSS.

We want to continue this discussion with you on the YUI Contrib mailing list to figure out the best way to integrate Pure into YUI. Let us know what you think!

Discuss on Hacker News

10gen introduced MongoDB Backup Service in early May. Creating a backup service for MongoDB was a new challenge, and we used the opportunity to explore new technologies for our stack. The final implementation of the MongoDB Backup Service agent is written in Go, an open-source, natively executable language initiated and maintained by Google.

Why did we Go with Go?

The Backup Service started as a Java project, but as the project matured, the team wanted to move to a language that compiled natively on the machine. After considering a few options, the team decided that Go was the best fit for its C-like syntax, strong standard library, the resolution of concurrency problems via goroutines, and painless multi-platform distribution.

mgo

As an open-source company, 10gen is fortunate to work with MongoDB developers around the world who build open-source tools for new and emerging languages to provide users with a breadth of options to access MongoDB. One of the MongoDB Masters, Gustavo Niemeyer, has spent over two years building mgo, the MongoDB driver for Go. In that time he’s developed a great framework for accessing MongoDB through Go and Gustavo has been a valuable resource as we’ve built out the Backup Service. In his own words:

“It’s great to see not only 10gen making good use of the Go language for first-class services, but contributing to that community of developers by providing its support for the development of the Go driver in multiple ways.”

Programming the backup agent in Go and the mgo driver has been extremely satisfying. Between the lightweight syntax, the first-class concurrency and the well documented, idiomatic libraries such as mgo, Go is a great choice for writing anything from small scripts to large distributed applications.

Starting a Java project often begins with a group debate: “Maven or Ant? JUnit or TestNG? Spring or Guice?” Go has a number of conventions through which Go team has created a sensible, uniform development experience with the holy trinity of tools: go build, test and fmt.

• The organization of source code and libraries is standardized to allow using the go build tool. See details here

• Name test files as XXX_test.go with functions named TestXXX can be run automatically with go test

• Braces are required on if statements and the first brace goes along with the if condition. E.g.

if x { doSomething() }

instead of:

if x { doSomething() }

• Methods that end with an f (e.g. Printf, Fatalf) means a string formatted method will be validated in go vet that the number of substitutions (e.g. %v) matches the number of inputs to the function.

mgo is a real pleasure to use with high-quality code, thorough documentation and an API that is a thoughtful, natural blend of idiomatic Go and MongoDB.Our team owes a lot of thanks to Gustavo for his hard work on this

project.
There are other Go projects being explored at the moment

By the 10gen Backup Team

You’re building an iPhone app. There’s a button that lets the user upload a photo. When they tap it, a sheet comes up, offering two* choices: take the picture now, or picking an existing photo. How should those two buttons be labeled?

I looked at six random apps on my phone:

Yikes.

Does it matter if apps are consistent on matters of this sort? Decades of UI theory seems to indicate so. Having the same button say the same thing in all situations means the user has to do less parsing of the text, and can simply rely on quick-glance recognition. No one really “reads” buttons labeled “OK” and “Cancel”; we recognize them by the mere shape of the words. Let’s try doing the same with these two buttons, used very frequently.

So what should the labels be? It’s not a bad idea to see what Apple does (and consistently, in all their apps, as far as I can tell):

(If your app only deals with photos, the first button would read “Take Photo”)

The point is not to blindly follow Apple’s lead, but to figure out why they arrived at their wording. A few things to keep in mind about menus of this sort:

• Use Title Case: Capitalize Most Words. This is a longstanding convention from menubar menus.
• If all the options (“verbs”) operate on the same target (“object”), mention the object only in the first option. So, the first button says “Take Photo”, and the subsequent buttons drop the word “photo”. This removes redundancy and makes the options visually distinct.
• Avoid technical references; “camera” and “library” are implementation details the user needn’t worry about.

It’s a small change, but if everyone made it, everyone would benefit.

* Of course, you could also consider adding a third option: Use Latest Photo. How exactly you word this button depends on where you place it. If it’s the first button in the list, one option is: 1. Use Latest Photo, 2. Take Photo, 3. Choose Existing”. The word “photo” is repeated, but I’m not sure if “Take Photo” can be worded without mentioning the object. “Take New” sounds a bit off to me.

There has recently been a renewed focus on what I’ve come to call the anti-convention movement in JavaScript. It seems like once or twice a year, someone either does a talk or writes an article saying that all of the things so-called JavaScript experts tell you are wrong and you should do whatever you want. I take notice because frequently I’m listed along with those who are telling you not to do certain things (you know, the people you shouldn’t listen to). The most recent contributions are Angus Croll’s Politics of JavaScript talk[1] from Web Directions and James Padolsey’s NetTuts article, Cargo-Culting in JavaScript[2]. Both take stances against commonly held beliefs in how you should write JavaScript. While I always enjoy a good debate about whether best practices makes sense or not, I feel that sometimes the discussion ends up in the wrong place.

Maintainability

I have a bias. I think that maintainability is important in all code (not just with JavaScript). If you are at all familiar with my work, then this will come as no surprise. After all I’ve written a book about maintainability practices in JavaScript and I’ve written several articles and given talks about the subject as well. To me, maintainability is about creating high functioning teams that can move seamlessly between one another’s code. Code conventions and other best practices designed to increase maintainability do so by decreasing the likelihood that two people on the same team will solve the same problem differently. That may seem like a minor point some, but in practice, seeing things the same way is important for teams.

I like to think of American football as a good example. Perhaps the most interesting relationship on the field is that between the quarterback and his wide receivers. The quarterback’s main job is to read the defense and figure out how best to make progress. The wide receivers’ job is to read the defense and figure out how best to get open so the quarterback can throw the ball to them . The most interesting part of this process is that the quarterback must actually throw the ball before the receiver arrives at the reception location. Because it takes a couple of seconds for the ball to get there, waiting until the receiver is wide open means waiting an extra couple of seconds during which the defense can get in the way. That’s why it’s important that the quarterback and the wide receivers see the same thing on defense and react the same way. When a defensive player behaves a certain way, both the quarterback and the wide receiver must realize it and react in complementary ways. That’s the only way a pass will work.

It’s the same thing with a team of developers. You want everyone reading the field the same way. The fewer unique patterns there are in the code base, the easier it is for everyone to work with. As I’ve said in many of my writings and talks, code is actually a communication medium between developers. Making sure everyone speaks the same dialect is important.

What I do

The very first talk that I gave was on maintainability. I wasn’t trying to trail blaze nor was I trying to prevent anyone from doing anything they wanted to do. What I did then, and what I continue to do now, is to share my experiences. When I say to avoid something, it’s because I actually ran into trouble using it. When I say something is a good way to approach a problem, it’s because I found it to be successful in my own work. Most of my advice has to do with building large web applications and working on large teams because that’s how I’ve spent the past several years of my career. If you have ever seen me give a talk in person, you probably heard me say that some of these don’t apply when it’s just you working on a project all by yourself or with a couple of other people.

Because I enjoy working on large projects and with large numbers of people, I focus most of my own energy on making those systems work. I love the scalability problem because it is much more difficult than anything else. I never talk from a theoretical background and I never claim that my way is the only way to do things. everything I share publicly, from my blog posts, to my books, to my talks, is just about sharing what I’ve learned in the hope that it also helps you. If it doesn’t help you, I wholeheartedly invite you to leave my advice off to the side where it doesn’t get in the way. I have no desire to convince you that I’m right or that you’re wrong, my only desire is to share what I’ve learned and let you use that however you see fit.

“I’m not stupid!”

Both Angus and James base their arguments around the assumption that those who are recommending certain practices believe that everyone else is stupid. While I can’t speak for everyone, I don’t think that this is the case. Recommending certain practices has nothing to do with whether or not you think that developers are stupid. If that were true, you could say the same thing about every person who gave a talk or wrote a book recommending anything. I don’t know when people started getting so upset about recommendations, but pointing the finger back at those making the recommendations and saying, “don’t call me stupid,” is ridiculous. Unfortunately, this seems to happen whenever somebody disagrees with a recommendation.

That’s not to say that all advice is good. That’s also not to say that you should follow all of the advice all the time. You should, though, stop and think about the context in which the advice is given and whether or not that context applies to you. There is no rule that applies 100% of the time. That’s not just true with JavaScript, it’s true with every rule in the entire world. The fact that there are exceptions doesn’t mean that it’s a bad rule. If the rule holds 99% of the time than it’s worth codifying as a good idea. The recommendations that people make around best practices should be treated the same way. All rules are starting points and it’s up to you to continue the journey.

Think about driving. Most roads have a line down the center and some have guardrails along the side. Most of the time, you expect people to drive on the correct side of the road and not drive off of the road onto the sidewalk. Why bother having those lines and guardrails? I’m relatively sure that everyone within a country knows which side of the road to drive on and that staying within your defined driving lane is expected. The lines and guardrails just serve to reinforce what you already know when you’re driving a car. They give you a few extra hints. So if you start to veer over the line in the middle of the road, you know that you may be entering into some dangerous territory. The line doesn’t stop you from doing it, it’s just an indicator of expectations. Yet I don’t know anyone who is offended by the lines in the road or guardrails.

And just like with best practices, sometimes you actually have to cross over the line or drive over a sidewalk. What if you’re making a turn to the other side of the street? What if you need to pull into a driveway? What if a car is broken down and you need to get around it? There are even exceptions to the rules of the road. No one really thinks about it because we all just do it naturally.

If you come from a position that anyone recommending a practice to you thinks you’re stupid then you are doing yourself a disservice. There is no global JavaScript contests to see who can get the most people to follow their practices. No one wins anything by having more people using comma-first than comma-last. Literally there is no skin in this game for anyone.

Coding for the maintainer

Both Angus and James use the following quote (one of my favorites, from Code for the Maintainer[3]):

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

Unfortunately both miss the context of this quote before dismissing it as bad advice. This quote doesn’t speak about your current teammates nor does it imply the person who is going to maintain your code will be stupider than you. The meaning behind this quote is that you don’t know who is going to be maintaining your code in the future and that person will lack context to figure out what your code is doing. Lacking context has nothing to do with intelligence.

Think back to a time when you had to take over code from somebody else. Maybe that person was still at the company or maybe not. How did you feel needing to work with that code? I can tell you from personal experience, I’ve inherited some really bad code over the years. Code that is hard to work with because it’s very difficult to understand what it’s doing. I consider myself to be reasonably intelligent, typically above average on most days, but if you sit me down in front of some code that I’ve never seen before and tell me to fix a problem it will likely take me a while to do that.

If I were to restate the quote in a way that would hopefully make people understand the intent better, I would restate it as this:

Always code as if the person who ends up maintaining your code will not be able to talk to you for help.

Removing the scare tactic phrases from the quote makes it a bit more palatable. The idea is that the person who maintains your code won’t have you as a resource and therefore the code has to make sense on its own. The assumptions and organizational knowledge that exist only in your head are the enemy of that maintainer. It doesn’t matter how intelligent that person is, the job is a nightmare without proper context. That’s why I can’t jump in and start maintaining your JavaScript library even though I know JavaScript pretty well. That’s why things like code conventions and documentation are so important for maintainability.

If your code can’t be easily maintained by someone else, then that’s not a mark of quality. The teams I’ve worked on have all converged on common conventions and that has allowed anyone to be able to work with any file at any point in time. Understanding the conventions means that you understand the files and that means you can do your job with a very low barrier to entry. It’s a point of pride for my teams that code ends up looking the same regardless of who wrote it because ultimately it’s the team’s responsibility for that code rather than an individual’s responsibility.

It’s a starting point

Thankfully, Angus ends his presentation with a very important statement: there are no absolutes. All of the rules and best practices that you hear about are simply a starting point. I always tell people on my teams that we’re going to define some rules and follow them until they don’t make sense. When they don’t make sense, we’re going to talk about why that is and figure out what we’ve learned. The rules are there to help you get off on the right foot and make sure that you don’t need to stop and ask at every moment what the right approach is. That’s important because our jobs are fundamentally repetitive.

We go into work mostly doing the same thing every day. If your job is to create features on a product, you’ll find that the features can get implemented in very similar ways even though the features themselves are very different. If your job is to fix bugs, you tend to debug and fix things in the same way. It’s the same for all of us, programming is repetitive. If everyone ends up doing the same task in different ways than the code becomes harder to manage. So you start by defining some rules about how things will be written and deal with the exceptions as they come up.

And there will be exceptions. Exceptions don’t mean that the rule is bad, it just means that the context has changed and the rule may not apply.

Effective learning

This really all comes down to how you choose to learn. Every single person who takes the time to write a blog post or give a talk or otherwise share their knowledge is saving you valuable time. They are doing the heavy lifting of presenting an idea and it’s just up to you to decide if that idea fits with what you do or not. Thinking those people automatically believe you are stupid is counterproductive and doesn’t matter at all. Recommendations are simply ideas presented for consideration. Many times, the ideas flow from a problem that the recommender experienced at some point in time. Figure out the problem and you can figure out whether or not the context applies to you. That’s the most effective way to learn. Or to put it more eloquently:

Do not believe in anything simply because you have heard it. Do not believe in anything simply because it is spoken and rumored by many. Do not believe in anything simply because it is found written in your religious books. Do not believe in anything merely on the authority of your teachers and elders. Do not believe in traditions because they have been handed down for many generations. But after observation and analysis, when you find that anything agrees with reason and is conducive to the good and benefit of one and all, then accept it and live up to it.

- Buddha

References

• The Politics of JavaScript by Angus Croll (SpeakerDeck)
• Cargo-Culting in JavaScript by James Padolsey (NetTuts)
• Code for the Maintainer (Cunningham & Cunningham)