What's Your Start-up's "Bus Count"? 7 Myths of Entrepreneurship and Programming

(Photo: Stuck in Customs)

For the last two years, one name has come up again and again when talking with A-class start-up investors: Pivotal Labs.

See, Pivotal Labs quietly helps dozens of the fastest-growing tech companies in the world, including freight trains like Groupon and Twitter. If your start-up needs to get good coding done quickly, as in lightning fast — or if new hires need to get good at coding quickly — top venture capitalists are likely to look over their shoulder and confide: “Call Pivotal Labs.”

I first met the Founder of Pivotal Labs, Rob Mee, when one of the start-ups I advise, TaskRabbit, began working with them.

One thing is immediately clear: Rob is obsessed with how to get obscenely high output. But that’s nothing new. Here’s the differentiator: he’s obsessed with how to get obscenely high output with sustainable effort. One of his first remarks to me was “3am with Jolt and pizza can be fun, but it’s a myth that it’s the fuel behind scalable success…”

My kinda guy.

I then posed a few questions:

How do you create a scalable, bullet-proof business? In this case, “bullet-proof” meaning that there’s no single point of failure — it won’t nose dive if any single player (like you) is taken out… or opts out.

What are the myths of tech product creation (software specifically, and entrepreneurship more broadly) that he’d like to expose?

This post contains his answers.

Think software doesn’t apply to you? If you’re in business, rest assured that at least a few principles of good software development most definitely apply to you. Translate them into your world and prosper.

Enter Rob Mee

Software development is a rapidly evolving field that got off to a very rocky start.

Conventional wisdom for many years was that software engineering should be like other types of engineering: design carefully, specify precisely, and then just build it – exactly to spec. Just like building a bridge, right? The problem with this approach is that software is just that. Soft. It’s endlessly malleable. You can change software pretty much any time you want, and people do. Also, since software can be used to model just about anything, the possibilities for what you can ask software developers to do are pretty much infinite. Want to simulate a circuit in software? Go ahead. Run a bank? No problem. Connect half a billion people to their friends? Why not, piece of cake. Not only that, but what we ask programmers to produce changes in the middle of the development, often in unpredictable ways.

This is not bridge-building.

Denying the reality of constant change doomed many software projects, for many decades, to either abject failure or huge budget overruns. So why did an entire industry hew to this conventional wisdom that flew in the face of all evidence? Hard to say. Finally, however, there has begun to emerge a new consensus: software development needs to respond well to change. In fact, it needs to be optimized for change. Nowhere is this embraced more than in today’s web start-up development community. So-called agile methods have gained currency, and the “lean start-up” movement calls for exceedingly rapid change, often automated and based on experimentation with the live system.

So we’re all good, right? Not so fast. In spite of the acceptance of more agile methods, there’s plenty of received wisdom hanging around… and most of it ought to be thrown out the window.

1. Myth: You have to hire “ninjas”.

The myth of the hero hacker is one of the most pervasive pathologies to be found in Silicon Valley start-ups: the idea that a lone programmer, fueled by pizza and caffeine, swaddled in headphones, works all hours of the night to build a complex system, all by himself. Time out. Software development, it turns out, is a team sport. All start-ups grow, if they experience any meaningful success. What works for a lone programmer will not work in a company of 10. And what’s worse, encouraging the hero mentality leads to corrosive dysfunction in software teams. Invariably the developers who do a yeoman’s 9-to-5, week after week, cranking out solid features that the business is built on, lose out to the grasping egomaniacs who stay up all night (usually just one night) looking to garner lavish praise. Rather than reward the hero, it’s better to cultivate a true esprit de corps.

2. Myth: Programmers need to work in quiet, without interruption.

This makes sense … if people are working on their own. Every interruption does indeed break concentration, and it takes a while to get back “in the zone”. Some well-known software companies even insist that each programmer have their own private office. That way they’ll never be interrupted, right? Except that modern-day interruptions have little to do with an actual person tapping you on the shoulder, and everything to do with instant messaging, mobile phones, Facebook and Twitter, email, and the music coming in through headphones that programmers swear helps them concentrate. The reality is that most programmers working on their own only spend a small fraction of their day actually programming: the interruptions are legion, and dropping in and out of a state of concentrated focus takes most of their day. There is a solution, however: pair program. Two programmers, one computer. No email, no Twitter, no phone calls (at least not unscheduled; you can take breaks at regular intervals to handle these things). If you do this, what you get is a full day of pure programming. And “getting in the zone” with someone else actually takes almost no time at all. It’s a completely different way of working, and I maintain that it is far more efficient than working alone ever can be. And in fact, with the current level of device-driven distraction in the workplace, I’d suggest it is the only way that software teams can operate at peak efficiency.

3. Myth: Start-ups run hot, so we’re just gonna have to burn everyone out.

Working crazy hours doesn’t get you there faster. In fact, it slows you down. Sure, you can do it for a week. But most start-ups plan to be around for a little longer than that, and developers will going to have to keep programming for months, if not years, to build a successful product. Many start-ups operate as if the pot of gold is just around the corner; if we only work a little harder, we’ll get there. Pretty soon developers burn out, and simply go through the motions of working long hours without any corresponding productivity. Working intensely, for shorter periods of time, is far more effective. Pivotal has helped hundreds of start-ups build systems, and has done it on a strict 40-hour week.

4. Myth: Looming deadlines necessitate shortcuts.

Many software teams use the excuse of a high-pressure market and the need to ship product right now as an excuse to do shoddy work. Writing tests goes by the wayside; careful design is forgotten in the rush of frenzied hacking. But software teams are no different than other teams we’re all familiar with, and the way high-performing teams succeed is not to lose their cool: on the contrary, when the pressure’s on, you stay frosty, and let your training carry you through. How many times have we heard stories of remarkable performance under unimaginable pressure – whether it be military, professional sports, or a pilot landing a plane on a river – and the explanation almost invariably involves the heroes saying, “We trained for this situation.”

5. Myth: Developers should take ownership of their code.

Ownership sounds good. As American as apple pie. Personal responsibility, right? But “ownership” in a software team implies that only one developer writes – and understands – each module of code. This leads to defensiveness on the part of the developer. It also creates risk for the business owner, since the loss of one person could slow the team, or potentially cripple the business if they were responsible for a particularly crucial part of the system. A much healthier process allows any developer to work on any code in the system. Pair programming facilitates this, because knowledge is passed from person to person. The so-called “bus count” (how many people in your team have to get hit by a bus before you’re all dead in the water) is a critical indicator of risk for the software start-up. And it’s not really a bus we’re talking about here – it’s your competitors, who would love to hire your best developers. The more people who understand the whole system, the stronger and more resilient your organization.

6. Myth: You need a quirky hiring process.

Would you hire an actor without an audition? You wouldn’t last long as a director if you did. But this is exactly what almost all companies who hire software developers do today. Usually the process involves talking through an applicant’s experience with them. And that’s all. Imagine asking an aspiring actor if they enjoyed their role as Hamlet. Did you play him well? Good. You’re hired! Many famous software companies propose brainteasers for their applicants. Some top companies even give candidates an IQ test. The best of them run candidates through a simulated software problem on a whiteboard. This is a sorry state of affairs. I’m going to state (what should be) the obvious: the only way to hire good programmers reliably is to program with them. I run programmers though a one-hour, rapid-fire, pair programming interview – and that’s just the start. Having done it over a thousand times, I can score developers relative to each other on a 100-point scale. What do I look for? Mental quickness, ability to think abstractly, algorithmic facility, problem-solving ability. And most importantly, empathy. Because collaboration is the most important thing we do, and it doesn’t matter how smart you are if you can’t relate to how other people think.

7. Myth: Specialization is essential.

Managers, quite naturally, want to attack problems by dividing and conquering. In software teams, this often manifests as an urge to force specialization. Front-end vs. back-end, database administrators, and so on. Brad Feld suggests in his blog that every team should have one “full-stack programmer”, someone who’s a true generalist. He’s right, but he’s not going far enough. Everyone, in every team, should know the full stack [Tim: read Carlos Bueno’s piece here]. Why? Because specialization makes a team fragile. Remember that bus count? Every specialist is a liability; if they leave, and you can’t replace them, you’re sunk. Not only that, but it makes a team sluggish. Specialists need to make their disparate parts of the system communicate through defined interfaces. In effect, they end up writing informal contracts with each other about how to do it. This leads to a lot of overhead, and often defensiveness or finger-pointing. At Pivotal, every developer works on every level of the system, from HTML and JavaScript, to Ruby, and down to the database. And the argument that specialists will be better at a particular layer of the system if they’re allowed to focus on it doesn’t really hold water. The state of software technology today is simply not that difficult. Programmers are better off knowing all layers and how they interoperate. By the way, another important implication of all this: you don’t need to hire for a particular technology. Ruby programmers in short supply? Fine, hire a Java programmer and train them in Ruby (pair programming works great for this). Someone defines themselves as a “server-side” programmer? No problem, make them do JavaScript, they’ll pick it up.

If they’re any good, that is.


Read more about Pivotal Labs and find their collection of tech talks here. If you’re in SF or Boston, try TaskRabbit while you’re at it 🙂

Click here to browse this blog’s other Entrepreneurship posts (covering everything from Twitter and FUBU to selling companies and angel investing).

The Tim Ferriss Show is one of the most popular podcasts in the world with more than 900 million downloads. It has been selected for "Best of Apple Podcasts" three times, it is often the #1 interview podcast across all of Apple Podcasts, and it's been ranked #1 out of 400,000+ podcasts on many occasions. To listen to any of the past episodes for free, check out this page.

Leave a Reply

Comment Rules: Remember what Fonzie was like? Cool. That’s how we’re gonna be — cool. Critical is fine, but if you’re rude, we’ll delete your stuff. Please do not put your URL in the comment text and please use your PERSONAL name or initials and not your business name, as the latter comes off like spam. Have fun and thanks for adding to the conversation! (Thanks to Brian Oberkirch for the inspiration.)

162 Replies to “What's Your Start-up's "Bus Count"? 7 Myths of Entrepreneurship and Programming”

  1. What you’re talking about is closer to moder Agile development. This is a very mature space in the software industry – mix in some Lean practices such as Kanban – and, you’ll take this to the next level 😉

    1. Learning all parts of the stack isn’t that hard. I’ve had to do that out of necessity for my own stuff. I also just find it really interesting knowing how everything works even down to driver level at the operating system

  2. I agree with the author on a few points. Generalists are important but good luck finding someone with all those skills you mentioned (HTML and JavaScript, to Ruby, and down to the database).

    As a developer, I prefer to be skilled in certain areas and prefer my experts to take over the milestones that are important.

    BTW, I like the taskrabbit interface (except for the buttons at the top – hard to follow).

    1. Hey Steve, hiring specialists isn’t an agile approach, you want to internally train people to have a T shape skill set where the developer is a specialty in one but can help out in other areas.

      1. Generalist developers automatically will have, or generate their own specialities from previous experience or what they are interested in. A team that then has to tackle a more advanced area simply have to pair up and learn something new. Most intelligent people like learning something new so it’s a good result all round.

  3. Hey Tim! Thanks again for the amazing posts really inspiring and keep up the great work! Love reading your content!

  4. Very timely Tim, thanks 🙂 Haven’t been able to afford the ninjas (yet) anyway & thankfully have learned a lot from mistakes at my (killed) job so sustainability & diversification have been top-of-mind…but this really solidifies a lot for me. Thanks Rob!

  5. I especially like this one myth: “Specialization is essential”. I’m an all-round web developer and designer but unfortunately there are a lot of old fashioned web businesses out there that are looking for specialized people. Of course, you gotta be good at at least something, but there’s more to life than front-end developing. Front-end developing in a team of 10 people. “Don’t touch the PHP”… argghhh.

    1. Yeah so true and great writeup. I’ve been applying for jobs lately and some of the descriptions can be lengthy when one considers what the job may actually entail. Besides all the communications fluff like “ability to work alone or in team”, “good communications skills”, “self-starter” and that jazz, they’d like it if you had 2-4+ years experience in each technology they’ve been using forever because a guy they hired x years ago got them started on something they’re afraid to get off of.

      THIS was actually in an ad I looked at today:

      • Application Development (C#, C, C+, C++, VB, VB.Net, PHP, Java, SQL, mysql, Oracle, PL/SQL)

      • Web Development (PHP, HTML, CSS, AJAX, JavaScript)

      • Database Architecture

      Seriously? So they have no idea what they’re looking for, and they will never find them.

      An interview last week I had for a job was to recreate an existing windows application, which is basically just a big form – onto a website, and they want to use PHP/mysql (my specialty). Turns out, they’d like the application to be able to work on multiple mobile devices (blackberry/iPhone, no biggy), is available offline (outside of cellphone area), and syncs automagically when re-connected or re-entering cell service areas. I didn’t even bother telling him PHP/mysql would be my last choice for such an application. Then he told me I was asking $15,000/year too much.

      And in another interview, “So 4 years direct experience with Drupal, jQuery, and PHP? But zero with script.aculo.us? [Don’t call us, we’ll call you.]”

  6. I’m not a programmer by any means but I definitely enjoyed this list of myths!

    Thanks Tim.

  7. MYTH: Startups run hot, so burn everyone out…

    Thank you for saying this Rob. It goes without saying that the mentality of “work till you drop” at startups is pretty pervasive. Sustainable output is key. I personally have had to learn this lesson the hard way. Perhaps others have gone through this model of production….

    1. BIG Idea – Everyone is excited and rallies behind the big idea / product / project. (This is the stage where you and your friends high five each other for being so awesome to think of such a great idea)

    2. Power Sessions – You know the first few steps towards making your product a reality so you pull a few all nighters doing research and placing a few phone calls. (This is the stage when the unsustainable effort is put in)

    3. Stumbling Blocks – The power sessions slowly lose their steam as you hit stumbling blocks. This is when the true magnitude of the project becomes real to you. (This is the stage where your friends start dropping out)

    4. Fizzle and Guilt – Suddenly its a few months down the road, the project is half completed, and no one feels like working anymore. (This is the stage where you are back to being alone with a half-baked idea and no more energy left to push forward)

    Moral of the story? Don’t be like younger me where all my projects were half baked and never completed due to unsustainable output. Pace yourself and set goals. My personal advice? Set ONE objective / feature / task per day and complete it. Most importantly just remember… you can’t fail. (Literally… you made the product / idea/ project up so you can’t fail at something that previously didn’t exist!)

    1. Totally agree with this list. One task per day, really focus on it, and do it right. The days where I feel “overwhelmingly busy” all day going from task to task are usually the least productive

  8. Timely advice Tim. I’m currently in the midst of building an exciting new start-up that’s already attracting a lot of attention here (in Australia) but the biggest frustration is actually getting it to market quickly and efficiently. I believe in build, test, iterate, launch, iterate etc. We’re getting close to launch but I’m certainly worried about the “bus count”.

  9. Great post. Makes me wonder what kind of software project your working on. 4HB App?

    I’ve become obsessed with leaning about software development lately and would be interested in hearing your thoughts Tim on non technical involvement in the software process.

    1. Hi Dave,

      I am working on several 4HB and 4HWW apps and will be detailing how it was done when finished 🙂

      All the best,


      1. Hi Tim, when you launch the apps im interested in learning more about the earning business model behind it.

        Im currently talking to programmers and developers to work out my first muse, which is based on a mobile app as well, would be interesting to talk about this subject.

        my application will source a lot of consumer data and with some back-end metrics and analytics its seriously interesting for certain companies. i believe a lot in social data and next to this it will help people being more mobile 🙂

        when you find it interesting to talk about and have the time, it would be a pleasure to talk about it, when you dont have the time but do have some expert friends 😉 same goes out for them ofcourse.

        many thanks, Pascal

      2. Tim, you’re a genius! Of course, you knew that….

        Man, I have to echo Guillermo when he says, “Tim, please dont leave BlackBerry users out!”

        Can’t wait!

      3. Aloha Tim,

        Thank you for your post about Pivotal Labs. I am in the beginning stages of having CRM software and a corresponding mobile app developed. I contacted Pivotal Labs and quickly realized that I do not have the budget to work with them. Would you be able to recommend any other developers that are less pricey? Please advise.

        Thank you for your time and help, Tim. I look forward to hearing from you!

  10. I love the interview “audition” very few companies know how to interview in a way that actually assesses skills and whether a person would be a good fit at their company. If you can make them do what they are going to do, you see their skills as well as how they act about what they are supposed to be passionate and successful at.

  11. The best part of this terrific piece is the fine line Rob Mee draws between useful automation and irresponsible outsourcing of a key responsibility (hiring).

    It would be easy for someone to think that the IQ tests or roadside riddles big software companies use to grab ninja talent are great examples of 4HWW-style automation. But as Rob Mee points out, this is irresponsible when you are expecting to work with the programmer in teams after they are hired.

  12. Good points Rob and thanks for posting this Tim!

    I’ve been working in a Fortune 500 company for my entire career and the funny thing is – you see folks inside think they are working in a “startup environment”. They almost take this list of myths as the way they operate. A very strange beast to observe, the dysfunction that ensues is hilarious at times. I’ve moved up from programming into management only because the corporate borg has offshored those parts of the business as they are deemed “non-strategic” roles.

    I sit here laughing at myself as I’m now part of the corporate machine, yet in my spare time from family and other interests I dream about and then struggle trying to start-up a side project/product. Other elements are wife, kids, mortgage, etc. I am a generalist: CompSci degree, Oracle/MySQL, Java, html/css/js, and playing with stuff like Ruby, Objective-C/Cocoa.

    Do you have any advice for someone in my shoes?

    1. hey matt,

      I do not know if i can help u from where i am.

      but i think the same thing as u and i do not have all the computer skills u have. i am working in a european french leading bank (trying to help greece and then getting poor S&P grade)

      in other hand, i could be seen as very “creative” or any other words that pop up when u think about people who are not afraid to ask question and make “not common” idea. my wife says that she likes my way of thinking for linking materials engineering and shoes design (for example).

      i really think that guys like us should exchange (like a big brainstorming) to see what we can do in order to pursue our dreaming lines or dreaming way of life.

      we are about buying a small mechanic(al?) company (which is not very well now) i wonder what funny things i can do with a turning machine 🙂 maybe it is not the good way for a muse !

      and u, what are u dreaming line and business projects?

      (by the way i am kind of rugby union and plan to do something about it)

  13. Great post. I too have found lots of these same situations. Programming doesn’t have to be as complicated as some make it out to be and smaller apps can actually be done very easily and cheaply its actually quite surprising!

    I’d say if anyone hasnt take the time to investigate getting a program done because they believe its too hard or expensive, dont assume, put in some time, get some quotes, you might be surprised at the result!

  14. Well I am not a programmer. Thanks for these myths. Good points to remember for future reference.



  15. Tim, and Rob, do you think it’s perhaps worth mentioning that what you’re calling myths do partly depend on the kind of product/project being worked on?

    If you move to more “mission critical” type of software development, like medical, financial, agricultural, etc then you can work through a lot of these “myths” and change them to “depends”. For example lets say you’re working with GIS systems then specialization actually IS pretty essential. Also perhaps don’t ignore that the specialized knowledge required may be more about the product/project itself than the programming.

    Having said that I, and probably every other devhead, look forward to seeing if you, Tim, can 4 hour software development!

  16. I fully agree with the 40ish hour work week. Ppl need to refuel on their own lifes to feel energetic about work again.

    I disagree about specializing. While one should be well rounded, it takes dedication and focus to be truly good developer even in one area. The front end changes fast and if you are going beyond the drag and drop tools out there and building your own frameworks, you better know exactly what your doing. If you are always leveraging others full frameworks…then sure… know everything so you can glue them together. But even then, most won’t have in depth knowledge and ability to build these systems themselves

  17. As always your posts are informative and inspiring. Thanks for this one, as for all your others. I am not much of a techy or coder, but I have many friends that will love this article and hear what you have to say.

  18. Thanks for the great post by Rob. I’ve been fortunate to work at Pivotal Labs (not programming) and it’s really a unique place. The core of understanding everything and working together as a team is great. Withstand that bus! Everybody behind you has your back.

  19. I think you have hit a point in my business life. I need to do a self assessment asap. Thanks Tim

  20. Controlling project risk is essential when developing software. It’s crucial to choose a project management approach / development cycle that can control or embrace those risks.

    Project risk might be influenced by:

    – project size (feature creep, ..)

    – volatility of the requirements (very volatile in today’s dynamic world)

    – experience with the technology

    – …

    Keep in mind that the project risk will rise +- exponentially by the presence of those risks.

    Whatever approach you might choose, key is to keep balance between consistency (documentation, requirements change management, ..) and agility (respond to changes that are essential to project success).

    More info in “Corporate Information Strategy and Management” by Lynda Applegate. That book is written for executives and is based on case studies by Harvard Business School researchers.



  21. Tim, the guest posts you put up here are elite.

    This blog should win the Nobel Prize for Awesome.

    It’s been a privilege to have the honour of reading this post and so many like it. Thank you.

    Ps. Your site says copyright 2007-2010 in the bottom right hand corner.

  22. This is a great post. As a developer, I’ve worked in teams and found them to be more efficient… I’ve even pair-programmed for tricky things, but not for any real length of time.

    While reading this, I thought it would be fun to take the pair-programming interview just to see how it goes.

  23. Kent Beck from1999 just called, he wants his White Book back. This is blog post is almost a carbon copy of XP mantra regurgitated.

  24. Love the idea of using pair programming to fight distraction. It has other benefits, including motivation and better quality code, but I had not thought of this.

    I’ve not done much pair programming, but when I studied physics at university working in pairs worked best. I look back with nostalgia (probably Stockholm Syndrome) to many days of quantum mechanics exercises in a freezing room, where only tea, the occasional episode of Coupling and very rare moments of increased understanding of the universe provided relief.

    I agree with some previous commenters that the argument against specialization needs some nuance. In physics I would often find the general solution strategy, while my partner had the patience to actually do the complete tedious calculations. Sometimes I was right, sometimes she forced me to dive deeper into these calculations myself and come up with a new idea.

    With development, I think the broad bachelor / narrow master analogy is best: you should be able to roughly understand every stack of the system, but each member can specialize in a specific aspect. You can even outsource a few highly specialized tasks. Not understanding a specific component of your system won’t sink your ship; worst case is hiring an expert for a week to figure it out and teach another team member.

    It always pleases me to hear people confirm that sustaining long weeks is unhealthy. I still think 40 hours is pretty long, unless you can avoid a long commute, get huge amounts of sleep, be in perfect health and have enough time for friends and hobbies. But I’m European 🙂

    Tim, I’m curious to learn more about your own 4Hxx startup projects. I’m in the Valley this summer looking for inspiration.

  25. The hiring process tip is a good one. IDEO is known for this type of hiring. If you want to know how good someone is at doing something, have them do it. Simplistically brilliant. Great post.

  26. Hey Tim…

    Thanks for using my photo (my agent sent me this)… can you please link to the main blog at http://www.StuckInCustoms.com ? That would be best… giving credit to Trey Ratclfif also would be better than my Flcikr handle, if you don’t mind.

    We’re up to over 175,000 photo views per DAY, thanks to creative commons… Also DM me @TreyRatcliff I have a little gift for you…

    1. Being a programmer and entrepreneur myself, this post is the quintessence of practicality.

      Thanks so much, Tim.

  27. Hey guys,

    I figure it’s a particular kind of audience who’s gotten this far into reading the comments on this post, so I’m going to figure you are either Tim Ferris or someone deeply interested in both programming and entrepreneurship. If you are reading this, you can probably pull this off. I’ve got an entrepreneurial idea I would really like to see done with alot of revenue/ positive change for humanity potential and I’d figure I’d throw it out here for someone to take if they’d like to. Just to reiterate YOU CAN TAKE THIS IDEA (if you’d like to, I think it’s nifty).

    If you look at the political system in the U.S., there are alot of candidates coming up with their best ideas for a political platform in an effort to please special interest groups that give them money and get enough votes to be elected. Basically, I think we should have people present IDEAS directly to the american people and explain them logically, and then have people vote them up or down in a way similar to the system Google moderator has for ranking questions. Then candidates can directly see crowd sourced innovative ideas that could change this country for the better and come up with a similar, already market tested idea to get votes. Society is naturally becoming more libertarian now that the news embargo is over, this is just a way for smart people to propose solutions directly (anyone should be able to submit ideas, but you should have to attach credibility indicators) and speed to process by which innovation and quick communication can help people.

    This is a really rough sketch of an idea, but I figure it’s very simple programming wise and has a large potential for viral growth and potential positive impact on humanity. We could take lobbying back from special interest groups and put it in the hands of smart people going after solutions to really big problems (I like to think of it as Throwing Rocks at Philistines). Hopefully that is you, have fun.

  28. Hi Tim,

    Are you interested in partnering with Symantec? We are currently looking to sponsor or partner with folks such as yourself in efforts to promote small businesses and entrepreneurs. We think what you are doing to help small businesses is incredible.

    Please let me know if you are interested as we would love to discuss this huge opportunity with you further.



  29. Liked the myths list. I like this idea: “run programmers though a one-hour, rapid-fire, pair programming interview”. Any chance to get more details on how its conducted, how the problems for pair programming interview are selected, etc… Something like a sample walk through.

  30. Fascinating. I’ve been looking for books on how to effectively scale a service based business to no avail, and I pay attention to any advice on scaling. I wish I could have Rob Mee obsess about service based business too and help figure some stuff out. I just don’t understand why there isn’t any good book on this already.

  31. Great list. Thanks to both Tim and Rob for sharing. This advice came at the right time for both my day job and my side project.

  32. One thing I have to say for Pivotal is that what they are doing is working very well.

    Not many know but I used to shot all of their videos for the past few years even when I didn’t need the work and could have been focusing on Datsusara full time. Why you ask? It wasn’t the money (although I did appreciate their system even in this department as they paid on time and without hassle, I can’t say that for any other client I ever had, including a a very large so called “lean” manufacturing group) . Basically everyone there is extremely competent, easy to get along with and just overall full of awesome sauce.

    I don’t miss doing video at all, but I do miss do video for Pivotal Labs, it’s a great place, keep up the good work Rob 🙂

  33. Awesome tips. I hate the concept that a programmer has to plug in for 24 hours a day, 7 days a week for a startup to succeed. That’s unrealistic and frustrating from my end. It turns entrepreneurship from an ideal career to a complete burden.

    I’m always curious to hear why people decide to pursue a career in entrepreneurship. For me, it’s always been a goal, but I used to be terrified to quit my job and start something with no assurance of success. I ended up reading a book called The Evolution of the American Dream which really inspired me to follow my version of the American Dream. Fellow entrepreneurs – what facilitated your decision?

  34. Quite possibly some of the dumbest advice I’ve read in a while. These “myth” debunks may be true of about how to solve one class of problems, startup web/mobile development and that’s about it. And I can’t think of a single mobile app of any success that can’t be rewritten from scratch in about 6 weeks by a very small team. So, take this advice for what it’s worth (nothing) because if your problem is more complex than that you’re wasting time and money. Invest in developing a real team of pros.

    As soon as any startup actually makes it, they recognize this and hire some pros and then magically their software problems become their least pressing business problem (see Twitter/fail whale).

    Pivotal Labs is basically a clone of those ThoughtWorks dorks. Their goal is ensure there is absolutely no real professionalism in software engineering so that their brand of “consulting” makes sense to non-tech CTO/CEO looking to lower costs.

    Seriously dumb post. If you are looking to solve/model complexity with abstraction in software, do yourself a favor. Hire a professional.

  35. While it is true that “quirky” hiring techniques are bogus, I would NEVER ask an applicant to program during an interview unless they were just out of college. Reason? If I am hiring somebody with some experience I don’t care if they can grasp something quickly, I care if they can grasp it deeply. The ability to code in a 1 hour interview does not correlate to the ability to handle a three year project with hundreds of thousands of lines of computer code. I once hired somebody I talked to for an hour over lunch. Spent more time talking sports than interviewing. He turned out to be a decent programmer and is still with the company 3 years later.

    Most work of any significance requires a large amount of specialization because it is HARD. Sometimes advanced math is required(this is my specialty). Not everybody can do it. Try to make them would be a waste of time. I work with somebody who absolutely refuses to code a graphical interface. Will I get rid of him? No, because he is the best embedded systems programmer in the company. Can I train other people to do his job? Not for less money than what he makes.

    The techniques described work for small projects. When dealing with very large(10’s of millions of dollars) projects over 3+ years, it just doesn’t work.

    1. Hi Jason- Thanks for the comment. Would you mind sharing some details about your experiences and current job position? Your company’s name is not necessary to reveal, but number of employees and industry would be great to know.

      Differing opinions and skepticism are great and 100% encouraged, but it helps us to know where and who these critiques are coming from to provide some deeper context.

      Look forward to hearing more…


    2. I totally agree with Jason that often there is no need to give a coding assignment during an interview. Coding quiz will only test applicant’s programming skills which are considered very basic and don’t require to have a computer science degree or an equivalent work experience. Anybody can code.

      Programming test won’t help me to figure out if the applicant is a good engineer (process/system designer). I have been building financial systems for 15 years, and it’s not that hard for me to tell if I am talking to a senior architect or a junior developer. I talk architecture and screen for bs. It never fails.

      I am also curious to know how many companies actually use pair programming extensively and successfully. After years of working for startups and large banks, I have not seen one. I am, however, a huge believer in involving more than one person in the design process of any important module.

      As much as I enjoyed this post, I have to say that there is no single methodology for running software projects. Different things are involved in building a web application, a super-fast algo trading system, and a google search engine. I prefer adopting my “methodology” to the type of a project I work on and the type of developers I work with.

      1. I’m honestly surprised—there are people who would hire programmers without making them prove they can, well, program?

        The problem is, there are plenty of “programmers” who can’t really code at all. Sometimes they even manage to almost sound smart, at least until you ask them to talk low-level details, or worse—actually lay down some code.

        I have personally witnessed more people fail than pass a trivial pre-interview programming quiz.

        More on the subject:





        There’s a big difference between talking the talk and walking the walk.

  36. Anyone else getting sick of all the guest posts?

    This article would have been improved by an explanation of pair programming.

  37. Great Post, reminds me a little bit of the 37signals books. This post and those books can totally apply to a much broader market than programming alone & have helped me in my industry.

    My business partner and I have worked together since (his) day one… mainly cause I had to train him from scratch. Now though he’s up to speed and I find when we get together to hammer out work, I alone get a minimum 2x as much done, same with him. Thus in 1 full day our company gets a minimum of 2 full work days out of each us or 4 days of work total! When I work alone, I’m not nearly as productive.

    Some other people in our company have started teaming up to tackle issues together. However, recently 2 people teamed up together who each have little experience (1 of them lied in the interview and claimed a lot more experience). It’s like the blind leading the blind. I think if people are paired together to work it either needs to be mentor/mentee type situation or both being knowledgable in different areas. It needs to be that each persons strength compliment the others weaknesses. Then you really crank out the work!

    Thanks again for the post & comments.

  38. Mr. Ferriss, I think you mentioned a good book for an introduction to programming, perhaps on an episode of the Random Show…? Would you perhaps share what the book was? Else I’ll have to re-watch some episodes (not like that’s a bad thing.

  39. I think it’s worth noting that Pivotal Labs, as far as I can gather from their Web site, primarily sells agile training. It’s always good to know where your advice is coming from.

    There is definitely some good advice in here, but this article has some issues.

    My coworkers are far more distracting than Twitter. At least I can exit my Twitter client; I can’t exit my coworkers!

    Owning a piece of code doesn’t mean no one else can ever see or touch it or ask me how it works. It just means that, right now, I am ultimately responsible for making it work. Reading source written by others is an essential programming skill anyway, so it seems weird to act like it’s impossible.

    We can’t rid ourselves of specialists just yet, at least not everywhere. These people who do a handful of scripting languages, Java, and SQL often have a hard time debugging into an OS kernel, for example, which is fine if you’re writing a trivial Rails app, but not so fine when you’re stuck tracking down really weird timing issues on a server.

    Finally, I highly recommend reading Joel Spolsky’s “Five Worlds” article. Not all programming advice applies everywhere.

    1. (Disclosure: I’m a Pivotal engineer working in Singapore.)

      While training is a component of what we do at Pivotal, our focus is on *shipping* software. The training we do is in the context of working together on production systems.

  40. Pair programming has its dangers and pitfalls too. You can end up with one person doing all the work, while the other one spends all the time on twitter, cell phone or facebook.

    Also, having everyone be generalist in the sense that everyone understands every bit of code in the entire product is unrealistic if you work on a really complex product. Where I work we have multiple UIs (CLI, fat GUI, Web UI) we work with multiple databases (Oracle, DB2, DB2/AS400, MS SQL, Derby) and our software runs on Solaris, Linux, HPUX, AIX, Windows and OS X and has complex client/server architecture.

    Expecting everyone to know every platform equally well or every part of the product well is just unrealistic. It also goes against the human nature. Some people love doing Web development, some love doing UI design, some love databases, some love sitting in the guts of the server etc. These people will naturally excel at what they love, and others will not be able to keep up with them. This is why you should let people specialize, but you should not let them live in the bubble where they write code in isolation and don’t care what the rest of the team is doing.

  41. Hi Tim,

    The posts that I find most inspiring are your ‘Engineering a “Muse” volumes: Case studies of successful cash-flow businesses’.

    Love to read how other people have setup their businesses. Not only do you learn something from their stories, it also motivates you to take the leap and start your own business.

    Any chance you’re going to do a China special? As someone living in China myself, I would love to hear your thoughts about the Middle Kingdom.

  42. Good article one problem. The so-called “myth #2” is actually a fact; developers aka knowledge workers ARE IN FACT more productive when they can work in quiet conditions and can concentrate on a problem without interruption.

  43. I’ve just finished 4HWW. I fail to see how you can achieve this with a family. I have raised 5 children. I don’t see your ideas as possible, especially if you want a committed family structure. Any thoughts?

    1. Ian- There are several case studies in the expanded edition of the book on families who have made this lifestyle (or certain aspects of it) work for them.


  44. While certainly interesting, this info is hardly anything new in the field. People have been raving about Agile for the past 5-10 years. We even learn Agile practices in Uni where I study…

  45. First time in your blog and really feeling great to read such an interesting post! I’ve one of my friends who used to work at Pivotal Labs and I’m going to share this link with him!

  46. From my experience: pair programming is useful, both for mentoring and just working with someone around your skill level. Your brain works differently when you have to verbalize what you’re doing.

    Pairing requires much more mental effort though, and for us it seems to work better when we do it no longer than for 1-2 hours a day. I doubt it’s sustainable doing it for an entire work day.

  47. I think what really strikes me in this article is the first myth. Software development is a team work effort and not just an individual effort. I think the other thing about working as a team is that the team must learn how to work together.

  48. Tim,

    My son loves your books. A question. He is 18 years old, 6’4″ and 154 pounds. Has always been way skinny, which is okay, it’s his genetic build.

    But what he needs is a few pointers as to diet, given he will be growing probably until age 22 as many males are wont to do. Your diet is great for the adult who has finished with the biological cell proliferation of their formative years. What about the growing adolescent to adult stage?

    Any thoughts?

  49. Interesting take on the specialist/generalist debate. We’ve been having this on me team lately. As an entrepreneur, I love generalists . . . but my business would be in real trouble without some highly trained specialists. I think the important part is to hire specialists who are still willing to dive in and learn new things.

  50. Two fantastic articles in the Financial Times this weekend. One, includes comments from yourself – “Invasion of the body trackers” by April Dembosky, the other, “Kids are the perfect excuse” by Simon Kuper – is all about creating a flexible work schedule. Great stuff.



    Loved your books and love the blog, but took exception to encouraging people not to read newspapers and to ask other people fill you in on what is in the news. Sitting in front of a computer screen is often ‘lazy’ behavior, as you rightly point out, but depending on others to fill you in on what is happening in the world is worse than lazy.

  51. Does that mean a non-programmer can just hire guys at Pivotal Labs and create a killer web application and be a billionaire?

  52. Tim, jiujitsu train with my friend David Meyer, the fittest 48 year old man you have ever met. He helped train Jake Sheilds for Jake’s latest fight. David is the World Gold Medalist in BJJ grappling the past three years in his division. He is in Sausalito, and knows of you. He trains at Fairtex in the city.

  53. Briefly about us: we’re a small start-up that helps other start-ups get to market very fast. My own background is in build enterprise systems (not applications — systems). Been doing this for a quarter-century. Have launched a half-dozen start-ups of my own (most of them failed :-)), and have worked at 2 of the world’s 3 largest software companies as well.

    The above advice is good for relatively simple applications, and Twitter, Groupon, etc., are simple. Their complexity stems from keeping the underlying infrastructure stable, scalable, etc., and those are totally different skills than just writing a simple application.

    As another poster above mentioned, doing anything serious or deep, requires specialization and concentration. Let’s say someone developed a new algorithm to compress information 100 times smaller than ‘zip’, I can assure you that sitting with another person and sharing a screen while implementing the new algorithm would be futile.

    When addressing deep problems, the correct team approach is to conduct frequent and thorough code reviews. This socializes the code and algorithm, and exposes it to constructive criticism.

    When hiring, one has to optimize the resources based on budget. Ideally, one wants to hire a specialist who can generalize, and a generalist who can specialize when necessary. That said, it would be a phenomenal waste to have a Windows/ASP.net specialist learn the intricacies of the LAMP stack. So use common sense. Don’t hire people who are not willing to learn, and who have no interest in stuff outside their ‘domain.’

    And while on the subject of the generalist, I’ll go out on limb and say that every successful engineer also needs to think like a business owner. At our company, every engineer (over a period of some years) is expected to think about whether a given feature or engineering strategy will lead to the customer’s eventual success or not, and accordingly, offer feedback. By no means are we even close to where we ought to be as an organization, but we’re working towards that goal. I’d urge you to cogitate on the following article:


  54. Dear Tim,

    I am in the Bay Area meeting with people such as Dave McClure and was wondering if you would be interested in grabbing coffee for 15 minutes within the next week. I’m a fellow tango dancer and think you might be interested in what I am working on. Feel free to send me an email if you’d like to meet up.



  55. Different kind of software developers are like different kind of doctors. They share a lot of knowledge and skills but specialisation matters. Would you let a generalist doctor do neurosurgery on you? Having generalist software developers is all well and good as long as having massive f**k ups is all right.

  56. Great post. Another factor to consider: time of the day. I find that I have a few hours in the morning when I’m super productive, and a few hours in the evening. The afternoon is not a great time to get creative work done. I usually use the afternoon to go on a run or read. I imagine the most productive people take advantage of their natural creative energy cycles.

  57. Its always good to bring attention to the problems one wants to fix. I wish I would have learned the lesson of dealing coders a long time ago. With my experience of not knowing code and having to hire coders, I can definitely relate.

  58. Basic question from 4HWW, not really related to this post, but I’d appreciate some advice from people further along in this process than me.

    I’ve generated several reasonable muse ideas – one or two are unique. My concern however is that after just a few months of production, my product will be offered by another, for 1/20th of the price, as stated in Tim’s book. QUESTIONS: Can one maximize profits in that short time-frame to make the project worthwhile? Does it require a super expensive marketing blitz? Secondly, is there a way to stay competitive without rolling over and cutting prices?

    Any advice would be stellar! Thanks.

  59. I am an avid fan of Tim. I usually don’t read books, but I am on my 4th time reading “4 Hour Work Week”. Each time I read it, it’s like reading a new book. It’s fantastic.

    Well, per Tim, I have tried to create a product that will opertate auto-pilot.

    I am proud to say I have created, in my opinion, a revolutionary product that will change the hair industry.

    An all natural hair straightener/smoother. But I don’t know what to do with it. I have a chemical MSDS report, it is currently being tested by a hair product lab, provisional patent, etc. People who have tried it, love it.

    But I don’t know what to do with it. I am not good at marketing and I was thinking of licensing my product or just selling it.

    It is excellent for all hair types. But I honestly don’t know what to do. I know that in the right hands it will make someone hundreds of millions.

    I am open for any suggestions. . . .


  60. HI –

    A simple question. I like a good soy latte in the morning (1/4 cup).

    Can I use Almond milk instead?

    Thank you.


    Ali Goldman

  61. Don’t write about things you don’t understand because you clearly have no experience with REAL programming.

  62. Hey Tim, wanted to give you another progress photo – 4hr body is great – I am having so much fun now – I am running half marathons like a walk in the park and started bike racing. Came in 3rd place last week in my first sprint race at the Velodrome. And I turn 35 next week. Just amazing.


    1. I actually think my back photo is more telling: http://www.sixpeeps.com/18weekback.jpg

      Hey Tim, I’m running a groupon feature for my photography workshops out in San Fran pretty soon. Just a reminder, I wanted to hook you and your camera-wielding buddies to a free 2 hour crash course. Everything you’ll need to start taking better photos ASAP. We’ll be in touch.

  63. Hi Tim,

    Great post. The part about getting the most productivity out of a programmer is pretty cool. I probably never would have thought about putting it on paper like that. I think it would take some creativity to implement, but do know it works.

    I havent necessarily practiced the technique on purpose, nor do I write code, but do know when you have two people looking at one screen, it is very effective.

    A business partner/friend and I use this technique every couple weeks to tackle problems in our own little businesses (if you can call them that).

    We will both get on the phone, and then use mykogo to do a screen sharing session. We are not sitting at the same location, but we might as well be. All distractions are turned off while we are hammering out a problem, and by the end of a half hour session, one of us has solved a big sticking point on our business/process. On our own, we probably would have wasted hours, if not days letting something small hold us up. Getting another set of eyes on the problem helps exponentially.

    So you dont even have to work in the same office to get this kind of super productivity.

  64. Tim,

    In your book you mention that eating Skittles will raise testosterone levels, what you don’t mention is how many to eat, I really love me some Skittles, is the whole bag a little too much, how many do you eat.

    Also, in your book you say to eat between 10-15 bananas a day, seem’s a little extreme, but if your doing it it must be okay, you also say to not peel the bananas and to eat them whole, I’ve been doing this and they don’t taste real good, but if you are doing it it must be good.

    You Rule

      1. Tim,

        In your book you say to use ice packs to help you lose weight. What about those of us who are allergic to ice, is there an alternative that works just as well? Do frozen peas work ok? What if I’m allergic to peas? I saw an ad on the internet that said ice harvested from glaciers in Antarctica helps you lose weight faster than regular ice. Where is the cheapest place to buy Antarctic glacial ice? In your book you said to use my own judgement and think for myself. Can you provide detailed step-by-step instructions on how to think for myself?

        Thanks, You’re the Best!

        – B

  65. I’m a civil engineer that ended up working in software development 14 years ago, I worked for internet startups and worked almost 8 years for one of the biggest software companies here in Colombia, and I was never able to convice the bosses that software is not like building bridges.

    I worked 1 year as a civil engineer and my 6 years of collegue taught me a lot of classical engineering, and believe me, it doesn’t apply to software at all, but since most software companies are run by people that blindly believe that software is engineering in its infancy it was an impossible task, too many fights, too many arguments, until they wanted ALL the use cases to be designed in full with class diagrams, sequence diagrams with all the possibilities designed before any line of code.

    That’s when I gave up an decided to start working on my own with agile methodologies, believe me, I tried 8 years but it was just impossible

  66. Hi all,

    I was wondering if anyone would have suggestions for a college student who’s interested in moving to silicon valley after graduating and doing investing/advising startup work. I’ve browsed the following:

    -My Start-Up Life: What a (Very) Young CEO Learned on His Journey Through Silicon Valley

    by Ben Casnocha

    -Founders at Work: Stories of Startups’ Early Days

    by Jessica Livingston

    -The Startup Game

    by William Draper

    -The Art of Product Management

    by Rich Mironov

    -Start-Up: What We May Still Learn From Silicon Valley

    by Herve Lebret

    Let me know if you think anyone one in particular is a good starting point or have any other suggestions.


  67. Very interesting!

    It seems the myth of a quirky hiring process goes hand in hand with the myth of specialization. If you interview a dynamic, intelligent (that includes social intelligence!), outside the box thinker who may be a specialist in only one thing or even a generalist, he can potentially do more for your company than a highly specialized employee.

    On the flip side, if a startup peremptorily dismisses candidates missing certain qualifications they’ve set in stone, they may be shooing some of the brightest and most teachable workers away.

    Welcome to the age of the generalist.

  68. Hey Tim,

    Can you give us some easier ways to get rich? All this computer start-up stuff makes my eyes glaze over

  69. Another solid article Tim, thank you. Man this hit the nail on the head for me. I’ve been working on my muse for almost a year now and am having one hell of a time getting the pieces to line up. Do you have any advice on how to motivate programmers to follow-through? I work with some outstanding people, but find their follow-through and attention to deadlines is waaaaaayyyy off and I am at a loss with how to motivate them to come to the table as far as “getting it done” is concerned.

    Do you recommend any well documented companies/programmers who can do websites like squeeze pages, affiliate marketing blog pages, etc in the fitness industry without mondo-headache?

  70. In college I was as computer lab assistant. This involved sitting down with a 1st year student, his (most were male) textbook and assignment paper, and the garbled mess of code on screen. I had 5 minutes to get progress moving again or turn it over to the dedicated teaching assistant. They changed programming languages every few months. It was better training for the real world than most of my formal CS classes combined. Of course I mention this story in job interviews…

    Tim has conditioned us (via 4HWW) to prefer location independence and getting the work done in as little time as necessary. Now this other guy is talking about being glued to another programmer all freaking day! How can we reconcile this? I suspect it might be possible with remote screen sharing tools. Maybe a few hours of intense ultra-productive work can be scheduled together, and solo tasks can be more flexible. But I can see the idea as a whole being used to justify scrapping all remote work. (Alas!) Any ideas?

    Also: How does this apply to a one-person company, or to a distributed virtual operation? Similar issues to the previous paragraph.

  71. This is common sense like a lot of your stuff Mr Ferriss. Kudos to you for cutting out the bull.

    I own a company which has 2 programming departments which only make products for our own use and we’ve been around for a long while now. I can confirm that we work exactly as above.

    We are based in low cost countries, we never hire ninjas (in fact we purposely hire beginners so we can train them easily into our system), our programmers work as a team and every job has a proper spec so anybody can pick up the job if someone leaves. Our staff are 9 to fivers – I’ve never seen one burn out.

    The biggest problem in our company is staff retention. Because we train the staff so well they usually want to leave for better pay, but that’s ok. Once they become a guru we don’t want to afford their pay requirements.

  72. so… a blog post full of nonsense, and loads of people who do not understand a thing in software praising for another solid article and thankful for a revelation. I guess it’s a good feeling to have so many fanboys.

    If you are interested in developing software as a business, please spend some time reading at least couple books on the subject. “Peopleware” and “Death March” are a good start.

  73. agreed. employees should be well rounded.

    i’m also waiting to see ways to compensate employees for more abstract things; like creativity, enthusiasm, positivity and innovation. these should be measured on a daily/weekly basis and factored into pay.

    thanks for the post,


    1. Suppose I’m your employee. Suppose I’m generally a nice person, and I’d hate to ruin someone’s day by pointing out the fatal flaw in this great idea he or she just had. Suppose I’m also optimistic about my own ideas, and don’t evaluate them as critically as I should. Both of these could lead to a lot of wasted time on ill-conceived ideas. Think Microsoft Bob.

      In this situation, for my own personal development I might want to work to acquire a healthy skepticism and to be more willing to offer criticism where it’s needed. However, you’ve just called us all into a meeting room and told us we’re all getting bonuses, but there’s a catch: the amount of these bonuses depends on how well we measure in “positivity” and “innovation.”

      Now, financially, it’s a bad idea for me shoot down anyone’s ideas. I should flesh out more of my own ideas to be seen as innovative, and I should encourage others so I’m seen as positive. Well-intentioned criticism runs the risk of being judged as negativity, which would very directly impact my pay, or worse: you could just decide to fire me for measuring badly on your newly implemented scale.

      The real tragedy is that I’m no longer thinking about being a good person doing good work for its own sake. Instead, I’m wrapped up in this silly game to look good on an arbitrary set of one-size-fits-all metrics that happen not to fit me so well after all. I’m playing a game for cash rewards instead of doing my job.

      For another perspective, if you have about 40 minutes to kill, check out http://www.thersa.org/events/video/vision-videos/dan-pink-drive. If you can’t spare 40 but can spare 10, try this instead: http://comment.rsablogs.org.uk/2010/04/08/rsa-animate-drive/.

      I also recommend reading “Incentive Pay Considered Harmful” (http://www.joelonsoftware.com/articles/fog0000000070.html) and “The Econ 101 Management Method” (http://www.joelonsoftware.com/items/2006/08/09.html).

  74. I think shortcuts are the sure way to failure. Even if shortcuts work for certain things, it will make things worse sometimes. Running a business with shortcuts and all the push button stuff out there will also put you on the road to failure.

  75. I contacted Pivatol Labs and did get the feeling that they are very professional, but when a company refuses to sign a NDA (non-disclosure agreement) as Pivatal Labs did it usually menas they are very questionable. Having been burned once before in the past by giving a company an idea of mine ,which they then developed I would NEVER work with a firm that will not sign a NDA. By signing a NDA the company in question (In this case Pivital Labs) is simplu signing a legal document confirming that they would not sell, steal, or further develop any concept or idea that I would lay out to them in a meeting or e-mail. The out right refusal to sign such a document is something that should scare every potential client. I am extremely suprised Tim would endorse a company that could legally do anything they wanted with your thoughts or ideas and you would have absolutely to grounds for doing anything about it.

    That being said I am a huge fan of Tim’s books and blogs and think his web sites are as valuable as any on the internet.

    1. ed.. your right about the NDA stuff, be wary, be scared

      I saw a friend give a talk at a web summit about his brand new geo location advertising platform while twitter/facebook in the audience and a few weeks later… facebook places was born.

      If people want to know your idea, they can find it, if they a customer, otherwise… shhhhhhhhhhhhhhhhhhhhhhhhhh

  76. I have begun to realize that more and more companies are getting savvy about the hiring process. Corporate “cut n paste” structures still exists, but its the start-ups that are truly innovative when its comes to finding stars. It probably stems from the realization that great people help the company grow and don’t just fit a mold to carry out some onerous task.

    I think every innovative company (or those looking to revamp themselves) should have a 3 month “evaluation” process of new hires before they commit them. Anyone can learn to be an automaton and hash some CSS/ HTML, but the real jewels are those with an entrepreneur mindset. This time frame will allow the decisions makers to realize the true mettle of their hires and invest in the hire. Until then, outsource!

  77. Awesome post. As for the specialist vs generalist discussion: I’m an aerospace engineer and anyone who works on highly complex systems (software or mixed disciplines) knows you have to have both. And that finding the balance is essential to success. I agree that you need to have someone or a few people with a broader perspective on the project, but depth is necessary for solving new cutting edge problems which is half the fun of being an engineer (of any kind). The brain power and experience of an individual is limited and you can’t always get the experience you need with people who have spread out their time becoming generalists. So I disagree with the last myth.

  78. I am an ex programmer, selling offshoring, I read the 4 hour work week, and I tried sending work to India, now I work for them, in London, finding work, writing specs, doing ‘mock ups’ of things,India do the bulk of the work.

    how can you compete against a country where a hotel room costs 65pence/cents a night

    tim..you read to need your book again, programming is done in india 🙂