tag:blogger.com,1999:blog-135021602024-03-07T19:50:23.772-05:00Software Rants & Other MiscellanyJTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.comBlogger42125tag:blogger.com,1999:blog-13502160.post-83347732440687769672012-09-24T08:03:00.003-04:002012-09-24T12:01:23.484-04:00The Attrition Funnel<br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">My post on the <a href="http://blog.jayteebee.org/2012/09/the-engineering-recruitment-anti-funnel.html" target="_blank">Recruitment Anti-Funnel</a> touched on the idea that one of the worst things you can do for hiring is to lose good people. The downside of losing good people should be obvious, but let’s state it explicitly in terms of recruiting - when you lose someone good, you suffer multiple losses for your recruiting efforts:</span><br />
<br />
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif;">you’re short one person (obviously) - however many people you were trying to hire before, now you need one more. Depending on how your funnel converts, this could require adding a few hundred more people to the top of the funnel.</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">you risk having someone out there in the market telling your potential recruits that your company is not a good place to work</span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;">more likely, even if that person isn’t telling people that your company is not a good place to work, LinkedIn makes it clear that they left; in the absence of information about why someone left, outsiders will assume the worst, taking any attrition as a sign that your company is not a good place to work.</span></li>
</ul>
<br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Of course, this ignores all the other negative effects to your team and your company that come with losing good people, this is just how losing good people makes recruiting harder for you.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">As with bad recruitment practices, I have spent enough time with startups over the past few years to see a number of common bad habits that lead to attrition among engineers - let’s call this your Attrition Funnel, the gradual sequence of steps you take to move people from “great employee” to “former employee”.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><b>You’re managing down to people. </b>Engineers in today’s market are less like traditional employees and more like free-agent entrepreneurs; each day they are making a conscious choice about whether to keep working at your startup, whether to return the phone call from the recruiter who has been hounding them, whether to IM a friend at a cooler startup to line up a new job, or whether to just quit and finally figure out doing their own thing.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">An engineer in this mindset isn’t focused solely on the technical challenges that are directly required of them in their role - they are constantly evaluating every aspect of the company to assess whether the company is headed in the right direction. They are reviewing every metric they can get their hands on (which, by virtue of their access to internal datastores, is much more than someone non-technical might expect). They are asking questions about marketing strategy, product priorities, and sales compensation schemes.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">In that environment, I am always flat-out gobstopped when a CEO asks me, “How do I get engineers to just stay focused on the technology problems instead of the always poking around the rest of the company?” In the pathological case, this comes out more like “No, I am not going to explain the company strategy to the engineering team, their job is to write more code and let me worry about the strategy!” </span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">For an executive dealing with engineers, this phenomenon is perhaps exacerbated because it is a behavior somewhat unique to engineers. I’ve rarely seen an individual contributor salesperson ask a CEO challenging questions about technology strategy, for example. This may be a matter of engineers flexing their market power (eg, “I need to know this to assess whether I can be at a company with better prospects”), or it could be a matter of a different perspective on the part of engineers, I can’t say. For executives in non-technical parts of the company, the glaring difference in behavior between engineers and non-engineers can lead to the conclusion that somehow the engineers at your company are just exceptionally difficult to deal with and intent on learning about areas you think they shouldn’t be concerned with. Trust me, engineers at every startup want answers from the executive team about every aspect of the business.</span><br />
<br />
<span style="font-family: Arial, Helvetica, sans-serif;">In any event, leaders in startups need to be prepared to <a href="http://blog.jayteebee.org/2012/08/leadership-mechanics-handling.html" target="_blank">handle the challenging questions</a> that come from their engineers, regardless of the topic. Failure to address the questions from your engineers will make them feel like you are treating them with less respect and transparency than they are entitled to; this is a shortcut to stripping them of a sense of empowerment, and makes it very easy for another startup to recruit them away with promises of real impact and access to the executive team.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><b>You’re churning on strategy.</b> It’s become very trendy in the past twenty-four months or so to pivot, to make a radical change in strategy that redefines a company. Pivoting shows that you’re lean! You’re always learning! You’re nimble! Still, there are a lot of ways a pivot can work against you in terms of attrition. Sometimes, a pivot is really just flailing, as <a href="http://steveblank.com/2012/08/27/vision-versus-hallucination-founders-and-pivots/" target="_blank">Steve Blank describes well here</a>. </span><br />
<br />
<span style="font-family: Arial, Helvetica, sans-serif;">I don’t want to get into the debate about how to avoid bad pivots, so, for sake of this discussion, let’s assume that every pivot you’re considering is a stroke of strategic genius that will set your company up to double growth rates, triple revenue, and give everyone a unicorn.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Even in the case of the perfect pivot, a strategy change can have a big impact on employee morale and hence, attrition. A large part of the decision to join startup, much more so than a big company, is subscribing to a vision of where that startup is heading and how it is going to change the world. When the strategy changes, employees can be left feeling like they were misled or, in worst case, lied to, about the prospects of the original vision.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">In some sense, this issue is a concrete case of managing down to your engineering team - they want the opportunity to evaluate a new strategy, understand all the factors that went into it, give their input, and decide whether they are signed up for this new vision. In the best case, the CEO or their designee should take the time to meet with the engineering team as a group or individually and really sell them on the pivot. The pathological case I have witnessed too many times is the CEO who says, “This is the new strategy I’ve figured out, this is what we’re doing. Anyone who isn’t ready to sign up for this right now is just not a team player.”</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><b>You’re not paying market rates. </b>This is the easiest mistake to avoid and the one that pains me the most to see. I’m on the record that I think <a href="http://blog.jayteebee.org/2010/11/im-calling-it-now-engineering-talent.html" target="_blank">engineering compensation has gotten out of control</a>, but for the foreseeable future, at least, as you’re budgeting for your startup, you have to plan for the fact that engineers are expensive. If your financial plan depends on people being willing to work for you at a salary 20-30% below what they can make at a similar-stage startup, you are going to be in trouble.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">I intentionally did not highlight this issue in the post on recruiting, because I have found that many great engineers are willing to take a below-market pay rate when joining a new startup, even as compared to similar startups. As such, paying below market doesn’t always hurt your recruiting efforts. This is a good thing for everyone involved - you hire new engineers, give them big equity packages, and incent them to make their equity worth gobs and gobs of money. In my experience, this situation can usually last for 12-18 months without issue. After that, if there’s no market confirmation that the equity is increasing in value, people naturally want to see an increase in their salary. If you’re not ready to bring salaries up to market rates, you can count on people starting to look around.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Figuring out how to assess the appropriate market rate can be a challenge, as good data on comparable startups is generally difficult to find. The recently-released <a href="https://blog.wealthfront.com/startup-employee-equity-compensation/" target="_blank">Wealthtfront tool</a> is the most credible and useful way I’ve seen to get a quick gauge for what you should expect to pay people.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">Even the Wealthfront data is pretty broad though, making it tough to assess how your compensation compares to your immediate peers. The most pragmatic way I know to assess where you stand relative to the rest of the market is to collect data through the hiring process. When negotiating offers with engineers, many people are willing to disclose the details of their competing offers. Every competing offer you can learn about is a concrete piece of evidence showing how your offer compares to your peer companies for the same employee. Over time, enough data can help paint a pretty clear picture of the comp structure at your peer companies.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><b><br /></b></span>
<span style="font-family: Arial, Helvetica, sans-serif;"><b>Of course, there are innumerable other ways to build a strong Attrition Funnel. </b>The spirit here is not to be exhaustive, but these are the mistakes I have seen startup leaders making over and over again that are most easily avoided and most likely to build a strong path of good engineers walking out the door for better opportunities.</span>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com1tag:blogger.com,1999:blog-13502160.post-16272173187742458482012-09-18T11:17:00.000-04:002012-09-18T11:18:44.603-04:00The Engineering Recruitment Anti-Funnel<b id="internal-source-marker_0.9810850832145661" style="font-weight: normal;"><span style="font-family: Arial, Helvetica, sans-serif;"><span style="vertical-align: baseline; white-space: pre-wrap;">I learned yesterday that the referral bonuses for engineers at some NYC startups are starting to get huge - one prominent NYC startup is now offering its employees $10,000 for each successful referral. This is a classic “throw money at the problem” solution to attracting engineers, and, while economic incentives certainly do impact behavior, I doubt it’s going to help enough. </span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="vertical-align: baseline; white-space: pre-wrap;">Hiring engineers is hard, hiring great engineers is harder, and hiring great engineers at scale is impossible if you insist on doing it wrong. Still, I don’t want to write Yet Another Blog Post On Hiring Engineers, so today let’s talk about what I’m going to call the Recruitment Anti-Funnel.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="vertical-align: baseline; white-space: pre-wrap;">So much of hiring these days is focused on the funnel - increasing a referral bonus, for example, is meant to increase the number of applicants at the top of the funnel, using external recruiters is meant to be a way to get a higher-quality funnel, faster turnaround time from interview to offer is meant to reduce leakage from the funnel, etc. The thing that I see these days is that so many startups are doing so many things outside of the funnel that just broadcast the message “Good engineers should not work here,” and I don’t think they have any clue that they’re doing it.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="vertical-align: baseline; white-space: pre-wrap;">In no particular order, here are the Anti-Funnel patterns I see over and over again.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">You’re churning through the good engineers you already have</span><span style="vertical-align: baseline; white-space: pre-wrap;">. This is an oft-overlooked factor, but many big startups in NYC have burned through a number of great engineers, people who have moved for any number of reasons, usually along the lines of unhappiness with the company, the product, or the team. Every time you lose a good engineer, you’re putting someone out into the marketplace who is willing to tell other engineers to avoid your company. This message transmits over drinks, at meetups, in IM conversations - “Oh, you’re talking to X? Ryan worked at X for 8 months and said they have no clue, I’d stay away from there.” There really is a </span><a href="http://medriscoll.com/post/9117396231/the-guild-of-silicon-valley"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">guild of software</span></a><span style="vertical-align: baseline; white-space: pre-wrap;"> (and it exists outside the valley!), and the members will warn each other off of joining a company that’s burning through good people.</span><br /><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Really great technology startups fight tooth and nail to keep their good people. If a good person is unhappy, that is more likely a problem with the company than a problem with the person.</span><br /><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">You’ve hired an engineering team of “band-aids”. </span><span style="vertical-align: baseline; white-space: pre-wrap;">Many non-technical founders, stuck between the rock of “can’t find any good engineers” and the hard place of “have to ship product to keep the board happy”, take the cheap way out and fill seats with any engineer who can string together three lines of PHP. You can convince yourself that this is just a band-aid, something to get you through until you can start to find some stronger people. </span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="vertical-align: baseline; white-space: pre-wrap;">Hiring for band-aids is like choosing the Dark Side of the Force: it’s quicker, easier, more seductive, and once you start down that path, forever will it dominate your destiny. It’s a well-known startup adage that </span><a href="http://blog.guykawasaki.com/2006/01/the_art_of_recr.html"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">B players hire C players</span></a><span style="vertical-align: baseline; white-space: pre-wrap;">, but we less often consider the inverse; I’ve never met an A player or even a B player who wants to join a team of C players. Your band-aid hires become the strongest factor in discouraging strong people from joining your team.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Great talent attracts great talent; bad talent repels great talent.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">You’re broadcasting your complete lack of understanding for how hard it is to build software. </span><span style="vertical-align: baseline; white-space: pre-wrap;">I am constantly meeting with entrepreneurs who show me a development roadmap that should take two years to build, then tell me that if they can hire two or three great people it should all be done in six months. No one pushes as hard as I do to get more things done more quickly, but the practical reality is that software is hard, and until you’ve been through the cycle of building big systems, you really can’t appreciate how hard it is.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="vertical-align: baseline; white-space: pre-wrap;">This pattern is particularly poignant in early stage startups, when the founders are not technical and don’t have good help in hiring for engineers. When you demonstrate to engineers that you have unrealistically ambitious goals for what they should be able to do, you’re advertising to them that coming to work for you means endless nights and weekends trying to live up to ludicrous schedules.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="vertical-align: baseline; white-space: pre-wrap;">Like I said, there’s no good way to learn how hard it is to build software until you’ve built software. If you want to at least get a feel for it, I highly recommend the book </span><a href="http://www.amazon.com/gp/product/1400082463/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1400082463&linkCode=as2&tag=softwarantsot-20"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">Dreaming in Code</span></a><span style="vertical-align: baseline; white-space: pre-wrap;"> - it’s a great non-technical account of how </span><a href="http://en.wikipedia.org/wiki/Mitchell_Kapor"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">Mitch Kapor</span></a><span style="vertical-align: baseline; white-space: pre-wrap;">, the creator of </span><a href="http://en.wikipedia.org/wiki/Lotus_1-2-3"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">Lotus 1-2-3</span></a><span style="vertical-align: baseline; white-space: pre-wrap;">, set out to build a new open source software product with a stellar team and tremendous backing, and, for all intents and purposes, failed.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;">If you don’t understand anything about building software, you can’t attract people who are going to build software.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">You have shitty office space. </span><span style="vertical-align: baseline; white-space: pre-wrap;">This Anti-Funnel pattern is certainly not as lofty than the others, but it’s pragmatic and it’s real. Working conditions matter a lot to good people, and when they come in to interview, they are evaluating your space as somewhere that they will spend 9 to 12 hours a day. No one is saying you have to have offices like </span><a href="http://www.refinery29.com/google-office"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">Google</span></a><span style="vertical-align: baseline; white-space: pre-wrap;">, but </span><a href="http://mashable.com/2012/02/28/foursquare-hq-tour"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">many</span></a><span style="vertical-align: baseline; white-space: pre-wrap;"> </span><a href="http://www.businessinsider.com/office-tour-of-fog-creek-2012-4?op=1"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">great</span></a><span style="vertical-align: baseline; white-space: pre-wrap;"> </span><a href="http://www.businessinsider.com/photos-tumblr-office-nyc-2012-01?op=1"><span style="color: #1155cc; vertical-align: baseline; white-space: pre-wrap;">startups</span></a><span style="vertical-align: baseline; white-space: pre-wrap;"> have great office space. It is expensive, and, if you’re looking at a straight P&L, it looks like a waste of money, but it is a lot cheaper than $10,000 referral bonuses.</span><br /><span style="vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Good office space is expensive when viewed as an administrative cost, it’s super cheap when viewed as a recruiting cost.</span><br /><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="vertical-align: baseline; white-space: pre-wrap;">Now of course, to build a great engineering team, you need to optimize your hiring funnel - you’ll get no argument from me about that. My point here is that you could have a perfect hiring funnel, but if you’re following these Anti-Funnel habits, the biggest referral bonuses in the world won’t be enough to help you build the team you need.</span></span></b>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com1tag:blogger.com,1999:blog-13502160.post-45806527085762127342012-08-27T12:21:00.003-04:002012-08-27T12:21:43.866-04:00Leadership Mechanics: Handling Challenges From Your TeamIf you've been an undergraduate at Carnegie Mellon any time in the last twenty or thirty years, you've been impacted by Michael Murphy. You might not have known about Michael at the time, but he has held a variety of roles in Student Affairs in that time, so to some extent, much of what happened to you outside of a classroom was under Michael's influence.<br />
<br />
When I was at CMU in the mid-to-late 90's, Michael was Dean of Student Affairs, a vast role that included responsibilities for things like housing, dining, and student activities. I could say a lot about great leadership traits I saw Michael exhibit at that time, but one of the things that stood out to me was the way he'd handle students challenging him about various choices made by the administration. I remember one instance as clearly as if it were yesterday.<br />
<br />
As a bit of background, at the time, the campus had two dining venues that accepted our meal plan, and they were both awful. Just terrible. For most of my second semester freshman year, dinner each night was cheese fries, because they were so hard to get wrong.<br />
<br />
Anyhow, at some point Michael was doing an open Q&A with students, and someone asked, "Why can't we have a McDonald's or a Taco Bell on campus?"<br />
<br />
Michael's response was not so much an answer as it was a full treatise defining the pros and cons of having a franchise fast food restaurant on campus. He acknowledged the appeal of having something familiar and consistent, he conceded that it was an option that had been raised and considered on multiple prior occasions, and then proceeded to recite a set of reasons why the idea had been rejected in the past. Fast food menus don't vary, at all, meaning it is easy to get bored very quickly with what's available. Large corporations don't have much flexibility in how an individual franchise works, so the school would have little influence on the operation. It's not clear that the economics of having a franchise on campus would appeal to a major fast food corporation. Putting such a franchise on campus could draw in people from outside the campus community, which is not certain to be the right choice.<br />
<br />
Michael was under no obligation to give a thorough explanation of the reasoning behind the choice not to have a fast food franchise on campus. Given his position, he could have simply said, "We've looked at that idea, it wouldn't work, we're not going to do it." I think though, that his goals as a leader were better served by going through the detailed explanation. In particular:<br />
<ul>
<li><b>He showed the entire audience that he respected their input and responded to it thoughtfully. </b>When you think about it, a group of entitled undergraduates probably didn't deserve that level of respect from a high-level university administrator, and yet he showed the respect anyway. </li>
<li><b>He demonstrated that he had a command of all aspects of the issue. </b>There's tremendous power in simply demonstrating that, as the leader responsible for such choices, he had given it far more thought than his original questioner had. </li>
<li><b>He worked to persuade the audience that the solution they had in mind wasn't as simple as they thought. </b>Whether or not Michael convinced anyone about the right choice to make, he made sure everyone walked away understanding that the choice was not black and white. I think this was particularly valuable because Michael treated the audience in a manner appropriate to their intelligence - this wasn't a matter of communicating to them a decision that had already been set in stone, as much as it was a matter of bringing the audience into a nuanced dialog with no clear best solution.</li>
</ul>
What leader hasn't had the experience of being challenged, particularly in public, by someone on their team who wants to see things done differently, or who is questioning a decision, or just wants to sound off about something that's annoying them? The anti-pattern that happens all too often is for a leader to shoot off something like "It's more complicated than you understand, but what we're doing is the right way," or, even worse, when the leader responds by directly attacking the questioner - a response that usually comes from a place of feeling disrespected.<br />
<br />
Here's why this really matters: the leader who shuts down challenges from their team leads that team to abdicate all responsibility for change - what member of a team tries to push the group in a new direction if their input isn't respected by the leader? The ultimate outcome is a team where the leader is the only one ever creating change, because the rest of the team has seen that their own attempts are never treated fairly.<br />
<br />
As a leader, it takes a tremendous amount of self-confidence to hear a challenging question, listen to the intent of the person asking it, and respond in a spirit of mutual respect and productive discussion. At the core, I have found that leading in this kind of situation requires the humility to accept that sometime someone will make such a challenge and I will have to say, "There are plusses and minuses to what you're saying, but yes, on the whole I think you have a better way, let's figure out a way to make that happen."<br />
<br />
Those experiences have always created positive outcomes for me on teams I have led, which is why I think careful and considerate response to challenges from your team is a critical one of our Leadership Mechanics.<br />
<br />JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-21375020227241295872012-08-22T09:28:00.001-04:002012-08-22T09:28:23.683-04:00Leadership Mechanics: Staying Above the FrayIn college, I was in a fraternity, but not just any fraternity - I was part of a group of incredible men who founded a new fraternity on campus. I don't really know what it's like to be a fraternity that has been around for decades and has established protocols, but I know that in my fraternity, we spent most of the first two years of our existence by arguing about The Way Things Should Be Done.<br />
<br />
What should the minimum GPA be? What about the minimum GPA for elected officers? What should we do about brothers hosting keg parties off campus? What about on-campus but not in the house? When do we hold elections? Can we spend money on paintball during rush? Should we be allowed to eat in meetings? I'm not kidding, these are the things we argued about.<br />
<br />
The house generally divided into two groups, which, in the interests of fairness to all involved, I'll call the drunkards and the uptight assholes. For any given question, there were usually two takes on it, and it was always the same set of people arguing the same predictable positions.<br />
<br />
We had a pretty open policy toward discussion in those meetings - if a brother had something to say, he would always get the chance to say it. This is why my Sunday evenings in those days were completely unproductive - house meeting would start at 8 and go until 11 quite frequently.<br />
<br />
Among all the debating and arguing about the finer points of fraternity management, we had one very important brother, Jeff. Jeff was a basketball player and electrical engineering major, and usually a very quiet guy. When we were debating some of these "issues", Jeff usually sat silently and listened.<br />
<br />
But after about six months, a very interesting pattern emerged. After endless debate on some minuscule topic, Jeff would slowly raise one giant basketball-player hand, never higher than his chest, and wait for his turn to speak. And whenever he did, he would calmly summarize both sides of the issue and propose a solution. But here's the really crazy thing: without fail, everyone would all hear it and say, "Yeah, he's right, let's do that."<br />
<br />
It was uncanny. It got to the point where, if we were having a debate and Jeff raised his hand, someone in the room would say "Shut up guys, Jeff wants to say something". He was like our own personal Messiah of mediation.<br />
<br />
To this day I can't figure out exactly how Jeff was able to create immediate consensus between two groups that had been yelling at each other moments earlier. But I can point to one key tactic he employed - Jeff never spoke up until he thought he could find a suitable middle ground, he just waited patiently. He stayed above the fray.<br />
<br />
If he had spoken up earlier, he would be perceived as having "taken a side", and all further comments would be colored by that perception. Instead, it was as though he was the one person in the room who could speak directly to all stakeholders, showing them that there was a balanced approach suitable to everyone.<br />
<br />
Staying above the fray is useful in any group dynamic, but it's critical when you're in the position of leadership - nothing can kill a productive debate more quickly than a leader indicating a preference for a particular outcome. In the common case, the leader's comments have the effect of silencing all counter-arguments, thereby ending the discussion before it can be fully explored.<br />
<br />
In my own career, I work very hard to employ a similar tactic every chance I get. If two people in a meeting are arguing about some point, I try not to dive in right away and pick a side, but I wait until I think I've heard what each of them have to say, and then try to point out underlying motivations or shared interests that can build toward consensus.<br />
<br />
As a leader, it's critical to me that I not be perceived as playing favorites or not letting everyone have a fair say in a debate. More often than not, a good group of people can come to a great answer without the intervention of a leader, but when it is required, that intervention comes best from someone who has obviously listened to all input and is focused not on a personal preference but the solution that is best for everyone - in other words, the person who has stayed above the fray.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-17557293932066898892012-08-06T13:56:00.001-04:002012-08-06T13:56:33.388-04:00Leadership Mechanics: Asking Difficult Questions<br />
I was a Boy Scout as a teenager, and my first scoutmaster was an incredible man we all called Mr. P. He was one of my earliest leadership role models, so I want to start the discussion of Leadership Mechanics with him. Mr. P was a powerfully quiet man - one of the few people I know who possessed the ability to silence a room of 40 teenage boys simply by standing quietly and waiting.<br />
<br />
In Boy Scouts, for each new rank you achieve, there are a number of requirements - earn this many badges, go on this many campouts, and so on. The final requirement for each badge was to go through a "scoutmaster conference" - sit down with your scoutmaster, talk with him for 30 minutes or so, and then he signs off for you to get your badge.<br />
<br />
When I first started working on my boy scout ranks, I had a notion that the conference would be just a pro forma conversation, something along the lines of "tell me what you learned while earning this rank".<br />
<br />
Mr. P's conferences, though, were nothing like my expectation. They rarely had anything to do with the requirements of the rank. In his calm, respectful demeanor, Mr. P would drill in on a line of questioning that was, more often than not, pretty challenging.<br />
<br />
A quick aside: it should be no surprise that, as a teenager, I was a first-class nerd. My idea of a good Saturday afternoon was winning a math competition followed by writing programs to find prime numbers, and I lacked any awareness that other people didn't have fun the same way. That my parents allowed me to spend weekends in the woods with a hoard of teenage boys was either a sign of great trust in my ability to take care of myself or great foolishness. The bottom line was, I was a constant target for the other scouts - they called me names, filled my shoes with shaving cream, threw buckets of sand into my tent, all typical teenage stuff.<br />
<br />
To this day, I can remember sitting with Mr. P. in the scoutmaster conference for my Second Class Scout rank, and him really exploring with me the topic of why I didn't get along with the other boys. It had nothing to do with the rank, or what I had learned, but it did have a big positive impact on my future in scouting.<br />
<br />
What really stands out in my memory was that Mr. P. was very pleasant and even caring throughout these conferences, but he would also keep asking questions, the kind of questions that made me reconsider some of my basic beliefs, until I could give a thoughtful answer.<br />
<br />
<i>"What does it matter what names they call you?"</i><br />
<br />
"Um, I don't want to be called those names..."<br />
<br />
<i>"What part do you play in triggering them to do these things?"</i><br />
<br />
"What did I do??? I didn't do anything. I was just around. OK, maybe I might have made some jokes about how I was smarter than they were, but a joke is not even close to the same as what they did!!"<br />
<br />
<i>"Why do you even react to having my shoes filled shaving cream?"</i><br />
<br />
"Why do I react? They filled my shoes with shaving cream - what else would I do?"<br />
<br />
<i>"Does that do anything to discourage them doing it again?" </i><br />
<br />
"Not really, I guess...."<br />
<br />
<i>"So why not choose just not to react?"</i><br />
<br />
"How would you even do that??"<br />
<br />
Throughout this conversation and many others like it, Mr. P. pushed, gently but firmly, to ensure that I was really learning and growing as a young man.<br />
<br />
Here's why I think this is so powerful as a leadership technique - a great leader is someone who is pushing everyone on their team, kindly, firmly, and consistently, toward ever-better performance. Too often we think of performance feedback as falling in the polar opposites of "Everything's great, keep it up, chief!" and "Oh you really screwed that one up, you better not screw up again," but I think a really strong leader can say, "You're doing great, but I want you to explain this situation to me in more detail."<br />
<br />
So this is what I want to call the first of the key tools in Leadership Mechanics: you need to be comfortable asking really difficult questions, and you need to hold people to giving you an answer.<br />
<br />
I use this tactic every day with my teams; for example, when things go wrong, I want to make sure we learn something and improve. I don't need to cast blame or chastise people, but I do expect that the situation provides an opportunity for learning. If someone doesn't give an answer that holds water, I ask again. I collaborate on ideas for what we can learn, but I make sure the answer comes from the person who really needs to learn the answer.<br />
<br />
You see a similar philosophy in the Toyota Total Quality Management approach of "<a href="http://en.wikipedia.org/wiki/5_Whys" target="_blank">Five Whys</a>" - in which a problem is debugged by asking why it happened, and, for each reason provided, you ask why that happened, the idea being that by the time you get five levels deep, you've discovered the real root cause.<br />
<br />
I developed a huge respect for Mr. P. during our scoutmaster conferences. His commitment to asking very challenging questions, and his expectations of getting genuine answers, pushed me to grow in ways I still appreciate.<br />
<br />
As leaders, I think we can all grow our teams and earn their respect in the exact same way: challenging everyone around us to develop genuine thoughtful answers to difficult and uncomfortable questions.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-5710476794095333202012-08-06T13:56:00.000-04:002012-08-06T13:56:24.128-04:00Leadership MechanicsI want to start a new series today on a topic that's been rattling around in my head for a few years now. I want to talk about leadership, but in a new way.<br />
<br />
There are hundreds of leadership books from successful CEOs, and <a href="http://www.amazon.com/s/field-keywords=leadership" target="_blank">thousands</a> more from coaches, trainers, and leadership theorists. These are great books - I started reading many of them at a pretty young age, and much of what I understand about great leadership comes from that study.<br />
<br />
However, what these books rarely get into is the real working day-to-day mechanics of leadership at all levels of an organization.<br />
<br />
A leadership book from a successful CEO usually betrays the luxury of being, in most cases, the final decision-making authority. A CEO's leadership can impact thousands of people, and it is, without a doubt, a very challenging leadership role, but the lessons learned in that context don't necessarily translate to many more common types of leadership roles.<br />
<br />
The theorists and coaches provide great longitudinal review of what works in a variety of situations - working with leaders across many organizations and roles allows them to extrapolate nicely and find useful patterns. However, I find the coaches' perspective frequently to be hollow - you can tell that their narrative is a report from what they have seen, not a first-hand account of visceral, gut-wrenching experience.<br />
<br />
And neither group tends to report on the very tactical aspects of leadership. For example, we can all say that listening is an important leadership skill, but what are the mental habits you build to ensure that you are listening to all those around you?<br />
<br />
So today I want to start a series on what I'm going to call Leadership Mechanics - the nitty gritty, nuts and bolts details of what I have observed great leaders doing day in and day out, and what I have adopted in my own leadership. More than anything, my goal is to start some conversation about the key habits that great leaders use in their everyday work, digging beyond the platitudes that<br />
<br />
For the ten of you that read this blog, I hope you enjoy it, I hope it expands your thinking a bit, and I look forward to hearing your thoughts.<br />
<br />JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-90235058147237714042011-07-10T15:53:00.003-04:002011-07-10T16:14:28.011-04:00Not All Early Optimization is Premature<div><a href="http://thegongshow.tumblr.com/post/6787330290/speed">Andrew Parker</a> and <a href="http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html">Jeff Atwood</a> have both had great posts recently about performance as a feature, but I think they've each actually stopped short of a powerful point - improving a product experience by 10 or 20 percent through optimization is great, but there's incredible power when you unlock fundamentally different feature sets through radical optimization. This is an area that the code-first-then-optimize process misses entirely, because incremental improvements on the same basic design will never lead to order-of-magnitude performance improvements.</div><div><br /></div><div>The power of such performance improvements is one of the most important lessons I learned at Google. A couple examples demonstrate the kind of optimization I'm thinking of:<br /><ul><li>In 2004, when the standard storage for webmail was 2MB, Google was able to launch Gmail with 1GB of storage, because <a href="http://en.wikipedia.org/wiki/Google_File_System">GFS</a> provided a means for managing disk that was orders of magnitude cheaper than what the other providers were using. Rumor has it that Yahoo went out and gave NetApp millions of dollars to buy storage devices in order to come anywhere close to what Google was offering. Underlying this all is an optimization of storage and disk that was deeply more efficient that what others in industry were capable of at the time.</li><li>One of the coolest features of Google maps is the ability to see a route, then grab it with your mouse and drag it to change the route. That feature is possible because <a href="http://googleblog.blogspot.com/2007/11/road-to-better-path-finding.html">Google developed a radically more efficient route-finding algorithm</a>, years ahead of what anyone else in the market can offer. The difference between computing a route in 1 second and computing it in 10 milliseconds means you can suddenly offer users the ability to compute hundreds of times more routes.</li></ul></div><div>It's part of the modern software engineering zeitgeist that "premature optimization is the root of all evil," but as I researched this post, I found out that the full Knuth quote is a lot more illuminating than just that snippet; the full statement attributed to Knuth is actually, "<a href="http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize">We should forget about <b>small</b> efficiencies, say about 97% of the time: premature optimization is the root of all evil</a>" (emphasis mine).</div><div><br /></div><div>So yeah, we can all agree that "performance is a feature," but that fails to convey the power of high-performance systems. We can talk about caching database results or using a CDN for static content, and everyone should be doing those things, but let's not be afraid to go much, much deeper. Consider the core operations of your service, then imagine that you could speed them up by 100x - what radically new features would be enabled? With those radical new features in mind, start working backwards to figure out actually make those 100x improvements.</div><div><br /></div><div>The big challenge is that these order-of-magnitude optimizations are design optimizations, not the kind of changes you can make after the fact. In design discussions, the engineer arguing for keeping the entire datastore in memory is immediately shouted down with the "premature optimization" line, but I think it's time we start fighting back on behalf of design-time optimization.</div>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-10075320375352725032011-04-10T18:07:00.002-04:002011-04-10T18:12:02.494-04:00Making Effective Use of Code Reviews<div>I’ve been reading chunks of <a href="http://www.amazon.com/gp/product/1430219483/ref=as_li_ss_tl?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1430219483">Coders at Work</a> this weekend, and the topic of code reviews has come up a few times. Code reviews are clearly a very useful development technique, but it can be tricky to apply them in a way that improves code quality without slowing productivity.</div><div><br /></div><div>Poking around the web, I don’t see a lot of great writing about code reviews, so I wanted to share the guidelines we use at <a href="http://www.yext.com">Yext</a> for effective code reviews. The guidelines below are captured from an email I sent to the the engineering team almost a year ago, and I’m proud to say that our code reviews do a lot to improve code quality while keeping the team operating at peak efficiency.</div><div><br /></div><div>These guidelines are heavily biased by my experience at Google. There, I saw how code reviews could identify and eliminate many preventable bugs, including many that the original developer never would have found. I also saw innumerable cases of reviewers who lost perspective on the larger goals of the team and the company, and thus acted to prevent progress on important projects as a result of matters of personal preference or sheer obstinance. My goal for Yext is that we capture the best aspects of code reviews while eliminating the worst.</div><div><br /></div><div>With that in mind, my recommendation for code reviews is that they address the following points:</div><div><ul><li><b>Correctness</b>: Does the code do what it claims to do? Is the code correct in both the nominal case and the boundary cases? As a reviewer, this is your opportunity to point out edge conditions of which the original developer may not have been aware. An important special circumstance is when you may be aware of legacy systems or features that interact with the modified code in some non-obvious way.</li><li><b>Complexity</b>: Does the code accomplish its task in a reasonably straightforward way? If you can point out simpler approaches that do not compromise the correctness or performance of the code, you should.</li><li><b>Consistency</b>: Does the code achieve its basic goals in a way that is consistent with how similar code in the codebase achieves those goals? Is it re-using the available libraries and utility classes? Where possible, has code been refactored for re-use instead of just copying and pasting?</li><li><b>Maintainability</b>: Could the code be extended by another developer on the team with a reasonable amount of effort? More than any item on the list, this is the karma investment you make by doing code reviews – the code you review today may be the code you have to update tomorrow, so taking the time to make sure it’s maintainable by others pays itself back to you.</li><li><b>Scalability</b>: Will the code be performant at the expected volumes? It is important that this question always be asked in the context of expected volumes. When building a new product in an untested market, it is fine to write code that works for 100 users but not 10,000; if the product should be that successful, you can profile, optimize, and, when necessary, re-write the critical bits. The corollary is that you should not spend time optimizing code when the market demand is unproven.</li><li><b>Style</b>: Does the code match the team style guide? This should rarely be controversial. The obvious assumption here is that your team should have a style guide.</li></ul></div><div>There are some items I believe should only rarely be addressed during a code review:</div><div><ul><li><b>Scope or mission feedback</b>: “I don’t think you should be doing this project” is almost never a useful comment for a code review. If you think the team is embarking on projects that are not worthwhile, that is great feedback to share, but not in the context of a code review. The exception here is if someone is introducing a new way of doing something that is already well-handled in some other way.</li><li><b>Design review</b>: A code review is not the time to evaluate the overall design of a project. For example, "I don't think you should be using the DB to store this data" is not useful. It is incumbent upon the developer to have their designs reviewed before implementation, and there will be scenarios in which the fundamental design is questioned during the implementation, but for a project that has been through a design review, let the results of that design stand.</li><li><b>Personal preference</b>: “I would rather you do it my way” is an invitation to an unproductive debate. If you have a way that is demonstrably better, you should always argue for it. The hardest part about this point is identifying when a review has deteriorated to matters of personal preference; the hallmark I spot most often is when people are trading hypothetical scenarios in which alternative solutions might be advantageous, with no way of determining the likelihood of said scenarios. In these cases, the default is to use what the developer has already written.</li></ul></div><div>How can you, as the developer, write your code in such a way as to make a code review? A few simple practices help.</div><div><ul><li><b>Correctness</b>: Comprehensive unit tests are the best demonstration that code functions as intended.</li><li><b>Complexity</b>: Favoring small methods and cleanly-separated functional units makes it easy for your reviewer to see how everything fits together.</li><li><b>Consistency</b>: When building new functionality, you can maximize the consistency of your code with existing work by taking the time to research how similar code solves similar problems. If you suspect someone else has solved the same problem before, ask!</li><li><b>Maintainability</b>: Thorough commenting and the use of meaningful names throughout your code help ensure that others will be able to easily understand your code.</li><li><b>Scalability</b>: My #1 recommendation in demonstrating the performance of new code is to just take 30 minutes and write a little driver to run your code through its paces. This can be total throwaway code, but simply being able to tell your reviewer that you’ve done a performance test makes this topic less debatable.</li><li><b>Style</b>: The most important thing you can do to maintain style consistency is to configure your editor to implement your style guide. (As an aside, this also means that your team should adopt a style guide that is simple to automate in the editors used by the team.)</li></ul></div><div>Even when everyone on the team follows these guidelines, there will frequently be strong debate during code reviews, and that’s a great thing - the point of these guidelines is to focus the debate on what matters.</div><div><br /></div><div>All of this ignores some very tactical questions about code reviews like what code gets reviewed and what tools we use to aid that process. If you’re interested in hearing more about that, leave a comment and I will follow up with another post.</div>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com4tag:blogger.com,1999:blog-13502160.post-44983980458344406772011-03-13T20:49:00.005-04:002011-03-14T08:29:07.917-04:00The Dark Side of Passion<span class="Apple-style-span" ><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; " id="internal-source-marker_0.7784135848287027">There was a lot of great response to my post about the <a href="http://blog.jayteebee.org/2011/03/foursquare-facebook-founders-and.html">Passion Gap</a>, but some people misunderstood it to mean that I fall in with the camp of career counselors who tell you to “<a href="http://www.amazon.com/gp/product/0440501601/ref=as_li_ss_tl?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0440501601">do what you love and the money will follow</a>”. While I believe that doing something you love is important, I also strongly believe that following your passion must be grounded in reality.</span><br /><span class="Apple-style-span" style="background-color: transparent;"><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; "></span></span><br /><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; ">This first became clear to me when was in high school. Sometime during freshman year, they marched us all into the career center and made us look up the key facts on our ideal jobs. We had to find out good college majors to prepare us for those careers, the demand for people with those jobs, and the average pay we could expect. I looked up the job I’d be dreaming about since age 9, and I was incredibly disappointed at the average salaries. When my father was pushed into early retirement while I was a senior in high school, the cold hard reality of making a living was a key input in my eventual decision to study computer science.</span><br /><span class="Apple-style-span" style="background-color: transparent;"><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; "></span></span><br /><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; ">To be completely clear, I’m incredibly happy with what I do - I love going to work every day. But I also love providing for my family.</span><br /><span class="Apple-style-span" style="background-color: transparent;"><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; "></span></span><br /><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; ">Moderating your passion with realism is not at all inconsistent with having a deep enduring passion for your startup. Even Dennis Crowley, protagonist of the Passion Gap post, is on the record saying that the one thing he most wants to be good at is … <a href="http://blog.onething.com/post/540962364/dennis-crowley-my-one-thing-is">karaoke</a>. But belting out Whitesnake just doesn't pay the bills.</span><br /><span class="Apple-style-span" style="background-color: transparent;"><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; "></span></span><br /><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; ">The dark side of passion is blindly following a passion that won’t support you. <a href="http://calnewport.com/blog/2010/10/16/the-passion-trap-how-the-search-for-your-lifes-work-is-making-your-working-life-miserable/">This post at Study Hacks</a> goes so far as to make the argument that the “follow your passion” culture is responsible for the fact that self-reported job satisfaction rates have fallen every year since measurement started in 1987 - the argument is that because people are so focused on the perfect job, the one they can be most passionate about, they are ultimately disappointed by having simply a great job.</span><br /><span class="Apple-style-span" style="background-color: transparent;"><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; "></span></span><br /><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; ">The unrealistic view that it’s sufficient to simply be passionate about something and not match that passion to reality is captured in <a href="http://www.nytimes.com/2009/10/04/opinion/04williams.html">this op-ed from the Times</a> in 2009, in which the author describes a difficult search for work as an art instructor, despite qualifications including an MFA. The author admits, “In my master’s program, we … tried not to dwell on earthy, unpleasant topics like money, or how to make it.”</span><br /><span class="Apple-style-span" style="background-color: transparent;"><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; "></span></span><br /></span><span style="color: rgb(0, 0, 0); background-color: transparent; font-weight: normal; font-style: normal; text-decoration: none; vertical-align: baseline; "><span class="Apple-style-span" >As I said in my earlier post, I deeply believe that passion can be a competitive advantage for startups, and I also think it’s crucial to success in most everything else, but that passion must be channeled in a way that is connected to reality.</span><br /></span>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-26197237963056210852011-03-09T08:27:00.003-05:002011-03-14T09:12:33.560-04:00Foursquare, Facebook, Founders, and Passion<div>Late in the summer of 2009, I was talking to a very successful entrepreneur at a tech industry meet-and-greet when <a href="http://twitter.com/dens">Dennis Crowley</a>, co-founder of <a href="http://www.foursquare.com/">Foursquare</a>, came into the room, at which point the person I was talking to commented, “I first met Dennis at 3am on a street corner on the lower east side. I have never met another founder who is a more direct physical embodiment of their startup.”</div><div><br /></div><div>That comment always comes back to me when I hear someone saying that a particular startup “is just a feature,” or, “has no defensible technology,” or, “could be replicated in a weekend.” There are a lot of startups out there that are subject to this critique, and yet, they continue to do extremely well in the face of competition. And I think, in many cases, it derives from the fact that these founders are the physical embodiment of their startups.</div><div><br /></div><div>In the case of Foursquare, we should expect by now that Facebook Places would have obliterated the use of Foursquare. And yet, as SAI points out this morning, <a href="http://www.businessinsider.com/chart-of-the-day-foursquare-users-2011-3">Foursquare’s user base has doubled since the launch of Facebook Places</a>. That’s pretty stellar growth in the light of competition that should be winning on every dimension. And that’s before the release of the awesome goodness that is <a href="http://blog.foursquare.com/2011/03/08/foursquare-3/">Foursquare 3</a>.</div><div><br /></div><div>Why does Foursquare just keep winning? If I could tell you the specific features or user interactions that are lacking in Facebook Places, I’d be a rich man. I’m in the Facebook mobile app 3 times a day, minimum, let alone being on Facebook over the web at least twice a day - I should be using Places all the time, and yet I just keep coming back to Foursquare. Somehow Foursquare just hums.</div><div><br /></div><div>This, to me, is the difference between a product built by someone who is deeply invested in the in the underlying product idea, as compared to a product built by someone who is just trying to check off a set of feature boxes. This is what I think of as the Passion Gap.</div><div><br /></div><div>If you’ve ever heard Dennis talk about Foursquare, or mobile devices, or cities, you can’t help but see that everything you think of, he’s already thought of, turned over in his head eight times, and reached the conclusion that you would eventually come to if you spent eighteen months in deep thought about the topic. Does Facebook have a Dennis Crowley? Or do they have a product manager who just started thinking about location-based services eight months ago? That PM may have 600 million users and every engineering resource they desire, but they haven’t spent the last ten years thinking about how to get people more engaged with their cities via their mobile devices. The difference between Dennis Crowley and that Facebook PM is the Passion Gap.</div><div><br /></div><div>The Passion Gap is evident when you see a founder or product manager so deeply engaged in their product that they can’t help but think about it all the time, and, as a result, they see all the fine details that are required to make a product that exactly matches what the market needs. This is true even when the market hasn’t yet realized the need.</div><div><br /></div><div>Another great demonstration of the impact of the Passion Gap is the difference between <a href="http://stackoverflow.com/">StackOverflow</a> and <a href="http://www.experts-exchange.com/">Experts Exchange</a>. StackOverflow is amazing, and we should all be thankful to Jeff Atwood for creating it. But Experts Exchange is basically the same product idea, created years before, with an entrenched user base. And yet, somehow the user experience at Experts Exchange is all friction, whereas StackExchange just hums. If you’ve read any of <a href="http://www.codinghorror.com/blog">Coding Horror</a>, it makes perfect sense - Jeff Atwood has a deep passion for making every software engineer out there better at what they do. Of course someone with that passion was going to be the one to make a tremendously useful knowledge-sharing site for software engineers!</div><div><br /></div><div>So I think of the Passion Gap whenever someone claims that a successful startup has “no defensible technology”. For some of the most interesting companies out there right now, the key bits of technology are not in some single large algorithmic piece, but rather in dozens of fine-grained product choices that make a total experience. The people who accuse those products of lacking defensible technology are taking a one-dimensional view of the product. It’s like we’re all color-blind to the features that make the product hum, and yet these highly passionate founders see the colors we’re completely unaware of.</div><div><br /></div><div>Just to enumerate some other examples of where I see the Passion Gap at work:</div><div><ul><li>Andrew Mason (<a href="http://www.groupon.com/">Groupon</a>) - Andrew’s startup prior to Groupon was <a href="http://www.thepoint.com/">The Point</a>; it was a startup for social causes where one person acting alone could not have an impact. I would have to guess that Andrew Mason's passion isn’t about marketing local businesses, as much as it is about leveraging the power of groups of people acting together. Certainly, we have to assume that his time spent thinking about the dynamics of group action while working on The Point provides a nice competitive advantage to Groupon.</li><li>Mark Zuckerberg - the <a href="http://www.time.com/time/specials/packages/article/0,28804,2036683_2037183_2037185,00.html">Time Man of the Year profile of Zuckerberg</a> does an excellent job of showing just how passionate Zuckerberg is for thinking about personal relationships and how to extend them with technology. Remember for a moment that when Facebook first started to get big, many people thought it was just another wave in the Friendster/Myspace ebb and flow of social networking sites. I see Zuckerberg's passion as key to how Facebook achieved and maintained dominance.</li><li>Steve Jobs - Steve is an interesting case, because his passion, by observation, seems to be more about beauty in technology rather than any particular product application. And yet, Apple consistently puts out products where the beauty of the thing itself is a huge part of the sales appeal. The Passion Gap is particularly well-demonstrated when competitors set out to copy and improve upon Apple’s category killers, for example, the Zune.</li></ul></div><div>The most common way that people talk about the Passion Gap is when they advise you to “start a company that scratches your own itch”. I posit that the underlying logic in that advice is that the best startup you can create is one where you will be constantly engaged in thinking about improving the product, maximizing the user experience, and planning for the future -where you have real passion for making it work.</div><div><br /></div><div>Anyway, the next time you see a startup with “no defensible technology”, take a look at the founder, analyze their passions, and consider whether their defense lies in the Passion Gap.</div><div><br /></div><div><b>Addendum: </b>Please check out the follow-up post to this one, <a href="http://blog.jayteebee.org/2011/03/dark-side-of-passion.html">The Dark Side of Passion</a>.</div>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com15tag:blogger.com,1999:blog-13502160.post-25884089796503263792009-07-24T10:44:00.005-04:002011-03-14T08:31:11.676-04:00Using Puzzles in Interviews<span class="Apple-style-span" ><a href="http://www.unionsquareventures.com/bios/albert.html"><span class="Apple-style-span">Albert Wenger</span></a><span class="Apple-style-span"> has a great post up on </span><a href="http://www.continuations.com/"><span class="Apple-style-span">Continuations </span></a><span class="Apple-style-span">about </span><a href="http://continuations.com/post/148229250/using-puzzles-in-interviews"><span class="Apple-style-span">Using Puzzles in Interviews</span></a><span class="Apple-style-span">. He makes a number of good points, most importantly:</span></span><div><span class="Apple-style-span" ><br /></span></div><div><blockquote></blockquote><blockquote></blockquote><span class="Apple-style-span" style="color: rgb(34, 34, 34); line-height: 24px; " ><blockquote><span class="Apple-style-span">1. Puzzles should be just one of many different parts of the interview.<br /><br />2. Try to find a set of puzzles that works for you and use the same puzzles with many candidates to get better comparability.<br /><br />3. Focus primarily on approach and behavior and only secondarily on outcome.<br /><br />4. Unless the position specifically calls for ability to think under stress (e.g. certain ops positions), try to put the candidate at ease. Being in an interview is stressful for many folks.<br /><br />5. Ask for a vocalization or visualization of the thought process.</span></blockquote><span class="Apple-style-span">I agree with most of this approach, but I still feel that everyone needs to be very cautious about using puzzles that are basically brain-teasers. In the first comment on Albert's post, one of the readers made part of my point for me - they posted a potential puzzle, and it was immediately pointed out that is well known amongst the brain-teaser set. I posted a fairly lengthy response on Albert's blog, but I figured I might as well cross-post it here.</span></span></div><div><span class="Apple-style-span" style="color:#222222;"><span class="Apple-style-span" style="line-height: 24px;"><span class="Apple-style-span" ><br /></span></span></span></div><div><span class="Apple-style-span" style="color:#222222;"><span class="Apple-style-span" style="line-height: 24px;" ><div><span class="Apple-style-span">At the core, the most important distinction is between coding/algorithm puzzles and brain-teaser puzzles.</span></div><div><span class="Apple-style-span"><br /></span></div><div><span class="Apple-style-span">E.g., one of the best interview questions I've ever been asked basically boiled down to performing bipartite graph matching - it required deep understanding of algorithms and how to match them to real-world problems, and then being able to implement the code behind them - pure awesome.</span></div><div><span class="Apple-style-span"><br /></span></div><div><span class="Apple-style-span">On the other hand, some of the worst interview questions I've encountered are the form of "N pirates have to divide X gold among themselves" or "You're blindfolded in a room wearing a hat..."</span></div><div><span class="Apple-style-span"><br /></span></div><div><span class="Apple-style-span">Brain-teaser questions tend to have the drawback that they are very uneven - for people who love brain-teasers, many brain-teasers are well-known or simple variations on existing problems, but for people who don't, they're starting without the benefit of any of the background.</span></div><div><span class="Apple-style-span"><br /></span></div><div><span class="Apple-style-span">In addition, in my time at Google I saw heavy anecdotal evidence that brain-teaser aptitude correlates negatively with overall effectiveness as a developer. Sometimes the developer who searches too hard for clever solutions winds up missing the simple solutions.</span></div></span></span></div>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-37910082502381695932009-07-09T16:48:00.004-04:002011-03-14T08:33:18.133-04:00ImportError: No module named django.core (fun with Windows)<span class="Apple-style-span" >I just spent 45 minutes tracking this down, hopefully if I post a trace here, others will be able to resolve the issue more quickly in the future.</span><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" ><span class="Apple-style-span">So I am building a little </span><a href="http://www.djangoproject.com/"><span class="Apple-style-span">django</span></a><span class="Apple-style-span"> app at work, but my latest installed version of django is pre-1.0, so why not upgrade, right?</span></span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >After getting everything downloaded and running setup.py, I did the standard thing to start a new project:</span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >C:\Users\jtb\Documents\Clickable\src>django-admin.py startproject myproject</span></div><div><span class="Apple-style-span" ><div>Traceback (most recent call last):</div><div> File "C:\Python25\Scripts\django-admin.py", line 2, in <module></module></div><div> from django.core import management</div><div>ImportError: No module named django.core</div><div><span class="Apple-style-span"><br /></span></div><div><span class="Apple-style-span"><span class="Apple-style-span">All the </span></span><a href="http://www.google.com/search?rlz=1C1GGLS_enUS291US306&aq=f&sourceid=chrome&ie=UTF-8&q=ImportError:+No+module+named+django.core"><span class="Apple-style-span"><span class="Apple-style-span">search results</span></span></a><span class="Apple-style-span"><span class="Apple-style-span"> on that error pointed to issues with my PYTHONPATH, but no amount of tinkering with it would make django actually run.</span></span></div><div><span class="Apple-style-span"><span class="Apple-style-span"><br /></span></span></div><div><span class="Apple-style-span"><span class="Apple-style-span">The real problem was that, due to a recent installation of Python 2.6, my PATH and my PYTHONPATH had fallen out of sync. My PATH was pointing to the Python 2.5 directories, while my PYTHONPATH was pointing to the 2.6 directories. It seems the Python installer I used knows how to update PYTHONPATH but not PATH. Which makes sense.</span></span></div><div><span class="Apple-style-span"><span class="Apple-style-span"><br /></span></span></div><div><span class="Apple-style-span"><span class="Apple-style-span">If you found this post through a web search and it helped you debug a similar issue, please post a comment.</span></span></div></span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><br /></span></div>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com2tag:blogger.com,1999:blog-13502160.post-64071812334660514602008-09-19T09:57:00.004-04:002008-09-19T10:03:43.590-04:00Xoogler Tip: What happens to your email after you leave?For all you Xooglers out there, here's a little tip to smooth the transition outside of the 'plex.<div><br /></div><div>When you leave Google, your existing mail account becomes a black hole - all mail sent to the address silently goes away. There's no bouncing or auto-responder. No big deal, right? Anyone at Google can probably get your new address off go/epitaph.</div><div><br />BUT: If, like me, you worked with anyone outside of Google (for example, patent attorneys), they might not know about your departure, and they can haplessly send email into the black hole for months without discovering that you're not there any more. I found this out recently when a lawyer who had been trying to reach me all summer finally found out that I had left the company. </div><div><br /></div><div>Simple fix: before you leave, you can file a ticket to have an auto-responder set up. If you've already left, your HR Business Partner can help you out.</div>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-29075274148922655322008-04-11T07:09:00.002-04:002008-04-11T07:16:03.670-04:00Today is my last day at GoogleAfter nearly five years at Google, I am leaving the company, effective at the end of the day today. My time at Google afforded a tremendous number of opportunities; I was able to take part in growing the company's <a href="http://googleblog.blogspot.com/2005/04/its-wonderful-town.html">first remote engineering office</a> from 5 engineers in 2003 to nearly 450 today, I was able to conduct blue-sky exploration of applying Google's data and computing infrastructure to web information extraction, and, more recently, I was able to help build an all-star team that just shipped <A HREF="https://www.google.com/admanager">Google Ad Manager</A>.<br /><br />Contrary to what glowing articles in <a href="http://money.cnn.com/galleries/2008/fortune/0801/gallery.bestcos_top50.fortune/index.html">Fortune</a> or <a href="http://www.fastcompany.com/magazine/123/google.html">Fast Company</a> might tell you, the best part of working at Google has nothing to do with the free meals, subsidized massages, or even the stock options. The best part of working at Google has been the chance to collaborate, to innovate, and to explore with the most talented collection of people I could ever imagine. Missing those people every day is the hardest part of leaving this company.<br /><br />I don't know yet what my next challenge will be, but I hope to go somewhere very small and take part in building a company from the ground up. Wish me luck!JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-41216153225666326012008-03-17T20:06:00.002-04:002008-03-17T20:10:07.463-04:00Followup: which skills to list on your first resumeOver at <a href="http://www.techinterviews.in/">techinterviews.in</a>, they've picked up on my recent series about writing your <a href="http://blog.jayteebee.org/2008/03/cs-undergrads-guide-to-writing-your.html">first resume</a> and posted some good <a href="http://www.techinterviews.in/resume-of-a-fresh-computer-science-graduate/76">comments</a>, including:<br /><blockquote>There’s nothing like picking a language or operating system or database management system that a candidate listed towards the end of his resume, and having an interviewer, who’s the expert in the field (”Ah! So you did Nintendo DS assembly programming, too! Let’s discuss this in detail!”) then discover that the knowledge of this listed tech is, to say the least, limited. It makes the whole resume look like a creative writing projects, the aim of which is to specify as many buzzwords as possible.<br /></blockquote>I do advise undergrads to be a little liberal in listing technical skills, and I want to take the time to explain that a more clearly. <br /><br />Here's an example from my own experience. One of my undergraduate research jobs was with a research group studying <a href="http://act-r.psy.cmu.edu">human cognition</a>, primarily via a cognitive modeling system built in LISP. I joined the group in my sophomore year and stayed on through graduation, during which time I wrote several hundred lines of LISP glue code to manipulate my models and experiments. By the time I was interviewing for jobs, I was very comfortable writing complex LISP code and tackling problems with a functional approach. However, I knew very little about the overall design of the language or some of the important big concepts like <a href="http://en.wikipedia.org/wiki/Common_Lisp_Object_System">CLOS</a>. But I still listed LISP on my resume.<br /><br />I recently had cause to write some LISP code for the first time in 10 years, and I was still able to work effectively in the language. But I wouldn't even consider listing LISP on my resume these days, because it's far outside the core of my expertise.<br /><br />On the other hand, my first research job in college involved writing a mix of Fortran and C code for a parallel supercomputing group. In the year or so I worked with that team, I probably wrote a few hundred lines of Fortran code, and it was ugly. In my senior year, I left Fortran off my resume - if someone had asked me to write even a line of Fortran code, I would have been helpless. In any event, I knew I didn't want to work for a company that would be excited by my experience with Fortran.<br /><br />In brief, when someone fresh out of school lists a particular technical skill, my expectation is that it conveys less expertise than when someone 10 years out lists the same skill.<br /><br />If you really want to be precise in listing technical skills, the best approach is to quantify your level of experience. Some people take the straightforward approach of listing the number of years they've worked with a technology. I find it more useful to communicate a self-assessment of your skill level, using phrases such as "expertise in ..." and "familiar with ..."<br /><br />But if you're just coming out of your undergraduate program, list anything where you think you can speak intelligently about the technology. If an interviewer asks a question that goes beyond your expertise, admit it, and offer a quick description of how you've used that technology and what areas you're best suited to answer questions about.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-46990147389470987232008-03-12T08:50:00.002-04:002008-03-12T09:06:00.263-04:00The CS undergrads' guide to writing your first resume, part 3Hopefully my first two posts in this series have given you a good idea about how to<a href="http://blog.jayteebee.org/2008/03/cs-undergrads-guide-to-writing-your.html"> start your resume</a>, and <a href="http://blog.jayteebee.org/2008/03/cs-undergrads-guide-to-writing-your_11.html">what to emphasize and downplay</a>. By now you've got a good draft, and you've had it reviewed by a number of friends. What's next? Take a pass over this list and make sure you're not committing any cardinal sins.<b><br /></b><br />Some resume mistakes are so bad that you must never commit them. Please.<b> </b>The ones that always set me off are:<b><br /></b> <ul><li><b>Multiple pages.</b> I've have reviewed hundreds, if not thousands, of resumes, and in all those examples I have seen only one multi-page resume come with a strong candidate behind it. All the other ones, the ones where people list every class project, or every club they've been in, or the names of all their teachers in high school? Worthless. Take the time to distill your education and experience into the points that can be expressed in a single page of text. If you can't get it down that far, hand a draft to one of your editors and ask them what's least interesting.<br /></li><li><b>Spelling mistakes.</b> See my earlier comments about having several other people read your resume before you share it with any companies you're interested in. When I see a really egregious spelling mistake, I will discard the resume completely. <br /> </li><li><b>Using the Microsoft Word resume template.</b> First off, the template just doesn't look that great, and second, it sends the message "I just put this together in five minutes because that's about how much I care about your company. Please pretend not to notice." I accept that page layout can be hard, but if you can't create something that looks decent, ask a friend for help. The layout for my first resume came from a good friend who actually has a talent for these things, and I used it successfully for the next several years.<br /></li><li><b>A non-CS undergraduate degree followed by a CS Master's degree</b> from either (a) a no-name computer science program, of (b) a top-tier school that is known to be a diploma mill for anyone with the money to buy a degree. I'm not naming names here, but you know who you are. <br /> </li></ul> Lastly, I just want to touch on the long-standing debate about whether or not to include an "Objective" at the top of your resume. In the modern era, most resumes are submitted directly for one or a small number of job openings, so I'm going to assume that your objective is to get hired for one of those positions. Including a comment in your resume to tell me you want a career like the one I have to offer you only wastes space that you could be using to tell me more about your background and expertise. I say skip the objective, but you can decide what works best for you.<br /><br />Thanks for reading this far. If you found this guide useful, please leave a comment.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com2tag:blogger.com,1999:blog-13502160.post-31293281908174363802008-03-11T10:06:00.002-04:002008-03-11T10:14:55.117-04:00Please keep your laptop open in meetingsJeremy Zawodny has mixed but generally positive feelings about <a href="http://jeremy.zawodny.com/blog/archives/010076.html">not having laptops open in meetings</a>, but I think he's actually going after the wrong point. What you really want is a "no distractions in meetings" rule - working on email, thinking about your vacation plans, or what you'd rather be doing at the time - are all detrimental to the effectiveness of a meeting.<br /><br />If you can avoid distractions like email or feed readers, a laptop is an invaluable tool in making a meeting more effective. Almost every useful meeting I sit in these days involves constant references to documents stored in the cloud, real-time scheduling for follow-on conversations, and back-channel talk among participants. All of these, obviously, require a network-connected laptop available throughout the meeting.<br /><br />Allowing people to keep their laptops open requires a certain amount of trust; namely, you're trusting that people will use their laptops to further the goals of the meeting, not to be virtually elsewhere while others are counting on your input and feedback. But a laptop is a great tool; let's not throw out the good with the bad.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-54238466502615676862008-03-11T06:36:00.002-04:002008-03-11T06:46:09.076-04:00The CS undergrads' guide to writing your first resume, part 2Ideally <a href="http://blog.jayteebee.org/2008/03/cs-undergrads-guide-to-writing-your.html">yesterday's post</a> gave you the basic structure for your first resume. Today I'll give some more details on what to emphasize, and what to downplay if you want me to read your resume and call you for an interview.<br /><br /><b>The Top Things I Look For In Your Resume</b><br /><ul><li><b>A degree in Computer Science.</b> I see lots of resumes from people with degree names like "Information and Decision Systems" or "Technology Management". I won't discount the value of those degrees, but for the kind of software development I do, my experience has been that a rock-solid understanding of computer science is the cost of admission. I'll always award bonus points for a minor or a second major that reflects to your interests and could be applied in your work.<br /></li><li><b>A good GPA.</b> For many schools, especially the top-tier schools, this means roughly something over a 3.5. I know you think college is hard and I don't understand your courseload and blah blah blah, but the fact of the matter is, a large part of your success in college is determined by your ability to manage and schedule your time and your work. If you had a B average, my first hypothesis is that you can't manage your own time, and transitioning to the professional world isn't going to make that problem magically go away.</li><li><b>Did you do more than just go to class?</b> This is where you really set yourself apart from every other graduating senior with a degree in Computer Science. If you think you went to college for the classes, you really wasted the other 158 hours of every week.</li><li>As a follow-on to the last point: <b>did you demonstrate leadership talent outside of class?</b> Most people shouldn't be President of Student Government, but you can be Vice President of <a href="http://seds.org">Students for the Exploration and Development of Space</a>. Heck, I was. I'm not saying that I only want to hire leaders, but I am interested in people who are willing to step up and volunteer their time and energy to do something larger than themselves. These are the people who see a problem and attack it, not just complain about it. Even better than taking on a volunteer leadership role is taking on an <span style="font-weight: bold;">elected</span> leadership role - it demonstrates that other people look to you as a leader.<br /></li><li><b>Interesting projects.</b> For me, if I read a project description on your resume of something I don't know how to do myself, I'll want to talk to you just so I can learn more about that project. Translation: while you're in school, look for opportunities to do hard projects. The homework assignments in your intro CS class aren't going to cut it, and the final project in Operating Systems probably won't, either. Get involved in a research group, or start something with your friends, but set out to tackle something difficult. Great big warning: if you list a project on your resume, be ready to answer questions about any aspect of it. Any hint of bullshit on this point will taint the outcome of your interview.<br /></li></ul>I appreciate that this list is completely useless if you're about to graduate with a C average in Database Systems, having done nothing outside of the classroom except get high. Sorry.<br /><br />Also, and this is not critical, but please, pretty please, use a format that will work on my platform. Since you have no idea what platform I'm using, go with something nice and portable. PDF is still the gold standard, though I'd be very impressed by anyone who sent me a resume by sharing a Google Document. Plain text works as well, though it severely limits your formatting choices. Whatever you do, just stay away from MS Word - almost any fancy formatting you do in word will not translate correctly into, for example, a Linux-based word processor like OpenOffice. I have a fixed amount of time to review your resume, and if I spend most of that time piecing together bits of text that wound up splayed across several pages, I'm probably not going to notice that hidden gem of a project you did sophomore year.<br /><br />I've found a common problem on resumes is to really drum up things that turn out not to be that important. This is based entirely on my experience on the observed correlation between background and impact as an engineer. To wit, here are ...<br /><br /><b>The Top Things I Don't Look For In Your Resume<br /></b><ul><li><b>An extremely high GPA</b>. Once you go beyond the 3.5 - 3.75 range, there's a leveling effect; in my experience the kid who got a 4.0 is just as likely to be good at writing software as the kid with a 3.75.<br /></li><li><b>A top-tier school.</b> There are a huge number of benefits to going to one of the three or four "best" CS schools in the country, but they seem to have little predictive power in the quality of the work someone will do professionally. I've known too many screwups from MIT and CMU, and too many rock stars from lesser-known schools, to care too much about where you got your degree.<br /></li></ul><div style="margin-left: 80px;">Caveat: Sure, if you went to CMU, that's an added bonus for me, because I know we immediately have some common background and we can swap stories about Mark Stehlik or late nights spent in Wean. But that's still not going to get you a job, and if the rest of your resume is weak, it might not even get you an interview.<br /></div><ul><li><b>Some minor contribution to some minor open-source project.</b> Open source is great, and as an undergrad, contributing to an open source project is a great way to get some exposure to real software development. However, your two-line contribution to libsecondlife, correcting the spelling of "Linden" in the comments, is really not going to get me excited, so please let's just skip it.<br /></li></ul>Obviously none of the items on this list should be considered a negative; I'm just saying that don't waste a few dozen words extolling the virtues of MIT, or trying to convince me of the quality of your non-MIT school. Tomorrow we'll cover the real pitfalls that destroy a lot of otherwise strong resumes.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-72427298162842568882008-03-09T21:04:00.004-04:002008-04-07T10:28:27.301-04:00The CS undergrads' guide to writing your first resumeContinuing on the theme of<a href="http://blog.jayteebee.org/2008/01/do-it-yourself-degree-in-software.html"> bridging the gap between an undergraduate CS degree and a career in software development</a>, I want to talk today a little about resumes.<br /><br /><b>What a Resume is Good For</b><br /><br />The most common mistake people make with their resume, young and old, is to write a resume that makes the case for hiring you. No smart company is ever going to hire you on the basis of your resume, so don't even try. Your goal is to have me read your resume and think, "Hey, this person sounds really interesting, I should set up a phone call with them." And that's it. If you want to, you could really stop reading here - once you understand the critical purpose of a resume, everything else is just details. So let's really drive the point home: a resume's only purpose is to get someone, anyone, to read it and be interested in you.<br /><br />If you're still with me, let's start things off with...<br /><br /><b>How to Write Your First Resume</b><br /><ol><li>Put your name and contact information at the top of the page, in a font larger than anything else you'll put on the page.</li><li>Start a section called "Education", and include:</li><ul><li>the name of your college or university,<br /> </li><li>the name of your degree program,<br /> </li><li>and your GPA. Please consider your GPA to be mandatory. Your career counselor will likely advise you not to list your GPA if it's below some threshold (usually a 3.0), but please go ahead and list it anyway. It's easier for all of us if a weak GPA can be weighed against all the other information on your resume at the same time. To put it another way: if you have a really strong resume with no GPA listed, you leave a big gnawing unknown out in the ether. If you at least list your 2.8 GPA and then go on to tell me about a whole bunch of awesome stuff you've done, I can make an informed decision about whether to proceed; if your GPA isn't on your resume, I'm likely to pass it over without ever talking to you.</li></ul><li>Next, list the most interesting and challenging CS courses you've taken. You're shooting for 3-5 here, and if they don't have names I'd intuitively understand (ex: "How to Think Like a Computer Scientist") please do me the favor of translating them ("Discrete Math and Algorithms").*<br /></li><li>Create a section called "Experience" and write down everything you've done that resembles a non-academic programming position. Personal projects, summer internships, research projects, everything can go in here. This is the meat of your resume, and where you're really likely to hook me into wanting to learn more.</li><li>Create a section called "Technical skills" and list every language, operating system, database, and development platform you're competent in. This means leaving off the stuff that you experimented with that one weekend freshman year. I want you to be able to tell me some of the ins and outs of any of the items in this section. I don't expect seniors in college to be experts in anything, so don't be too conservative, but you want to avoid setting off my bullshit meter [<a href="http://blog.jayteebee.org/2008/03/followup-which-skills-to-list-on-your.html">addendum</a>].<br /></li><li>Finally, in a section called "Activities and Awards", list the most important activities you've participated in and awards you've received. This should be much shorter than your "Experience" section, but don't leave it off completely.<br /></li><li>Find someone to read your resume and give you fair and honest feedback. Start with a classmate. If you can, find a recent alum from your program and ask them to review it. Show it to your advisor. You can't have too many people read and comment on your resume. Listen to what they say, and incorporate their feedback.<br /></li></ol>Still with me so far? Great! Keep reading for <a href="http://blog.jayteebee.org/2008/03/cs-undergrads-guide-to-writing-your_11.html">basic tips on what to emphasize</a> and the <a href="http://blog.jayteebee.org/2008/03/cs-undergrads-guide-to-writing-your_12.html">cardinal sins to avoid</a> that will take this recipe and turn it into a winning resume.<br /><br /><i>* Real example taken from the Carnegie Mellon undergraduate curriculum circa 1996.</i>JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-46767736878946448612008-02-01T11:58:00.000-05:002008-02-07T22:09:49.376-05:00The Do-it-Yourself Degree in Software Engineering: Bonus RoundSo it’s six months later, you’re a coding rockstar, you know how to run a team, your organization follows the principles laid out in Peopleware, and now you’re wondering, “Hey, what’s next?” Here are some great reads that are illuminating but not part of the required curriculum. I consider everything I’ve posted earlier as the basic cost of doing business as a professional software developer. These are just for fun, but still very useful in making you an excellent engineer.<br /><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj840ocjulD9_rSWXQR-cdlbUI7PWsuIVB39y1E0uWiOHgQHuDle74XSW8reUyedb_ohDrFLJm4w8SwUsC67dcOYAuT5hst6heqBaZM11hAWLzWh75wQ0ElMpUdJcBpW4RWQwgd/s1600-h/21jY8gsy4zL._AA_SL160_.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj840ocjulD9_rSWXQR-cdlbUI7PWsuIVB39y1E0uWiOHgQHuDle74XSW8reUyedb_ohDrFLJm4w8SwUsC67dcOYAuT5hst6heqBaZM11hAWLzWh75wQ0ElMpUdJcBpW4RWQwgd/s400/21jY8gsy4zL._AA_SL160_.jpg" alt="" id="BLOGGER_PHOTO_ID_5163238021162289202" border="0" /></a><a href="http://www.amazon.com/gp/product/1400082463?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1400082463">Dreaming in Code</a> presents a sweeping view of the history of software engineering, told through the lens of Mitch Kapor and the Open Source Application Foundation’s efforts at developing Chandler, the Personal-Information-Manager-That-Will-Totally Change-Your-Life-If-We-Could-Ever-Ship-Running-Code. It brings together many of the lessons of the Mythical Man Month and Peopleware in the context of a real effort at building a new product.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.amazon.com/gp/product/B00006B6RN?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=B00006B6RN"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLnS_hzjWgxMJP3XimnmjvylJ5htgCrqPdarsozm6Nhj3WNLnLBkHXhGx0Br9MYu-xzJURuwMxXIbMMhwh1_dGs0GCKmzvQsa5gux0OG5xXv_gK9b6zAWtuNjPx1IEeXqDzQKh/s400/21ARTX51QAL._AA_SL160_.jpg" alt="" id="BLOGGER_PHOTO_ID_5163238519378495554" border="0" /></a><br /><a href="http://www.amazon.com/gp/product/B00006B6RN?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=B00006B6RN">Go To</a> is another great history of software, focusing more on the sequence of technical developments between World War II and where we find ourselves today. The exciting running thread throughout the book is the number of great advances that have been made by individuals building the exact tool to suit their own needs. If there was every a compelling argument against software design by committee, this is it.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2n6Epp2yBI7MgUssrkwaLJo-ABbt0S30ZB-xRS8WeHE8OILXyguaaJFAAOcPMwQ1R9w8pmURH4L9mrciNAV58viWNxf8c4-_rh6qDoMaTrRWN_HWzYpG5IRLkISInGVdEDBxq/s1600-h/21R8DSQZZNL._AA_SL160_.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2n6Epp2yBI7MgUssrkwaLJo-ABbt0S30ZB-xRS8WeHE8OILXyguaaJFAAOcPMwQ1R9w8pmURH4L9mrciNAV58viWNxf8c4-_rh6qDoMaTrRWN_HWzYpG5IRLkISInGVdEDBxq/s400/21R8DSQZZNL._AA_SL160_.jpg" alt="" id="BLOGGER_PHOTO_ID_5163239180803459154" border="0" /></a>The <a href="http://www.amazon.com/gp/product/0060521996?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0060521996">Innovator’s Dilemma</a> is an excellent read because it shows over and over how entrenched players in a market are unseated by small teams working with great focus on an emerging market or technology. Every time someone tries to convince me that Google can never be unseated from a position of dominance in search, or that Microsoft and Yahoo are the companies we should be concerned about, I tell them to read this book. For a big company, the competition isn’t the hundred-billion-dollar software shop down the road, it’s a few folks in an apartment somewhere using sheets of plywood for desks and borrowed hardware.<br /><br />There’s a great flipside to the Innovator’s Dilemma, too: if you’re thinking of building something, and you think it’s going to go up against some established megacorp, take inspiration from the number of times that some unproven David has taken down a Goliath.<br /><br />Lastly, <a href="http://www.amazon.com/gp/product/1590597214?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1590597214">In Search of Stupidity</a> presents a unique perspective on how so many software<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxiD8du4dSXGPBVTOv50ASQ68QYc5NW78grfQGbfXPsdjOsshkoIIbppHrwVztwJkC8ZqZm1Wq2CBcUFdQsgZ-USx27xNX_PSVqCv8VUM_ZVdJGxiq3TK9A1UHPm1s1JRwNMRo/s1600-h/21JAK7WBA5L._AA_SL160_.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxiD8du4dSXGPBVTOv50ASQ68QYc5NW78grfQGbfXPsdjOsshkoIIbppHrwVztwJkC8ZqZm1Wq2CBcUFdQsgZ-USx27xNX_PSVqCv8VUM_ZVdJGxiq3TK9A1UHPm1s1JRwNMRo/s400/21JAK7WBA5L._AA_SL160_.jpg" alt="" id="BLOGGER_PHOTO_ID_5163239958192539762" border="0" /></a> companies managed to compete with Microsoft and fail completely. The underlying thesis of the book is that Microsoft isn’t necessarily that great, but everyone else is so bad; Microsoft happens to be the one software company that didn’t make any horrendously stupid mistakes in the eighties or early nineties. You can debate that thesis, but it’s still entertaining to read some of the brain-dead things that Microsoft competitors did.<br /><br />This is now the final final conclusion of my list. Please let me know if you end up reading any of these on my recommendation, and let me know what you think of the books. Enjoy.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com1tag:blogger.com,1999:blog-13502160.post-6627807959092496762008-02-01T11:03:00.000-05:002008-02-06T21:15:43.138-05:00The Do-it-Yourself Degree in Software Engineering: Software Engineering ManagementCongratulations on becoming a coding rock star! You can do anything you set your mind to. You might not be ten times more productive than the average engineer, but you’re probably six or seven times more productive.<br /><br />This now puts you in an unstable equilibrium. Sooner or later someone is going to notice how good you are at building software, and they’ll ask you to take on some form of leadership or management role, in which you’ll be primarily responsible for getting other people to build software. Welcome to a life spent in meetings, doing “coordination.”<br /><br />In all seriousness, even if you never get asked to manage other developers, understanding the principles of how to manage software teams will make you a better engineer. These two books are each a quick read and will equip you with an entire toolbox of ideas about how to make teams work well.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.amazon.com/gp/product/0201835959?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201835959"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 170px; height: 170px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1myxHuS3Pv7gJpckDrycL99hTK6vjnKi8x_sd9N6tpiKtE0e_W6CxD84A11uSeUD-W3_4BNP4QZXoSlpgkIS5s69Meax58MOp62rh4-XUBX-6qnO-6mj9LTzdXp5LmgVYbGFh/s400/mythical_man_month.jpg" alt="" id="BLOGGER_PHOTO_ID_5162044892132362226" border="0" /></a>The first book to read is <a href="http://www.amazon.com/gp/product/0201835959?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201835959">The Mythical Man Month</a>, the classic software engineering text by Fred Brooks. There are any number of things that you can disagree with in Brooks’ treatise, but the logic of Brooks’ Law is fundamental in understanding how to deal with late projects. It’s been 40 years since he made the excellent argument that adding more people to a late project makes it later, and yet, even at enlightened software companies like Google, the first reaction to a late project is to add more engineers.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.amazon.com/gp/product/0932633439?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0932633439"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 192px; height: 192px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEheRKWNyWlb5XGQScIB7v8gE3XCBJ_5t2URgOlwE1FLXAUCwa2DK1KBdNA0M7obP-fNvI8eAxLeUc5vcHE8tf41A0CVU6CvCPYFc0bXsvBIsDASgftTgBfE2wKOPbI0R2TzcvF7/s400/peopleware.jpg" alt="" id="BLOGGER_PHOTO_ID_5162054886521260034" border="0" /></a>Once you’ve read Mythical Man Month, and you can argue successfully with your manager about how to make the right tradeoffs between schedule, quality, and features, it’s time to learn a little about how successful software organizations treat their people. For this, you need to pick up the classic <a href="http://www.amazon.com/gp/product/0932633439?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0932633439">Peopleware</a> by DeMarco and Lister. A lot of people espouse theories about how to operate software organizations; these guys did the research and the experimentation to demonstrate what makes a difference between the mediocre software shops and the stellar operations.<br /><br />I am proud to say that I no longer own a copy of Peopleware. Back in early 2003, when Sergey would still come out to NYC and hang out with the nascent engineering team out here, I managed to get him into a debate about running engineering organizations, and I learned that he had never read Peopleware. The next day I pressed my copy into his hands, and told him to just take it, as long as he promised to read it. We still don’t have private offices at Google, so I’m not sure if he ever actually read it, but at least I tried.<br /><br />Congratulations on making it this far. Upon finishing these books, you will now be qualified for a degree in Software Engineering in the Real World. Tomorrow, just for kicks, I'll share a few more interesting reads that wrap up many of these ideas in a fun package.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-15850583814557729242008-01-30T21:58:00.000-05:002008-02-05T22:26:17.402-05:00The Do-it-Yourself Degree in Software Engineering: Complementary SkillsThe first three books on my list help you build great code, use and understand patterns, and even refactor the legacy code you got saddled with. What are the skills you need to be able to package that up and have a real impact?<br /><br /><a href="http://www.amazon.com/gp/product/0131103628?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131103628"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 133px; height: 174px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiYUtLIL-LcG1zXt_-76A44HUMflNoSqvDwraZDNH2BLil_K2_rMTncYiWEWt7LlZtumBDtC_vL__FzsDMMGhuFTclCa-V4PFh_9y2EVUhkHFMU2PRboJPjN71olWgZ67hsxj4/s400/c+programming+language.gif" alt="" id="BLOGGER_PHOTO_ID_5162040592870098898" border="0" /></a><span style="font-weight: bold;">You need to be able to write. You need to be able to write clearly and succinctly about technical issues. </span> No interesting software is ever built by a team without real debate about the design, and those debates usually happen in written text, via email or design documents. If you want to see your ideas advance, you need to be able to write in a manner that is clear and persuasive.<br /><br />Unfortunately I can’t point you to a text on how to write about technical matters. The best thing I can do is to point you to the archetype of clear, succinct technical writing, <a href="http://www.amazon.com/gp/product/0131103628?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0131103628">The C Programming Language</a>, by Kernighan and Ritchie. This book provides the model every technical writer should use when trying to explain a new technology or concept to technical readers.<br /><br /><span style="font-weight: bold;">You need to be able to work on user interfaces. </span> This is the hardest one<a href="http://www.amazon.com/gp/product/1893115941?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1893115941"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMWJZm8BoJ1M4MYAQxrOIDMC7MzIzourN8Zsfq-6-UplqPYKbaMrQ_OjFp0AvGTVezK-ge3AIC-QBqwNiext6tcSm1zdUnChb3G8lfNwTrknNR1G6ZUp1YIjWTjvrrhjzEOD1T/s400/UI_For_Programmers.jpg" alt="" id="BLOGGER_PHOTO_ID_5161470461731358642" border="0" /></a> for me, because I have no idea how to arrange pixels on a screen to convey meaning. It drives me nuts every time I try. Given a choice, I will hand off UI design to a trained professional every chance I get. But the fact is, skilled UI designers are exceptionally rare, and a service with a working UI is 100 times more meaningful than some script outputting text on a console. Most engineers will never be able to build beautiful interfaces, but <a href="http://www.amazon.com/gp/product/1893115941?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1893115941">User Interface Design for Programmers</a> by Joel Spolsky is a great beginner’s guide.<br /><br /><a href="http://www.amazon.com/gp/product/0201657880?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201657880"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 127px; height: 159px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1HQ2MUtfgvdfkJfInRu7BnofqdWsUlXNhKDIMCvjLn0GuQQqsMKi0Vu36EVkReeqEnTxbipgKStKnrq_-cmiWK5nSB9IGBzCue5GJlUxMn4dSzJJC-YOqg8R4Td9p1g9A0eXB/s400/programming+pearls.jpg" alt="" id="BLOGGER_PHOTO_ID_5162041241410160610" border="0" /></a><span style="font-weight: bold;">You need to know how to think about hard problems in Computer Science. </span> This is a fuzzy concept to describe, but what I really mean to say is, you must read <a href="http://www.amazon.com/gp/product/0201657880?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201657880">Programming Pearls</a> by Jon Bentley. And when you read it, do the freaking exercises. That’s what really matters. I always pose the same challenge about this book when I speak to undergrads: in the chapter on proving correctness of programs, find the bug in the program that is proven correct.<br /><br />Coming up tomorrow: how to learn everything you need to know about software engineering management.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-34682319824161935182008-01-30T21:42:00.001-05:002008-02-04T21:34:14.933-05:00The Do-it-Yourself Degree in Software Engineering: Code Construction and DesignPicking up where I left off <a href="http://blog.jayteebee.org/2008/01/do-it-yourself-degree-in-software.html">yesterday,</a> what are the code construction and design books you need to read in order to become a practicing software engineer?<br /><br />There's one absolutely critical task in building software, and that's creating the actual sequence of operations that comprise your software. If you can't get this right, you're nowhere.<br /><br />Short tangent: think back with me for a moment to the first computer science class you ever took – that one in high school, with the hand-me-down PCs from the typing lab, and the part-time Math/part-time CS teacher. Ah, the heady days when making “hello world” appear on the screen seemed like magic, and HTML felt like a “programming language”.<br /><br />I’m willing to bet that one of the first lessons you learned was about “routines” – nice, isolated bits of code that did one thing and did it well, bits that could be incorporated into other bits with a simple call. Boom, magic.<br /><br />There’s always some smart student in the room who asks, “when do I use a routine and when should I just write the code in-line with everything else I’m doing?”<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.amazon.com/gp/product/0735619670?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0735619670"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhx64lKwGieuIdYNUfMEwmICovsWe5dYwG5JIbaY80A0Q3yL_jNGwlgOXYlvKqV5OFuvvIOpjh7ncKvCP5h1JJh_UzUabXHAcpMUDWTzZcEDF3KhaVZT3TBLPlSiNQquRcbWyVL/s400/code+complete.gif" alt="" id="BLOGGER_PHOTO_ID_5163233790619502610" border="0" /></a>This question has one standard answer given in CS classes all over the world: “write a routine when you’re creating a piece of code that is going to get used frequently.” And for introductory CS classes, for the kind of code written by 16-year-olds, this is a fine enough answer. But for real software, with real users, and more than one developer, there are a lot more reasons to put a piece of code in its own routine. If you can’t name at least three, you need to read the beginning of chapter 7 of <a href="http://www.amazon.com/gp/product/0735619670?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0735619670">Code Complete</a>. And that’s just three pages out of this 800+ page tome! (Aside: by a wide margin, Code Complete is the longest book on my list).<br /><br />If you read nothing else on this list, please, for the sake of software, please read Code Complete. This book is jam-packed with hundreds of little tips that will make your code better, one line at a time<br /><br /><a href="http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201633612"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqCaQ_kcGspvcN-p0klSAtpDjR74t_-QQlmzBuQedUt3if9l3sdKeB20-KUzEamca_Llq8fNzao1Uo8lmjX1AXQmGlQAxmdJTXlm4Y_BCcF6z_FpQnNaTRUtlUNy97ksR68jZD/s400/design+patterns.gif" alt="" id="BLOGGER_PHOTO_ID_5161466420167133042" border="0" /></a>Code Complete will equip you with the skills to start thinking at a high-level about the organization and construction of code. There are two books I recommend here.<br /><br />First, <a href="http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201633612">Design Patterns</a>. A lot of developers like to write off Design Patterns as some pointy-haired fluff, but the fact is, in the 14 years since this book was first published, Design Patterns have become established as a useful shorthand for discussing high-order organization of code. If nothing else, you are likely to encounter other people using Design Patterns when they describe their code, and you need to understand the language in order to communicate with them.<br /><br />There is a risk associated with reading Design Patterns - many people read this book and decide that patterns are the meaning of life itself. I am not advocating that you become a Design Patterns weenie, searching for ways to needlessly incorporate a Strategy or a Factory in your code, or, pure Design Pattern nerd-vana, a StrategyFactory. Nonetheless, there are a lot of fantastic ideas in this book, and your code will be easier to maintain, by yourself and others, if you apply the ideas espoused in Design Patterns.<br /><br /><a href="http://www.amazon.com/gp/product/0201485672?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201485672"> <img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiR2498nZ0NO89w3Yhbr0jCsc895yjukyxzoup3MwGWxQCWc4R0Ws_j8KSMDiHMnO3R6u_RGWcuXpDUs7gJgNvbiq6lHL8I1Irls-ZSw3jpiH1yLKhozWJOqDfszuQBr6s0ieDH/s400/refactoring.gif" alt="" id="BLOGGER_PHOTO_ID_5161466832483993490" border="0" /></a>Next, and finishing out the Code Construction and Design category, is <a href="http://www.amazon.com/gp/product/0201485672?ie=UTF8&tag=softwarantsot-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0201485672">Refactoring</a>, by Martin Fowler. This book is fantastic for the genuine focus on a codebase as dynamic and evolving. For most computer science graduates, working on an existing codebase is completely foreign in academic settings, and one of the first experiences in the professional setting. The ability to think clearly about how to improve the design of existing code, while making strong assurances about the quality of the refactored product, makes an immense difference in your ability to work effectively with software.<br /><br />Once you're through these three books, the raw quality of your code will be immensely better. Code Complete is the longest, but it's a fairly quick read. The other two should be easy to get through in free time.<br /><br />Coming up tomorrow: now that you're writing great code, we'll talk about the skills you need to go along with that in order to round out your abilities.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com0tag:blogger.com,1999:blog-13502160.post-18719090760481095932008-01-30T21:40:00.000-05:002008-02-07T22:08:49.999-05:00The Do-it-Yourself Degree in Software Engineering: IntroDepending on where you go to school, your degree in computer science can be useful for a lot of goals – becoming a professional developer, going into finance or biotech, getting a Ph.D. in computer science, becoming an IT project manager, or even something barely related to computer science. The one thing a CS degree is almost useless for is practical training in how to build production-quality software. The curriculum at most universities, especially the “top tier” universities, is (rightly) focused on an academic grounding in the field, not a practical guide to building great software.<br /><br />I’ve been trying to teach undergrads about this gap between a Computer Science degree and professional software development in a talk that I’ve given twice now, once at Princeton and once at Carnegie Mellon. The kids seem to like it, and the number one question I get is for the reading list I mention.<br /><br />My list is intentionally brief. Anyone with a degree and some spare time should be able to make it through the entire set in under six months. If you haven't read these books, and I mean all of these books, you are probably building bad software. When people talk about the 10:1 productivity difference between great developers and average developers, well, you're on the "1" side of that ratio. Take the time to read through these and everyone impacted by your software will benefit.<br /><br />Just for the sake of your ease in reading, I’ve taken this list and broken it up over several posts. I’ll post the first portion of the list, <a href="http://blog.jayteebee.org/2008/01/do-it-yourself-degree-in-software_30.html">code construction and design</a>, tomorrow, followed by a few books on <a href="http://blog.jayteebee.org/2008/01/do-it-yourself-degree-in-software_4960.html">complementary skills</a>, then books on <a href="http://blog.jayteebee.org/2008/02/do-it-yourself-degree-in-software.html">software engineering management</a>, and finish up with a <a href="http://blog.jayteebee.org/2008/02/do-it-yourself-degree-in-software_01.html">short bonus</a> of fun and engaging books that help fill the gap between a degree in computer science and professional software development.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com1tag:blogger.com,1999:blog-13502160.post-32147739227445906292007-06-22T08:55:00.001-04:002007-06-22T09:03:27.703-04:00Somebody noticed GoogleLookup!Over at Google Blogoscoped, they just noticed that the Google Q&A data is <a href="http://blog.outer-court.com/archive/2007-06-22-n66.html">exposed in Google Spreadsheets.</a> This has actually been out for quite a while, but it never got much press.<br /><br />In my mind, this kind of application was always far more interesting than the Q&A onebox. It's nice to give people quick responses to simple fact-finding queries, but it's far more interesting to aggregate, mashup, and expose data that they can re-use themselves. The spreadsheet integration is just one example of that sort of effort.<br /><br />In addition to the data, it's an exciting demonstration of what you can do with a spreadsheet product that is native to the web. There are a lot of people with big ideas about where this can go from here.<br /><br />Regarding the question about which queries trigger the Q&A onebox: it's based on a corpus that gets updated over time; as the scoring functions and data coverage change, you can expect to see certain queries start or stop triggering over time. I assure you it's still under development.JTBhttp://www.blogger.com/profile/12418301982612783044noreply@blogger.com1