Over the years I've heard a bunch of quotes. Most of them aren't terribly insightful or inspirational but every now and again one sticks. A quote that has meaning to you, one that you embrace and perpetuate to others as ideas and ideals you believe in. Here's a few quotes that I've seen that have "stuck":

"A good engineer learns when compromise is more profitable than perfection" ...Robert Martin

"Talent hits a target no one else can hit; Genius hits a target no one else can see.” ...Arthur Schopenhauer (1788- 1860)

"Far batter to dare mighty things, to win glorious triumphs even though checkered by failure, than to rank with those poor spirits who neither enjoy nor suffer much because they live in the gray twilight that knows neither victory nor defeat" .. Theodore Roosevelt (quoted on the Harvard Business School Admissions website)

"No matter how busy you may think you are, you must find time for reading, or surrender yourself to self-chosen ignorance.” ...Confucius

“Live as if your were to die tomorrow. Learn as if you were to live forever.” ...Gandhi

"If you cannot measure it, you cannot improve it." ...Lord Kelvin

"Intuition is regularly wrong. Let data drive decisions." ...Damien Wintour

"The mass market comprises the pragmatists, those who just want the damn thing to work." ..Geoffrey Moore, author of Crossing the Chasm

"Revenue is the proof of your ability to win customers, which will determine your success more so than your ability to squeeze a few pennies out of your costs." ...extract from Ahead of the Curve

"Before criticising someone, you should walk a mile in their shoes. That way, if they get nasty, they're a mile away and barefoot." Unknown

"The will to win means nothing without the will to prepare." ...Juma Ikangaa, elite marathon runner

"If you’re concerned about scalability, any algorithm that forces you to run agreement will eventually become your bottleneck. Take that as a given." ...Werner Vogels, Amazon CTO

"Logic will take you from A to B. Imagination will take you everywhere." ...Albert Einstein


Meeting Etiquette

As you move up the ranks from technical positions to more managerial positions you invariably find yourself doing less technical work but attending more meetings where issues are discussed and decisions need to be made. Well-run, concise meetings are essential to information flow and collective decision making however I've attended far too many meetings that fail to observe what I consider basic etiquette for meetings. Accordingly, here's my short list of things to do to make meetings more productive:

  1. Before initiating a business discussion, know your goal!
  2. Non-verbal communication is a big part of your message!
  3. Respect and listen to (but don't always follow) other peoples' opinions
  4. Be conscious of how much time you are taking in the conversation.
  5. Time-box open forum discussions to force people to be concise.
  6. Don't be afraid to cut people short if it's heading in the wrong direction.
  7. Evaluate the personality of the other attendees, and adjust communication as necessary.i.e. Don't talk techno-babble to the CEO.
  8. If you invite subject matter experts to attend the meeting let them speak to those issues - they're the SMEs right!
  9. Before agreeing to attend, ask 3 questions about a meeting:
    • What is the purpose?
    • What is the agenda?
    • Am I really needed?
  10. Don't use meetings to grandstand - you'll lose respect fast
  11. If you are providing input to the meeting, come prepared so as not to waste other people's time.
  12. Take notes - reliance on human memory is a sure path to failure.
  13. Prefer quick hand-drawn diagrams on the whiteboard (which can later be photographed/scanned and circulated) over elaborate PowerPoint presentations. You'll get the job done just as effectively an order of magnitude faster.
  14. Prefer video- and tele-conferencing over long-distance travel but make sure the technology works beforehand.
  15. At the end, summarise action points and key decisions made so everyone is on the same page.
  16. And finally, be on-time. You are wasting other peoples' time by being tardy.


Smart and Gets Things Done

Smart and Gets Things DoneI've long been a fan of the succinct and insightful thoughts of Joel Spolsky (http://www.joelonsoftware.com/). Joel is a Yale-educated ex-Microsoft employee running his own software development company, Fog Creek, in New York.

I recently came across a book he wrote, Smart and Gets things Done, and decided to invest time in reading it. It's only 150-odd pages so you can easily get through it in less than a week - Bill Clinton biography-sized bricks don't endear themselves to me that much.

According to the blurb on the back of the book it is "a guide to attracting, recruiting, interviewing, and hiring the best technical talent."He covers this topic skilfully with useful insights, though I must say that I don't agree with all his observations. As with most of Joel's writing, and as can be seen from the long list below, there are numerous gems to be found in this book. For the record, here are the more critical issues Joel identifies that I feel strongly about (both positively and negatively).

Things that Joel mentions that I think are important and strongly agree with him on:

  • Good design adds value faster than it adds cost. Joel bases this observation on the fact that software duplication is essentially free thus development costs can be apportioned over the units sold resulting in negligible per unit incremental cost.

  • There no place in the software industry for low-cost providers, for the reasons given above. And industries that need to develop good software should not be trying to reduce the cost of programmers.

  • The difference between good and average programmers is significant. Great programmers are 3 to 10 times more productive whilst only costs 20-30% more. (And kudos to Joel for providing empirical productivity data from a reasonably well controlled experiment to backup this notion). On that topic- I'm a firm believer that data should drive the decision making process! If you don't have the necessary data, think about how you can get it. Hint: hallway usability tests, split A-B testing, customer involvement, web server log files, etc.

  • There are benefits to using the smallest possible team, since co-ordination and communication is overhead for the team.

  • For companies whose success is dependent solely on the quality of the products/service they develop, you'll need rock-star programmers who can "hit the high notes". If you work for an Internet startup this applies to you! If you're an executive at an Internet startup tattoo "quality is critical, ergo great people are critical" to your left fore-arm but you needn't go for David Beckham's kanji script.

  • The software marketplace these days is somewhat of a winner-takes-all system. That is, it's a hits-driven business rather than a long tail play.

  • If great programmers don't want to work for you they won't. So learn what they want and go about trying to give them it. The book details these issues fairly well.

  • You're not going to get great programmers if you don't respect them.

  • Programmers pay close attention to the intellect of the interviewer. Dead right. Talent attracts talent! Great programmers have a yearning for learning and being surrounded by smart, successful people as this helps them believe they will learn new tricks, which of course they will.

  • Programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can't.

  • Some technologies are just harder than others. If a developer can write assembly code, or is a whiz at pointer arithmetic in C++ they are going to be able to pick up <insert-desired-high-level-technology-here>.

  • Requiring programming and/or logic assignments on application are an unnecessary obstacle.

  • Aptitude is more important than experience, since the software industry moves relentlessly fast. I'd add that the only allowable exception to this is when you are hiring short-term contractors that need to be up-to-speed in the technology being used for the project.

  • Look for programmers who are smart AND who get things done. Both attributes are important here! I know it sounds elitist, but this expression, which is also the title of the book, essentially sums up the whole recruitment process nicely!

  • Being a blow hard or quiz-master interviewer is highly ineffective. These days we all have a Google search engine at our fingertips, so knowing the process is more important that the detail. If the applicant knows the Karatsuba algorithm is a slightly more efficient way to do multiplication of large numbers don't penalize them for not being able to recite the precise approach! The key point is knowing what the algorithm does on a general level and when to use it. 

  • Smart people are passionate about the projects they work on.If they aren't they would have quickly left the project and subsequent discussions about it become critiques of their former boss's lack of management / technical skills and why they couldn't wait to get out of the project.

  • Most of the time at an interview should be left for the candidate to prove they can write code (on a white board or paper). Speaking from experience :-)great programmers like to show off their skills and will relish the opportunity to write code for you.

  • If the basic concepts aren't so easy that you fly through them, you're not going to get the big concepts. The corollary to this is that a candidate that can confidently talk to you about more advanced topics, say for instance... why lexically-scoped closure makes anonymous delegates in C# way cool, is more than likely going to be able to understand simpler concepts.

  • The best programmers have an aptitude for dealing with multiple levels of abstraction simultaneously. I agree, and it's for this reason I am biased towards programmers who come from a mathematics or physics background because in the course of their undergraduate study they've already had to deal with copious amounts of abstract concepts.

  • Most recruiting is structured as if the company has something precious (a job) that the individual wants. When hiring great developers the situation is completely reversed. That's simple economics. The demand for great programmers outweighs the supply of them. Remember that!

Things I can't say I agree with Joel on:

  1. Joel is still adamant that a software company needs to be adept at "converting capital into software that works", rather than pursuing an idea that solves some problem which hasn't been solved before. I don't completely agree with this and here's why....Without a good idea, great execution is all you have. In some cases that, and first-mover advantage is good enough to succeed. i.e. Amazon selling books online. In other cases it's not. But a company with BOTH a great idea and superior execution is far more likely to succeed than a company without both components, so why wouldn't you pursue both? "converting capital into software that works" sounds very much like Joel suggests focusing on user-driven execution which is a great thing to do but if it's based on a lousy idea you'll end up with a product/service no-one wants or needs.

  2. Great software developers are rarely on the market. Don't agree. Many great programmers are attracted to the life of an independent contractor, for financial reasons, for the benefit of selecting what work they undertake and for the ability to jump from industry-to-industry and organization-to-organization sucking up as much new knowledge as they go. Due to the short-term, project-specific nature of this work, these folks are on the market a great deal more often than "rarely".

  3. Private offices make software developers more productive. Although Joel cites several respected publications, I can't say I agree with these findings from the viewpoint of optimizing the team throughput rather than the individual productivity. Because most software is developed by teams with no one individual having complete knowledge of the system in his or her head, team members need to communicate to share the collective knowledge of the system. Putting developers in private offices, whilst giving them a bit more quiet time for uninterrupted development work, actually inhibits the free transfer of information and ideas between the team. Developers packed into relatively close confinement will mix more freely. Yes that does bring in the opportunity for more distractions but that's better than having each developer being an island unto themselves.

For the mathematically astute you'll notice that I'm agreeing with Joel far more than I'm not - well OK you don't need to be George Danzig to figure that out. So in summary I can confidently recommend this book to anyone who is engaged in the practice of hiring programmers for a company that need to produce great products. It's not a difficult read and is choc-full of gems you want flowing through your hippo-campus.

Great job Joel ! Hits the mark nicely.

PS. Here's a link to it on Amazon

Next »