Skip to main content

Steve Jobs

By all accounts, Steve Jobs was the kind of guy who you didn't want to work with. To put it bluntly, he was a perfectionistic pain in the butt, the Boss from Hell for whom good was never good enough. Yet that intensity was driven by a vision that has transformed technology in the past decade.

Many successful businesses make their fortune by carefully calculating how much people can spend and squeezing every bit from them via tricks, gimmicks, and sometimes even outright lies. Advertising and marketing create demand for a product that is often much different than it appears to be. When people find out that the reality doesn't match what they were promised, the outcome is bitterness and anger towards the company that deceived them.

Jobs was different in that he figured out what people really wanted--so often in sync with what he really wanted--and gave it to them. He seemed to figure it out not by focus groups or statistical analysis of consumer trends, but by a gut feeling that was in tune with the public's inner desires. For Apple the product itself, not the advertising, inspired good feelings. Those products are often defined by what they don't have, a Zen simplicity that lets their essential qualities shine through.

Plenty of companies take one idea and ride it for years, making only small tweaks to the formula. Not so with Jobs. He had no problem branching out from Apple's core business of personal computers. First with the iPod, then the iPhone and iPad, Jobs put his company into markets against established players and blew them out of the water. He dived headlong into markets left for dead after multiple attempts by competitors who had nothing to show but a crimson balance sheet. He reminded us that a great product is the best foundation for a great business strategy.

Clearly, Jobs was not the only one responsible for Apple's past decade of incredible success. To his credit, he never claimed he was. In a "60 Minutes" interview, Jobs said, "Great things in business are not done by one person, they are done by a team of people." Yet he provided a successful vision the company could follow, and--to their credit--one they did follow.

Jobs passionately knew what he wanted, and wasn't happy with the people around him delivering anything less. Yet passion by itself isn't a recipe for success, especially when it creates such tension in the organization. Jobs was effective not just because he was passionate, but because the ideas behind his passion were so often proven right. No doubt there were stressful times inside Apple given Steve's style. In the end, however, everyone must be deeply satisfied with the success of the products they created under his leadership.

Comments

Popular posts from this blog

Tragedy of the WebKit Commons

With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change. We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging:  "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions."  I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different. Opera did  land their first WebKit patch  so they wanted to make a statement that they weren't gettin

Please Stop the jsPerf.com Abuse!

According to many of the tests on jsperf.com , jQuery is slow. Really slow. The jQuery team gets bug reports from web citizens who've discovered these egregious flaws via jsperf and want them fixed. Now, jsperf.com can be a great tool when used knowledgeably, but its results can also be misinterpreted and abused. For example: Why doesn't jQuery use DOM classList for methods like .addClass()? There are at least three good reasons. It doesn't make any practical performance difference given its frequency of use. It complicates code paths, since classList isn't supported everywhere. It makes jQuery bigger, which makes it load slower for everyone, every time. But this jsperf shows classList is much faster! How can you say that? Well it's possible that test is running afoul of microbenchmark issues , and not measuring what it is supposed to measure due to the increased sophistication of today's JavaScript compilers. This is a big problem with a lot of t

You Might Not Need Babel

Babel is great, and by all means use it if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6. At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel. ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert() , we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face