So professionally, this was an interesting week for me.

Wednesday, Chegg shipped their new eReader which is the project I’ve been working on since August. It’s HTML5, and its a faithful representation of the books (more on why that’s important in a bit).

Thursday, Apple shipped an upgraded iBooks, announced a new textbook initiative aimed at K-12, and shipped a new “eBook authoring tool” called iBook Author.

That same day, I had an interesting discussion with a friend of mine about eBooks and their effects on libraries. He had the typical Silicon Valley arrogance for anything non-digital: “those publisher people are dinosaurs and we should legislate them out of existence” . Having lived outside the Valley for most of my professional life, I had a more measured response that the publishers do add some value, and that much more interesting things would happen if we made them allies instead of enemies.

Since iBook Author was free and I’m lucky enough to use a Macintosh for work I immediately had to go and check out iBook Author.

I’m underwhelmed. I know its a 1.0, but there are several missteps here. No print publisher is going to use this tool to create books. Even amateurs are going to find it a bit challenging to produce really high quality books. Even if an amateur makes it through the process, they will then be shocked to find out it will also cost them $125/book to publish their book even if they want to give it away free because you need an ISBN number to publish a book.

Still, its a really well done product, its just not solving the problem in the right way. Hopefully if someone at the relevant team at Apple reads this, they will take this as constructive criticism.

For you to understand my point of view, I first need to discuss some things I’ve learned in the last 21 years of being in the technology industry; the last 5 months of being in the digital textbook industry; and the last 45 years of being the son of an elementary school teacher.

iTunes did not kill the music Industry

Contrary to conventional wisdom, iTunes did not kill the music industry. If anything, iTunes and iPod saved the music industry. iTunes directly saved the music industry from online piracy. iPod helped as well, because they made it easier for people to listen to music.

Yet the music industry’s revenues are down. The music industry’s revenues are down because people spend slightly more of their income on entertainment but across many more categories. That is, the music industry has a smaller percentage of the entertainment dollar. Hour per hour, people have a certain amount of leisure time. They divide that time between music, books, exercise, movies, television, food, renaissance fairs, etc. All entertainment categories have seen a decline, but music has declined less than any other category precisely because iTunes and iPod have made it easier to consume music than any other category.

iTunes saved the music industry! But there’s a reason that all of the music companies are now owned by movie studios, or as we call them now, “entertainment conglomerates” that produce movies, video games, music, toys, etc. Even when people are spending more on entertainment than ever before, there’s more completion than ever before for that same dollar.

Publishers are not the enemy

Unfortunately, the publishers don’t know anything about the entertainment industry. All they know is that like everyone else, their revenues are down. Down by a two thirds! It’s making them understandably nervous and scared. They don’t know what to do about it, because they see what happened to the music industry and they expect it to happen to them with eBooks because they’re blaming iTunes instead of the Internet. Their old business models aren’t going to work any more, and change sucks.

There’s this classic New Yorker cover called the New Yorkers view of the World. In that cover, anything outside of New York is a vast desert; New Jersey is represented by a little mud bank on the side of the Hudson river and so on. It uniquely captures the arrogance of a New York denizen about their town. When I was a kid, I remember meeting people from New York who came out to California; they were always surprised it wasn’t like a John Wayne movie, all horses, Wild Indians and sagebrush.

Silicon Valley people have their own version of this. It’s the assumption that only they know how to do anything digital, and that digital technology is so superior to the “old way” of doing things that anyone doing things the “old way” should just roll over and die. It would be amusing if they didn’t also start arguing that the legislature should make sure that they die.

Here’s the thing. Its not necessary in life to make enemies of everyone who disagrees with you. In my job, I have to negotiate with the publishers all the time, and I never, ever approach them as the enemy. Do they ask for things that are unreasonable? Yes! But as I’m constantly telling my co-workers, they’re reacting from fear. So it doesn’t matter if their request seems irrational. You can’t argue them out of it with logic, you have to address the fear. It’s basic human relations that when people are reacting from emotion, you have to deal with the emotion first. When we do that, we get a much better response from the publisher.

Publishers are not in the dead tree business

The standard business school myth is that the railroad companies, once the largest and most profitable businesses in the United States, didn’t realize they weren’t in the railroad business, they were in the transportation business. As a consequence, they didn’t seize the opportunities presented to them by the rise of the trucking industry. Gradually that led to them become irrelevant because they couldn’t adapt. The thing that always bothers me about this story is that we could have had container shipping 100 years ago. Computerization helped, but we had people with clipboards 100 years ago.

The thing you have to realize is that textbook publishers are not in the dead tree business. They are in the education business. The publishers realize this. The holdback for electronic education has always been more of a problem of platform (Windows was too hard to use), expense (computers were too expensive), and the system (you have to get all the bureaucrats to agree). Plus let’s face it, no one really knows what e-learning looks like yet. Even eBooks are just a Old thing in a new package, and it’s not clear the new package is really better because dead trees don’t crash and need to reboot.

Currently, we’re in a transition period, which means the publishers are “living in interesting times”. Cut them some slack! The face of education is changing, and the publishers are desperately trying to figure out what e-education looks like. Before you mock them as dinosaurs, realize that no one else knows what e-education is going to look like either.

Textbooks are 50% design

Someone commented to me that Calculus hasn’t changed in 100 years, so why do we need a new Calculus textbook?

One of the most popular text books on Chegg’s site to rent is a textbook about how to use Microsoft Office 2010. Think about that. The most popular book, is about a subject that didn’t exist until 2 years ago. It’s also about a piece of computer software. Textbook publishers definitely do crank out edition after edition. Some of that isn’t warranted. But so does the computer industry! Leave the Silicon Snobbery at home. The Publishers are creating value in the world. I’m not sure that’s true of many Silicon Valley companies.

I’ve spent the last few months looking at a lot of textbooks, and I can tell you, these aren’t the textbooks I had in school. Calculus may not have changed, but the way we teach calculus has changed. The textbook publishers have taken every trick in the book made possible by desktop publishing and brought that level of design into the textbook. Textbooks are now 50% design, 50% writing. It would be a very cool thing if we started giving textbook designers credits in the same way we give the authors, or for that manner, film directors.

Yes, you can read Harry Potter on your iPad. But trying to shoehorn a modern textbook into ePub loses half of the design sensibilities present in the textbook design.

Neither ePub 3.0 or HTML5 can capture the fullness of a modern textbook. If you don’t believe me, try to to implement a sidebar, notes in a margin, and 2 column reflowing text, with an attached picture in HTML.

It can’t be done. CSS teases you into thinking its almost possible but it’s not. HTML cannot reflow text into columns! it can’t move a picture to float into the margin while the text reflows. For that you need a layout engine.

The ideal textbook writing application

If I was going to sit down and write an application to write textbooks I would start by thinking about the components of a textbook. Because what I would want would be something that I could use to describe how the information in a text book relates to each other and to the page. For instance picture the following 6 interrelated items:

• A block of text describing a concept. It should be nicely formatted on the page, justified, with two columns in landscape mode.
• A picture that goes with this block of text as an illustration.
• A caption that goes with that picture.
• A margin note goes with the block of text near about the center or rather next to the 3rd sentence in the 4th paragraph
• After this text, present this sidebar.
• A footnote is associated with this portion of the text.

While that seems like a lot, what I’m describing isnt any more complex than the layout of a “Dummies” book. That doesn’t seem like a particularly high bar to aim for! The textbooks I’ve spent the last 5 months looking at are considerably higher quality than this. In those books, every page is hand crafted.

Thinking about the components of a textbook would help me to build a data model to describe how the pieces of information in a textbook relate to each other and what those pieces are.

The next step for me in building this tool would be to reimagine how those elements should work in an e book. Not every print convention makes sense on a tablet. Do footnotes really need to be at the bottom of a page? Why not have them function as popups? What about footnotes that are extended asides? Should margin notes stay in the margin or should they be popups as well? What about sidebars?

So now I have a data model and some presentation ideas. The next thing I would need to build would be a layout engine. Because each reader has a different aspect ratio, and even the iPad is both a 4:3 and a 3:4 device, my ebook tool needs to be able to algorithmically layout a book the same way a human would layout a book.

That’s how I would build an ebook tool if I really wanted to revolutionize the text book industry.

Which brings us to iBook Author

iBook Author is not built the way I would build an eBook authoring tool. That’s because iBook Author makes a couple of simplifying assumptions.

• It only supports the iPad, that is 4:3 or 3:4 book orientations. iPhones, Kindles and 16:9 devices are not usable. Nor are laptops!
• The tool will be used to layout the book once, not write the book.

These assumptions are both iBook Authors greatest strengths and simultaneously it’s greatest weaknesses. iBook Author has no real provision for automatic layout of a book beyond basic text reflowing. It has no understanding of basic textbook idioms like sidebars, callouts, figures, tables, margin notes, etc.

What iBook Author instead understands is that on page X there are some boxes with certain specific pieces of content to display, in certain locations. If the iPad is in the other orientation, these boxes will be on Page Y instead, and they will be in these locations instead. Boxes can sort of float with specific pieces of text, or they can be on a specific page.

In other words, IBook Author is mostly a page layout tool. To get the same level of quality as a existing textbook, you would start by taking your existing textbook layout and throwing it away. Now you can rebuild your textbook as an iPad book from the original content.

Then, when you’re finished with that, you have to start over and layout the book all over again for the other orientation of the book.

So is it possible to use iBook Publisher to layout a modern textbook? Yes! People used to layout textbooks with paper scissors and glue. But it would also be incredibly tedious. Will the textbook publishers revamp some textbooks into this tool? Yes, especially the textbooks that are mostly text. Technical books such as the O’Reilly books that start out as a Word documents and essentially remain that way even in printed form will be easy to convert because layout isn’t really a factor for those books.

In fact, those sorts of books don’t need iBook Author. You can get any of the Pragmatic Programmer line of books in EPub or mobi already. In fact, Pages will already export to EPub for you without any weird licensing agreements required.

IBook Author is only interesting for books that require conplex layouts. But complex layouts mean complex work. Work that has to be done by someone manually. Is McGrawHill going to layout their entire 1,000 college textbook Catalog in IBook Author, then lay it out again for the other orientation? Not this week! not unless they hire 1,000 graphic designers to get it done.

No Programming required means it’s lame

The other big feature of iBooks are the widgets. Again, color me unimpressed. They’re pretty basic. There are 6 predefined widgets:

1. Gallery.
2. Media (movies and such).
3. Review.
4. Keynote.
5. Interactive image.
6. 3D.

There’s no real wow here. If your really want interactivity, you’re going to have to program it yourself, but you’ll only be able to go so far as a widget. Embedding Keynote is going to be kind of weird, because you open a book, then there’s a presentation inside the book? That seems like a strange user experience.

So at the end of the day, while iBooks Author is cool in many ways, I don’t see it replacing high end textbooks any time soon. Low and medium end textbooks will do just fine in the existing ePub format, but it will be too tedious for textbook publishers to layout their complex textbooks twice until the market has proven itself. While the widgets are kind of neat, none of them are especially innovative.

The “Fuck You” dialog

So lets say you do all this work to layout your book (twice!). You’re ready to export the book. What do you get? This dialog.

As others have commented, using iBook Author locks you into somehow involving Apple with selling your book. The license agreement goes on to say:

IMPORTANT NOTE:
If you charge a fee for any book or other work you generate using this software (a “Work”), you may only sell or distribute such Work through Apple (e.g., through the iBookstore) and such distribution will be subject to a separate agreement with Apple.

Apple will not be responsible for any costs, expenses, damages, losses (including without limitation lost business opportunities or lost profits) or other liabilities you may incur as a result of your use of this Apple Software, including without limitation the fact that your Work may not be selected for distribution by Apple.

A format that doesn’t work with a publisher’s workflow, differs in important but subtle ways from standard formats, isn’t supported by any of the industry’s tools, is, long-term, going to be a torture to support.

So Chegg launched our new eReader today so I thought I would take a moment to talk about writing a Project Charter per Johanna Rothman’s excellent book on project management.

Johanna recommends that for every project you sit down and write out a project charter. The project charter states the purpose of the project, additional goals, the single driving factor, and any constraints. Everyone on the project should be able to state why they’re building the project. Meanwhile, the project manager should know what the real driving factor for the project really is because that’s going to be the key to managing the project.

When I got to Chegg my boss gave me a set of desired attributes for a content management system based on his experiences at Netflix. He also gave me a deadline.

When I sat down to write the project charter I discovered an interesting thing. The project driver wasn’t what anyone thought. The fundamental driver for the project was that we needed to be able to convert 40,000 books in 2 weeks.

Figuring that out actually simplified the problem quite a bit. What we needed was not a content management system like we thought, but rather a cloud-friendly job coordination engine. The deadline, while a constraint, wasn’t the driving factor in the project. Doing 100 books by the deadline wasn’t interesting, it was doing 40K books for the launch that was interesting.

Writing a project charter made sure I built the right thing in the right way.

You can get Johanna’s book at Amazon, I highly recommend it.

A friend of mine who is job hunting (he’s looking for a job in Software QA if you know of any positions) emailed me this morning for help with his job hunt.

Here’s my tough-love answer:

Your job right now is looking for work. If you’re not spending 35-40 hours/week on looking for work, you’re not doing it right. That does not mean 35-40 hours/week sitting at your computer. That’s the least productive way to get a job. You get a job by meeting people.

Have you gone to any of these meetings?:

http://www.ssqa-sv.org/speakers.htm

It took me 10 seconds to find that group. That’s the kind of thing you should be doing. Sending a resume somewhere and having that actually work for getting you an interview is like winning the lottery. Meeting someone at a group like that is easy, and its like getting 5 interviews for no effort.

I couldn’t do it when I was in Flagstaff, but even though I’m not looking for a job any more, next week I’m going to my college alumni luncheon so that the next time I go looking for a job I’ll have 15 people I can call. Additionally, when my new company is looking for people, I’ll know 15 people I can recommend.

Besides hard core networking, in addition to the 35-40/hours week you need to spend looking for work, you need to be spending 10-20 hours/week Sharpening the Saw. That means exercising, learning a new skill, etc.

Finally, looking for work can be demoralizing because you do a lot of work before you see any success. When you see success, you’re done. You need to reframe the way you approach this so that you can refill your success well.

That means you need to start logging everything you do while looking for work. That’s what I had to do, I had to reframe things so that just doing the work was “success”. That also helped me budget my time so that I wasn’t doing too much of the things I liked to do (spend hours on the computer browsing websites) and more of the things I didn’t like to do (networking). Pick the part of the job hunt you hate the most (for me it was cold calling) and any day you do two of those in a day is a “win” for you.

There’s a scene in the movie Good Will Hunting where Matt Damon tells this stuck-up guy in a  bar:

” You blew $150,000 on an education you could have gotten for a $1.50 in late charges at the public library.”

Bar Scene from Good Will Hunting

Something I’ve done for years is prowl around college bookstores about the time the term starts and see what textbooks were selected for what classes. If the textbooks are good, I often buy them and read them on my own. Right now I have textbooks on my bookshelf on:

• Molecular Biology
• Protein Structure
• Biomechanics
• Behavioral Economics
• Astronomy
• Architecture

I’m always learning. I call this the Good Will Hunting method, because why should I pay some university a bunch of money for a piece of paper?

I was talking with a recruiter about a position at their company the other day and after reading the job requisition I commented to her that it was a “Bigfoot” requisition; the kind of req that reads “Must be a Lawyer and a Pastry Chef”.

There’s no way that the recruiter will be able to find a person to fill that req. All of the lawyer’s I know who burned out and became pastry chef’s are quite happy in their new bakery business. So what will happen instead is that the hiring manager will hire someone he knows and grumble about how HR can’t find anyone good.

So it goes.

Personally I’ve always hired for brains+attitude, not necessarily some specific laundry list of tech skills. My best engineer in my last position ported himself from Windows and C++ to MacOSX and Java in about a month; as I knew he would. I needed someone who knew object oriented programming and could design servers, Java was ultimately optional.

The silliest for me is when I see people listing source code control systems like svn, git and SourceSafe in a req. Are you really not going to hire someone who lists cvs on their resume? For that matter, who lists source code control applications on their resume?

The recruiter came back to me with the following:

I love the way you think… It’s always smartest to hire the best athlete and watch ‘em perform in the role. All the minutia is ridiculous.

Now, identifying a “best athlete” who’s not a referral… that’s a whole ‘nother challenge for those of us doing the hiring, isn’t it?

Ok, Stacy, challenge accepted. Here’s how to identify an athlete that’s not a referral, that is, from a resume. So, first rule:

• Athletes break the resume rules for specialization

Picture yourself as a software engineering manager with a star athlete on his team. Over and over you are going to find yourself saying to the athlete: “Can you help Fred with this? Can you look into this new technology for me? Can you work with Barney on that problem he’s having? Accounting is whining about Billing, and that involves money so we better fix it. Can you figure out what we need to do?” The athletes on a development team are going to have the broadest experience in terms of problems you’ve asked them to solve.

Translating that to a resume, software athletes are people that look like generalists, because their resume will show lots of broad experience. Broad experience is much more interesting in the long run than “depth” in the particular skill you’re looking for; tech skills rarely last longer than 5 years.

My resume for reference. I have been a software athlete, and am now a coach (Director/VP) of athletes.

Specifically, that means that if you’re looking for a Java engineer, a resume that lists:

• C++, Python, Perl, Ruby

Is quite probably a much more athletic engineer, and a better hire than one that lists:

• Java

That’s because the 4 languages above have their own strengths and weaknesses. Someone who gets object-oriented programming in C++ is going to pick up Java pretty quickly, and they’ll have learned things from doing programming in Ruby and Python that will serve them well with Java. Someone who has done Java and only Java for years will be much more narrow and less versatile in the long term. After 2 months, the C++/Python/Ruby/Perl guy could easily know more about Java than the original Java guy, because he’s more curious in fact, that’s been my experience.

Similarly, you want to look for the same sort of breadth in achievements. Someone who has the same 6 months of experience 10 times is not going to be a good hire. I call those people IT mushrooms because its common to see someone from the IT department at a big company who did the same thing for 5 years. Just like a regular athlete can do 20x what an average joe can do, so can a software athlete be 20x more productive than a regular software engineer. Software managers give their star athletes giant tasks to accomplish, tasks that are often hard to distill down onto a resume.

So if I was looking for someone with Business Intelligence experience, given a choice between:

• Developed 8 reports for Accounting using Oracle Business Intelligence system

and

• Reworked billing.

When asked to find a person with high-end Business Intelligence experience I would most likely hire the second guy. Because what I know happened is that billing was broken somehow and Accounting was always whining (it was taking too long, etc.). So I asked my software athlete to “Fix billing”. He fixed it, which involved meeting with Accounting to figure out what their needs actually were, setting up an ETL process from the OLTP database into a data warehouse, setting up the BI system, and developing a couple of reports. It probably took him 2-3 months.

After that, I would have assigned the first guy, the mushroom, to follow in the athletes footsteps and do any additional reports Accounting needed. It probably took him about a month to do each report, sometimes more. So even though nominally the first guy looks like a closer fit for the position, the athlete is the one that really did all the work.

Of course, I have an advantage as a technologist, that I can skim a resume and tell if a person is an athlete or not to a decent approximation. What are recruiters supposed to do? My suggestion is to get the hiring manager to follow the process I use when working with recruiters:

1. Talk to the hiring manager about whether they want an athlete for this position. “Do you want an exact match, or a smart guy?”
2. Select 20 resumes at random, after throwing out the obviously bad ones. (Grammar problems, misspellings, web designer for a programming position, etc.)
3. Have the hiring manager sit down with you and sort the resumes from best to worst, with the specific idea that you’re looking for athletes. They should immediately know which technologies overlap which other technologies and what tradeoffs they’re willing to make. Have them explain the top 5 resumes they selected to you, possibly against the bottom 5. You’ll get a lot of good information out of this about what they really need for the position, because as a hiring manager, I have to say that my job requisitions are rarely perfectly written…
4. Repeat steps 2-3 occasionally if needed if you’re having trouble finding a match.

This information gathering exercise will tell you a lot about what the hiring manager really wants, not what the job requisition says!

From your meeting with the hiring manager, you should now be able to glean a few “possible athlete” resumes from your queue for the position. The next step is in the phone screen. When phone screening for athletes, your goal is to separate the jack-of-all-trades-master-of-none candidates from the master-of-all-trades-throw-me-at-a-problem-and-I’ll-kill-it athletes.

My two biggest tools for doing this are the questions “How did you do that?” and “Why did you do it that way?”. It’s nice but not necessarily important for me to understand the details of their answer. What I’m looking for are that there are those details, that they really dug into the problem, solved it, and moved on. I’m looking for something that for any other candidate would be 2 years of work and required training classes but the athlete did in 3 months. I’m also looking for people who had a hammer in their hand, but had a problem that was a screw, so they put down the hammer and went and found a screwdriver. Finally, I’m looking for brains.

I can’t explain it any better than that, but it’s obvious to me when it happens during a phone screen.

So after scanning resumes, phone screening the results, and hopefully finding one or two possible athletes, that’s the point where I would make a note on the resulting candidate “May be athlete”. Because the manager is going to interview a potential athlete differently than they’ll interview someone who is merely a close fit.

I hope this helps, let me know!

Background:

This is the first time I’ve ever really applied myself fully to hunting for a job. Looking back, I’d always done a mediocre effort at it while simultaneously working full time. Job hunting requires 20-30 hours/week of work to be effective. Only about 4 hours/week of that relates to submitting resumes; the rest is researching companies, learning about job hunting, online stalking networking, contacting people, following up with companies, etc.

Job hunting is really a lot like managing software development.

The kind of job I’m looking for is a Director-level job managing software engineers; basically what I did at my last job though I wouldn’t turn down a step up to a Senior Director or VP-level job. I also want to switch from the small companies I’ve always worked for to a larger company with more resources. The kind of projects that I find interesting are too hard for small companies to pull off, and wearing multiple “hats” so I have more responsibility is becoming less interesting than focusing on one really big hat.

That means relocating from Flagstaff, but De and I had a state-of-the-union recently and realized that since we can’t have kids relocating to somewhere more urban makes sense. Especially if I want to manage engineers, Flagstaff is not the place.

So I’m looking at innovative technology companies like Apple, Google, Yahoo, Amazon, Rackspace, companies that are either using the internet in interesting ways, or companies that are creating interesting technology. I hate Windows, so I’m avoiding companies where I might have to type LPCTSTR, i.e. Windows programming. Since most internet stuff is Windows-free, that’s not as drastic as you might think. Really my requirements are “software development senior management, non-Windows, and willing to pay for relocation”.

The Challenge:

The challenge in all job hunting is that most jobs aren’t advertised. Mostly people hire people they know, or know of. Its only after they’ve gone dry that they advertise the job. ( If you think about this, how many times has your manager said to you “hey I need someone to do X, do you know anyone?” ) It’s even worse at the Director level.

The job hunting books tell you that the solution to this is to bypass HR completely by networking your way to the hiring manager, or even better the hiring manager’s manager. At Director level, the hiring manager would be the VP, with the manager’s manager being the SVP or CTO. It’s pretty hard to network your way to that level. That kind of cold calling is also something I’m not particularly good at; I’m an engineer and it feels like stalking to me. Plus those people are pretty busy. I’m also at a disadvantage because having worked mostly at small companies, the networking pool is smaller. Some of my best contacts are from my days at Radius because it was the largest company I worked at but I feel funny bugging someone I haven’t talk to face to face in 16 years.

Meanwhile, the job hunting books tell you that your chance with a resume submission are about 1 in 200. Then they tell you to submit resumes anyways. I will say that submitting to Monster, Execunet, and RiteSite wasn’t very useful; about all its gotten me is an email a day asking me if I want to be a life insurance salesman. I’ve had better luck with the companies websites directly.

My Solutions so far:

So I’ve had to learn how to really job hunt. Here’s what I’ve come up with so far:

Networking to Internal Recruiters: Rather than trying to network to the hiring manager, I’ve had fair luck with networking to the internal recruiter instead. I have a pretty strong resume and skill set so if I can make contact, that’s usually lands my resume on the hiring managers desk which then leads to at least a phone screen. That meant getting serious about LinkedIn, and learning Twitter. I’ve avoided FaceBook so far.

Aimed Resume: If resume submission is about 1 in 200, devoting a lot of time to customizing your resume doesn’t make a lot of sense. But a recruiter wants to be able to scan your resume in 20 seconds and see if you fit the position. My compromise has been to do something called resume-aiming which lets me customize a resume quickly. I talk about that in-depth here: http://bit.ly/aimed-post

I’m getting about 2 in 5 response rate after aiming my resume. Networking still helps though.

Books that have helped:

Resume Magic: Reading this book made me realize that I’ve been writing terrible resumes for 20 years. If you’ve been starting with the Microsoft Word resume template, get this book: http://amzn.to/lgGJhP

Interview Magic: This book was very helpful with preparing for interviews. You really need to have a set of 10-20 prepared anecdotes about stuff you’ve done and who you are. You don’t want to practice interviewing during an interview like most people do. http://amzn.to/j7gFgV

The Unwritten Rules of the Highly Effective Job Search: One of the most frustrating parts about job searching is the fact that you don’t really get any feedback so its hard to keep your success well full. This book was really helpful, and I now keep track of all the stuff I’m doing as part of my job search purely so I can feel a sense of accomplishment. http://amzn.to/jgiOuZ

Programming Interviews Exposed: Certain high-tech companies are following a fad of asking tricky programming or brainteaser questions. I doubt the utility of most of these types of questions as I prefer to hire on a combination of Brains + Attitude. This is a good review book though if you’ve forgotten the tricks for dealing with singly-linked lists and other obscurities, and it covers other parts of the interview as well. My first reaction to any “say you have a singly-linked-list” question is “can I fire the idiot who used a singly-linked list and replace him with someone smart enough to use a doubly-linked list”; but you probably shouldn’t say that in an interview since what interviewers really want to know is “could I stand to work with this guy”. http://amzn.to/kPOFlh

www.glassdoor.com collects interview questions, so I’ve been using that for practice. It also describes what its like to work for various companies, but be prepared for lots of whining.

Ok, so you’re working at a non-Agile shop, possibly even a shop with bad project management. How do you get them to being Agile if you’re not the CEO or VP of Engineering? By doing something I call:

CrockPot Agile

CrockPot Agile is my term for converting your shop to Agile development by making a series of small improvements in the development process as it exists. As you make these small improvements, you will build street cred with your fellow developers and with management. From these small steps you can eventually build up to Agile, and it will seem like a natural progression. You’ll look like a total genius during the process, which is good for your career. You also won’t run into nearly as much resistance, because you’re not promoting giant changes, just small, logical, useful steps.

Step #1: Nightly Build & Deploy to Test

Setup a nightly build that deploys to a test server. People have leaky brains. When a developer writes some code and checks it in all knowledge of that code immediately starts leaking out of his brain. Similarly, if a tester finds a problem the details of that problem starts leaking out of their brain once they send the bug report.

So if you’re not building and deploying nightly, then you have a large amount of brain leakage between the developer checking in some code, the tester finding a problem, the developer fixing the bug, the fix getting deployed, and the fix getting verified. Plus there’s a lot of friction between QA and Development about whether or not a fix is available to QA and so on. Lots and lots of unproductive waste.

To illustrate, say a developer checks in some code on Monday. Let’s say there’s a deployment on Friday afternoon at 4:30pm. So on Monday #2, the tester notices a problem, and posts a bug report. It’s now been a week. Maybe the developer knows, maybe he doesn’t where the problem is; its been a week. Let’s say he figures out the problem and fixes it though on Monday #2, a quick turnaround. The fix will now languish until Friday. Monday #3 is now the earliest the tester will be able to verify the fix, assuming they remember how to reproduce the problem. That means it takes 2 weeks to close a bug! That’s with a weekly build, your shop probably isn’t doing even that. If you’re building “when the developers feel like it”, it may be even longer.

If you deploy nightly, if a developer checks in some code on Monday, it deploys Tuesday. If a tester finds the problem immediately, the developer can almost always pinpoint the problem quickly, because the problem is in the code they just changed. The developer immediately fixes the problem, checks in the fix, and on Wednesday the fix will be verified and closed. You’ve taken the cycle time for a bug fix from 2 weeks to 2 days!

If you setup a nightly build, QA no longer has to bug development about when the fix is ready for testing, and they don’t have to go through a giant backlog after every deployment to test. Instead, every morning QA can simply look through the fixed bugs and verify and close them. Then when a fix doesn’t work, or its only a partial fix, the development team gets immediate feedback and no leaky brains! QA and development also get in the habit of working closely together.

So Step 1: Setup a nightly build. Then give a speech about leaky brains and how a nightly build means everyone has less to remember.  I recommend Hudson.

Step #2: Continuous Integration

Once you’ve got a nightly build going for a while, (hopefully with Hudson), it’s a quick jump to Continuous Integration. At this point, the other developers may even ask for this; that every check-in triggers a build and emails the development team if it fails. You don’t want to do a deployment for each check-in, because you’ll drive your QA department batty if you’re constantly taking the server up and down. But you do want engineers to get immediate feedback if they’ve broken the build, especially if you’re building for multiple platforms. If you’re working on Mac and you break Windows, you might not know for a while otherwise. Again, it’s a leaky brain problem.

Step #3: Unit Tests

Ok, so you’re now on a roll. Just changing the build process has built you a lot of street cred with QA and your fellow developers. You can now add running tests as part of the build. The way to sell this to your fellow developers is simply to point out that the nice thing about tests is that it’s often easier to check the code they just wrote via a unit test then it is to set up all the other pieces of the system. Writing test code makes checking your work easier, and then having that integrated into the build is just gravy.

Don’t try to sell them on Test Driven Development. Instead, just convince them it will make their lives easier. In most modern IDEs, its trivial to run a test case. In every development environment I’ve worked with though, the code I’m working on at the moment is part of a larger whole, and setting up the whole is a Pain-In-The-Ass. It’s easier to write test code for a unit then it is to fire up 20 other units. Nearly all developers will buy into this once you show them how the IDE can run test cases for them. Plus, running the code you just wrote through a test fills your success well.

This is a good time for you to think about building some test infrastructure; like the ability to load YAML files for data, setup/teardown a database, etc. Integration testing is always a pain, but if you have some good foundations, you can eventually get your co-workers to write integration tests as well. For one thing, they now run every night and every check-in, so they’ll see the immediate value. You have to get them to write some tests first though, but once they do, they’ll realize it’s another leaky brain issue, and they’ll start to prefer code with tests.

Step #4: Respect QA

See my post here: QA

Step #5: Check In [CI] Emails

Start sending to everyone in your group and your boss an email titled “[CI] Your name YYYY-MM-DD” with bullet points for the following:

• What you did that day
• What you plan on doing tomorrow
• What you’re stuck on.

(Yes, it’s a 1-person scrum in email form. I don’t call them that, because I invented them in 1991 at my first job, which predated scrum, so there.)

It will take about a week for about half of the rest of the development team to follow because actually, your co-workers are interested in what you’re working on so they’ll start doing it too. By the end of the week your boss will mandate it across your development team, he’ll like it so much. Ask your boss to do his own [CI] email so you know what’s going on with the big picture. Thank him/her when they comply.

Step #6: Release Trains

Once you’ve got your code being built nightly and tested to some degree, you can introduce the concept of release trains. The idea here is that there will be regularly scheduled releases (whatever release means) as if there are trains pulling out of a station hourly. So it’s not critical to fix every bug and then to “freeze”. If what’s on the web site now has more bugs than what is in test, why not push out the new version? Why make users use the old crappy version?

Of course, to do this, you must have confidence with what’s in testing, which is why Steps 1-4 need to be done first. And some amount of “freezing” is important. But modern version control systems support branching well enough this shouldn’t be an issue. So you branch for the release, and then development can continue on the head branch. The branch is the release train that is pulling out of the station, the head is understood to be the next train. If you’ve got continuous integration running, you should be able to set up a second test server for the branch that is built by the same build system.

The benefits here are more intangible. It gets people focused on the big picture of the development process of release, release, release. It keeps both QA and development continuously productive and gets them in the habit of continuous testing and development. It lowers the stress of both QA and development when they know that a bug fix can catch “the next” train. This is also the beginning of transitioning to Agile, but don’t tell anyone that!

Step #7: Project Planning Step Zero – A To Do list

Ok, so now development is humming along, but are they doing the right things? The next few steps relate to introducing good project planning to the organization. So now you can push for building a list of everything that has to be done. This involves doing a certain amount of design up front. I call this “Step Zero” for project planning; making a to-do list of what you have to do.

You may think you’re doing this already. Are you sure? It’s very hard to know everything you have to do without doing at least some engineering design work. Joel On Software has some good stuff on this.

This step will probably meet the most resistance in shops with no project management, where engineers just want to “start coding”.

Step #8: Prioritize the To-Do List

Ok, so you’ve got a to-do list. There’s probably too much stuff on it! Start organizing the list so that the stuff that’s most important (technically hard , important feature, or risky) gets on the earliest release trains. This will seem stupidly obvious to everyone once you point it out. Suggest people work on the to-do list in order.

Step #9: To-Do Poker & Story Points

Now you have to actually sell. Convince people that relative estimates are more accurate than regular estimates (Joel On Software is wrong in this case). Introduce the concept of to-do poker for estimating relative complexity. Add complexity estimates to your to-do list.

Step #10: Start doing Iterations & Burn Down

It’s probably at least a year later now, and everyone thinks step 1-9 were your own brilliant ideas; you’ve been promoted to manager of the group. You’re doing release trains already, so breaking those up into Sprints, and tracking your Story Point Velocity and doing a Burn Down chart is going to seem natural. So are Scrum meetings.

Whether you tell anyone your development team is now “Agile” is up to you.

Here are some books to get you started:

One of the useful concepts I learned in martial arts was the idea of a well of success. I’ve found the concept useful both for managing people in general, and for understanding while Agile teams report such large productivity increases.

Success Well

Every person has a success well. If you try something and fail, your success well empties. If you try something and succeed, you success well fills. If you do something big, it fills a lot. If you do something small, it only fills a bit.

The kicker is that you are only willing to attempt a task of a size equal to the amount of success in your well, because you aren’t willing to go negative. Going negative generally causes a severe blow to your self-esteem. So if you are going to attempt something quite large you either need to build on an earlier large-scale success, or on lots of small successes. Success breeds resiliency to failure, failure breeds paralysis.

Similarly, if you’re managing someone, you need to be aware of that person’s success well. If you give them a task too large they may stall for a while doing small things before attempting it. If you give them a task and are unable to support them adequately so they fail, if the project is canceled or some other sort of failure you may need to give that person a series of mini tasks that you know they can complete successfully. Those mini tasks allow them to raise the water level in their success well. Until their success well has been raised to a sufficient level, they will only pretend to work on larger tasks.

You can also manage people’s perception of failure by giving them positive feedback. As their boss, the words “I gave that task to you even though I knew it was hard, and as far as I’m concerned, you did the best you could under the circumstances.” can turn a perceived failure into a perceived success.

Agile and the Success Well

I think that some of the reported productivity improvements of Agile are due to the success well. If you understand the success well, and you combine with the toxic environment common to corporate IT departments and IT consulting where Agile started it all starts to come together. In all the Agile literature they make a big deal about how many software projects get canceled before completion. This is all too common in IT. Engineers work hard on a project for months or years only to have it vanish. The result is cynicism, turnover, and crippled productivity. Any minor setback looms large for those with a shallow or empty success well.

Under Agile, with its emphasis on constant iterations, development teams are constantly rewarded with success. Success breeds success; the team gets addicted to that success and small bumps in the road are nothing compared to their overflowing wells.

Meanwhile, and this is one of the real geniuses of Agile, things cut from the “backlog” to ship the product on time are not failures because no one ever started working on them. Projects are never canceled; they are just “stopped” and declared complete.

So not only does Agile actively work to fill people’s success wells but it also keeps from draining them.

Drop me a comment if this idea has helped you.

If I call the recruiter at the company too soon I’m desperate. If I wait too long, I’m not interested.

Recently, I was at a company website browsing for jobs. As usual, I ran into a typical catch-22: Every career advisor on the planet will tell you to customize your cover letter and résumé for the position, but I have yet to run into a website that lets you upload a different résumé or cover letter for each position. Being a software architect, I immediately had to think about how to fix the problem. I came up with an idea I figured was simple, and incorporated feedback I’d heard from recruiters about their own frustrations with the hiring process.

I took that idea and contacted a recruiter I had met in the course of my job search, Michael Long at Rackspace.  Michael is in charge of the RackerTalent.com website and responsible for helping drive the next generation of their recruiting tools, so I figured he would be a good person to ask. (@theredrecruiter on Twitter) Michael told me it would make a good blog post, that I had a good understanding of where a recruiter is coming from because of the sheer volume of résumés they are dealing with.

So hence this post. I’m proposing a simple approach for résumé submission that both recruiters and job hunters can use to work around a problem in recruiting systems as they exist today. I’m hoping that by bringing job hunters and recruiters together that we can work out something that will make it easier for job hunters to demonstrate they are a good fit, and make it easier for recruiters to find job hunters. (If you are a recruiting systems developer, email me at pierce@twinforces.com for my thoughts on how you can fix this in the next generation of recruiting software.)

Background of the Problem

Sending out résumés is both important, and one of the least effective ways to get a job. It’s an important part of the process, because a résumé is how you market yourself to employers. Even if you’ve done all the online stalking networking career counselors recommend as necessary for finding a job, at the end of the day, you still need a résumé for people to look at.

So you need a résumé, and you want one that is a good as you can possibly make it. I think of this résumé as the Networking résumé, others call it the Generic résumé. This is the résumé you send out to people when you don’t know exactly what the position will look like. 75% of jobs that are filled before they are ever published, so you want a résumé that’s kind of broad because you’re trying to network your way into a Job. You can see mine by going to my LinkedIn profile. If I have a firm nibble from someone, I can then take my Networking résumé and make it more focused for a position by going deeper. Another approach is to tie position requirements to specific past positions in my résumé, etc.

If you’ve successfully networked your way to a hiring manager, you’re already in the top .2% of résumés for this position. The recruiters I’ve been talking to say that they can get 2800 résumés for a position. Meanwhile, the hiring manager may be only willing to look at 5 résumés or .2%. If you can network your way to the hiring manager to be that sixth résumé, you’ve raised your chances from 1 in 2800 to 1 in 6.

At that point, your chances are much better for getting an interview. Because hiring managers don’t hire résumés they hire people. As a hiring manager, for every position I’ve ever hired for I really only wanted two qualifications:

* Brains
* Attitude

That’s because I’ve been writing software for 20+ years and managing and building software teams for 11+ years. At the end of the day, I can teach someone a technology, but I can’t make them smarter. You can probably teach attitude, but unless you are a Drill Sargent for the Marines, you probably don’t want to. So while I would like them to know X or Y, if they’re smart enough after 30-90 days it won’t matter and I’ll have to put up with them as employees for a lot longer than that.

So while hiring managers want Brains and Attitude, you can’t take Brains and Attitude to HR and expect them to use that to filter résumés for you. They’ll agree with you that B&A are the most important qualities, but they can’t use it to filter résumés. So as a hiring manager, you have to go through this fiction of creating requirements for the position. Generally, by the time you’ve created this shopping list of requirements, these requirements describe someone who can’t possibly exist. What I’ve heard recruiters call variously Bigfoot or a Purple Squirrel. Because what the hiring manger typically does is fill the job req with “would be nice” requirements, because their two main requirements, Brains and Attitude can’t be used.

Aside: While its true that occasionally, I will have a specific need for a particular technology, or broad class of technology, and that will have to go into the description for the position. But its always for a broad class of technology, rarely a specific one. It always makes me laugh when I see a position that requires “knowledge of particularly SVN”. Really? Are you going to not hire someone because they used CVS, Git or SourceSafe? Of course not. You want some experience in using source code control, but that’s a “would be nice” requirement. Or another requirement I’ve been seeing lately: must know LAMP. Does the recruiter know that means Linux-Apache-MySQL-(PHP,Perl,Python)? Or do they want the specific packaging of those things together? Are your software development engineers really going to be writing Apache config files?

So you now have a list of must-have requirements, and a list of would-be-nice requirements. Sometimes job posting separate them out, some times they don’t. Hopefully as a hiring manager you’ve prioritized them and had an informal conversation with the recruiter about what you’re really looking for because most recruiters have found that even some of the “must haves” are optional. HR then publishes the requirements and immediately receives a deluge of résumés. With a typical recruiter working 10 job reqs at a time, 2800 résumés each is 28,000 résumés to shift though. Career counselors will also tell you that you need to customize your résumé for the position you plan on applying for. The reason they tell you this is because while a hiring manager might spend 60 seconds looking at your résumé, a recruiter can realistically only spend 10 seconds.

A recruiter is going to take the list of requirements for the position, and spend 10 seconds trying to figure out how many of them you meet. They do not have the time to solve puzzles; they are not going to realize that your experience with Padrino means you must know Ruby and are probably a Ruby expert. They aren’t going to know that knowing Mongrel is probably better then knowing Apache if they’re doing Rails. They probably won’t know that RoR is Ruby On Rails. From your résumé, they have no way of telling if you are smart and have a good attitude. The only thing they can do is to try to find matches that get as many of the requirements as possible; and the hiring manager may not have even told them which ones are most important.

So before you submit your résumé to a company web site, you need to customize that résumé for the position. It just makes sense. For the recruiter the job opening is like a hole in a jigsaw puzzle of a certain shape. The more your résumé matches that hole, the more likely the recruiter will put your résumé in the Yes pile.

For me this is especially true, because I have enough experience that I exceed 90% of the requirements for any Director of Software Development position out there because that’s what I’ve been doing (duh!). For a VP of Software Development position I’m running about 60-75%.  For the remaining of requirements, chances are in the last 20+ years, I’ve done something similar or used a similar technology. So while I have no way of telling, I suspect its easy for recruiters to slot me into Senior Manager/Director slots; anything above that I expect I’ll have to network my way into. That doesn’t particularly bother me, that’s just how hiring works.

Ok, so we’ve can see that sculpting your résumé to make you a perfect fit is a good idea; you want to use the same terms as the job posting and so on. There’s a catch 22 though. Even though it makes sense for the job hunter and it also makes sense for the recruiter to have customized résumés I have yet to see an HR system that let’s you submit a customized résumé on a position by position basis. Plus, job postings on company websites can often be somewhat virtualized. Companies who need a certain type of position filled may leave a position on their website for months, purely to collect résumés. Recruiters can then search through that collection looking for a match without having to deal with duplicates.

So you are not able to submit multiple résumés, and even worse, submitting a custom résumé may actually be to your detriment because too specific a résumé might preclude you from a later search. With all the barriers to entry for the job hunter, it’s really not surprising that only 5% of positions are filled purely from someone submitting a résumé. That’s one of the reasons recruiters tell you to network, network, network, because the best recruiters actually care about candidates, and they fully realize the system is broken.

My Solution: Aim the résumé

Here’s what I’m doing to try to improve my odds. I call it “Aiming” my résumé. One of the the best ways to customize your résumé for any position is to take the list of job requirements, copy them to the top of your résumé, and rewrite them to state your actual qualifications. I’ve heard that stated by several recruiters. It makes their job easier, and saves them time. Since most of the HR résumé submission programs want an ASCII résumé, its even easy because you don’t have to worry about screwing up your résumé’s layout.

So at the top of my Networking résumé, I do exactly that. I take the requirements and annotate them with exactly how I am qualified for their position. I also clearly state where I am not a match. This should indicate to the recruiters the following:

• I have actually read the job description and I think I can qualify I am not merely résumé spamming. This should immediately put me in the top 10% of applicants because a common recruiter complaint is that people apply for jobs they can’t do. That’s not really surprising, the recruiting systems actually encourage this behavior.
• I will be honest about what I can or can’t do. That should put me in the top 1% of applicants, because again, people fudge. Again, you can’t blame them when you read job requirements that say “must know SVN” or “must know LAMP”. I would never claim to know MySQL because I think its a crappy database so I never use it. But I would probably say I know LAMP.
• It is probably worth reading my résumé a little more closely, even if I’m not a match for this particular position. I might be a good fit for the next one.

The nice thing about this approach for the job hunter is its relatively quick, 10 minutes instead of 2 hours spent tweaking a résumé to be a perfect fit for a position and then fixing your résumé formatting afterwards. (Aside to recruiters: As a candidate, I would be more willing to spend 2 hours tweaking a résumé if candidates were provided more feedback. Most résumé submissions are a complete black box. You don’t even know if someone has looked at your résumé. )

To deal with the issue of being able to submit only one résumé and the fact that the position advertised might not be the one the recruiter is actually filling, when I get multiple matches what I do is rank them. Since as a job hunter I don’t have any visibility into whether a recruiter has reviewed my résumé, I upload a aimed résumé for one week and set a timer for a week later. When my calendar reminds me I target a different position and I upload a differently aimed résumé.

So lets put that all together. Given a position I’ve targeted, I’ve pulled out the following 5 requirements to illustrate:

• Deep understanding of the end-to-end software development process in a complex business environment.
• Knowledge of service-oriented business and webscale ecommerce.
• Understanding of software system architectures.
• Strong working knowledge of software development tools.
• Extensive experience with and strong working knowledge of development platforms and technologies, including Java, LAMP, Ruby on Rails, PHP, Python.

Note the classic mixture of some vague statements in the requirements, along with some demonstrable skills. What exactly is a “complex business environment” exactly? So here are the same requirements, as aimed by me. Note that I’m making references to later on in my résumé, much like you might do in a cover letter. The nice thing about aiming your résumé is it can stand in place of a cover letter, especially for technical positions.

Note to HR personell: This resume has been aimed, see http://bit.ly/aimed-resume for details. + means I qualify for this requirement, – means I don’t, ? means I need clarification.

+ Deep understanding of the end-to-end software development process in a complex business environment.

At PACE, my last job, I was responsible for overseeing everything from design through to operations and deployment.

+ Knowledge of service-oriented business and webscale ecommerce

At PACE, we had a complex site that did e-commerce, allowed end-users to manage their data, a separate website for customers that they could use for end-user support, and services for customers that let them deliver software licenses from their own e-commerce systems.

+ Understanding of software system architectures.

+ Strong working knowledge of software development tools.

I have 20+ years of experience at all levels of software development. I think that the Design Patterns book by the Gang of Four was a watershed moment for software development.

+- Extensive experience with and strong working knowledge of development platforms and technologies, including Java, LAMP, Ruby on Rails, PHP, Python

Breaking these out: +Java, +Linux +Apache -MySQL +(Perl, Python) -(PHP), -+ Ruby on Rails (Used it a long time ago for a short project)

Ok, so we’ve discussed the problem, and I’ve explained my idea. Now we’ll see how it works! Follow me on Twitter if you’re interested in further posts in the series as I proceed through my job search.