How can we make your first month awesome?

My first month at every job is a period of self-loathing, usually characterized by frequent white-hot panics in which I believe that I’m not good enough for the job, not a real programmer, or just profoundly stupid. (This experience is what I thought everyone understood by the term “onboarding”)

So, when I looked at the schedule for PyCon this year, the talk “Technical on-boarding, training, and mentoring” stood out. I ducked in and sat in the last row, so I could easily slip away if necessary.

Instead of what could have been a soul-crushing grind about resource efficiency, I was delighted to hear the presenters Kate Heddleston and Nicole Zuckerman describe onboarding techniques that they had used to make new employees feel like humans welcomed into a group of other humans. Imagine if the next person we hired at Safari didn’t feel like we had set them on fire and asked them to find the water!

Activities for new engineers

As the talk progressed, I began to realize that we are all doing onboarding wrong. I wrote typo-ridden notes, struggling to keep up with all the great examples of onboarding activities that the presenters discussed, many of which I had never done nor asked a new person to do. Here are a few examples, paraphrased and sometimes given a Safari twist:

  • Buddy up the new engineer with the last person who got the development environment running

Not the most experienced person on the team, not the team lead or the person who built the dev environment from scratch two years ago, but the last person who set it up.

  • Ask the new engineer to start emailing things they didn’t understand or learned every week (2–3 things per week)

This one is great because even if a manager or a more experienced engineer sets aside time for one-on-ones, a new person might avoid or delay asking questions for several reasons. They might not want to bother someone who is obviously busy, or want to avoid asking what they think are foolish questions. Asking them to send questions invites them to open up and sets the expectation that they won’t understand some things. This could be a big win for some of the more reticent personalities joining a team.

  • Give the new engineer a map of people on the team, what they work on, and their areas of expertise

I wish that every time I had joined a team someone had given me this document. Imagine if, as a new engineer, you could easily find the person on the team who knew the most about Redis, or a particular internal web service or build process. Invaluable!

  • If they are more of a junior engineer, ask them to give a 5 to 10 minute presentation on a small topic biweekly or monthly (internal products, Python or JavaScript language features, testing methods). These should be things they can research independently that are useful to know.

This one is cool because it sounds super annoying, but it could really benefit junior programmers and interns. Just the other day, my boss was like, “How does SAML work again?” and I struggled through a hand-wavy explanation before giving up and admitting that I still didn’t have some of the details down. I guarantee you that if a junior engineer joins the team, I will ask them to give a presentation on SAML.

There was tons of other great advice, like having “code labs,” which are times that a new engineer could ask a more senior person any question, even something simple or embarrassing [A reddit AMA?—Ed.]. Also shadowing or short-term pairing, where the engineer sits (or remote screen-shares) with someone on the team to get exposure to the whole development workflow that the team uses.

Summing up, and more resources

One of the main ideas that I took away from the talk was that a new engineer’s first month could be very explicitly about the team welcoming them and guiding them through what is always a very complex, fast-moving world of new code and people. It sounded great, and I immediately wanted to go back and make the onboarding process at Safari even more awesome. I put together a proposed schedule of onboarding activities that we can try with new hires based on what the presenters suggested. I’m stoked for our next employee!

Kate Heddleston & Nicole Zuckerman gave a talk "Technical on-boarding, training, and mentoring" at PyCon 2014

The video from Kate Heddleston & Nicole Zuckerman’s great talk “Technical on-boarding, training, and mentoring” at PyCon 2014

Now that PyCon is over, the talks are all online, so you can watch a video recording of “Technical on-boarding, training, and mentoring”.

For a completely different perspective on onboarding, check out how WordPress does it by making everyone rotate through their customer service team (from The Year Without Pants).

Career transition: from a startup to a larger company

Over the course of my career I’ve spent most of my time working at smaller companies (less than 20 employees). I recently joined Safari, so the 150+ employees that work here is my first taste of a “larger company.” I realize to some that’s still a small company, but there’s no shortage of new experiences and things I’ve had to learn.

I’ve seen numerous posts on what it’s like to transition from a larger enterprise to a startup, but I haven’t read anything on the opposite experience. It’s been a wonderful experience so far, and the rest of this post summarizes my learnings.

Remembering names

To kick things off with a bit of humor, remembering names might be my biggest challenge so far. I’m terrible at this, so I find myself talking with coworkers and feeling bad that I have no clue who I just spoke with.

To my chagrin, everyone remembers my name. It helps to have Hipchat list names of coworkers, but remembering everyone is something that will take time.

Startup flexibility vs. BigCo entrenchment

If you work at a smaller company, they will tout the fact that they are more flexible than a large enterprise. This is generally true, yet doesn’t mean that larger companies can’t move quickly. I’ve been very surprised at how quickly Safari is moving.

In Clay Christensen’s book “The Innovator’s Dilemma,” one of the biggest challenges that companies face is when to invest in new technologies/markets. Typically disruptive innovation sneaks up on larger enterprises, and overtakes the old way of doing business very quickly (destroying the BigCo in the process).

This book serves as a cautionary tale, but my point is that many larger companies are fully aware of the need to constantly reinvent themselves. Safari is one of them.

As a result, large companies have smaller products/initiatives they are working on. This is essentially a startup inside a larger company, and there’s plenty of opportunities to move quickly, make an impact, and grow the business in a big way.

blah blah

Photo courtesy of Philippe Lewicki via CC BY-NC-SA 2.0

Balancing processes

I’m a big believer in the power of effective processes. There’s value in establishing a set way of doing things (larger companies) vs. unstructured tasks (typically work at a startup). Clearly this can be a double-edge sword. My role (marketing/growth) requires that I move at a fast pace, yet at the same time I must be cognizant of how to document issues in programs like JIRA and follow normal development sprints (still working on this). The key here is to balance normal processes, while still moving quickly.

Who should I talk to about ________ ?

At an early-stage startup, it’s normal to be the sole person responsible for a particular function. In a larger company, more teamwork is required. As a result, it can take time to understand the people who can help you accomplish particular tasks. If I had any advice on navigating through this process, it’s to ask questions. Get a copy of the company org chart or segment chat rooms related to particular projects.

The “make a difference” myth

Many people join startups because they want to make a difference. That’s a fantastic goal, but you can make a difference at a larger company, too. In fact, I daresay you could make a bigger impact at a larger company.

For example, Safari is participating in the ConnectED initiative, and providing $100 million dollars worth of technology resources to K-12 students.

How many startups have the resources to provide this? Not many.

I’m really excited about this, as I was in high school and would have loved to have access to the Safari library of books/videos. I’m thrilled to help the vocational center that I used to go to receive access to these resources, and they will be early “beta testers.”

Employment “risk”

Startups are not all fun and games. You might have your job one day and lose it the next. If you’re comfortable with ambiguity, a startup might be right for you. If not, I highly recommend working at a well-established organization. I tend to be risk averse, so there’s definitely a sense of comfort around knowing that the company you work for is profitable and growing.

Dynamics of a larger organization

If you work in a startup, and plan to sell your product/service to the enterprise, it’s probably a good idea to understand the dynamics of how a larger organization works. Who holds the credit card and needs convincing? Who’s in charge of a specific function, and what’s their decision-making process look like?

It’s for that reason that I recommend working at larger organization. There’s no better way to learn than by full immersion.

Wrapping things up

If you learned anything from this post, I hope it’s that you shouldn’t trust stereotypes of what it’s like to work at a startup or large organization.  Be open-minded and do your research.

I hope you enjoyed this post, and if you have any comments or thoughts, let me know on Twitter, or just comment below.

Zen and the Art of Writing Software

I’ve always been a libertarian when it comes to the writing of code. When the team recently became enamored with coding style guides (e.g. A style guide for Python tests) and asked my opinion regarding the adoption of a particular guide for Javascript, I reluctantly offered the following: “I think there are some good things in there. But I also think there are plenty of things that will have no useful impact other than to create more commits and pedantic comments in code reviews. I think we should start out with a minimal set of guidelines on things that we know have already caused issues and organically add items as they are needed…”

Continue reading

A letter to my past QA-self

Dear QA-self from the past,

This is your QA-self from the future writing to give you a quick pep-talk. Right now you do not have access to the Website’s Database so information that could take you a matter of moments to obtain end up taking way longer because you don’t have permissions to a run a simple query. You also have no control over your Test Environment or what gets deployed to Production. You’re frustrated because changes you aren’t aware of keep sneaking in. The good news is that things will be opening up in the coming years when you start working on Safari Flow. You’ll have access to your Website’s Database and can deploy builds yourself to the Test and Production Environments as needed.

Continue reading

Agile Authoring

To some, November brings to mind the beginning of holiday cooking season, with massive feasts, multiple dishes, a neverending list of ingredients to buy at the grocery store, and possibly a house full of visitors who want to be useful but usually just get in the way.  To others, November is the month of NanoWriMo, a ritual amongst amateur writers to shut yourself away for a month and crank out that novel that you’ve always wanted to write (usually poorly, and usually alone).  At Safari Books Online, we went into November engaging in our own mammoth writing exercise, with its own massive list of things to do and its own eager crew of contributors wanting to be helpful.  This was our Book Sprint.

The challenge: describe an application that had evolved over time through the contributions of a dozen developers, where documentation had perennially lagged.  It wasn’t a simple matter of asking one or two people to set aside two weeks to properly document their code, but to get a bunch of individuals who were each experts at different aspects of the application to sit together and pool their knowledge.  

What we hoped would emerge: a comprehensive software manual that didn’t read like it was written by a crazy person.  It was a very interesting challenge, so we approached Adam Hyde from BookSprints to help us focus our efforts.

A Book Sprint, as the name might imply, takes its name from a code sprint and is, in many ways, a method of taking agile software methodologies and applying them to the collaborative task of writing a book.  We sat down with Adam and had him lead us through a discussion session where we started raising topics that needed to be discussed in the book.  Each of the topics were all written down in a sticky-note, then posted on a whiteboard.  Once posted, we grouped the notes into common themes, and as the groupings evolved, the a basic chapter-and-topic structure emerged.  This was organized into a rough table of contents, and each of us picked out a few notes that we felt comfortable writing about, and we set to work putting down our thoughts into a collaborative online document which was the beginning of our book.

Replace the notes with tickets, the table of contents with a backlog list, and the periodic status checkups with a standup, and you can see how this authoring process mirrors the  workflow of an agile software development team.  Indeed, at its core, agile development is a process and mindset for organizing a group of talented and motivated individuals who are all contributing to a project that may evolve over time, and there’s nothing that says that this approach only applies to code.  

Writing books can benefit from collaboration and must evolve as ideas and information emerge through the writing process.  By switching out the conventional model of a rigid outline in favor of modular topic cards, multiple contributors can start writing independently—working on individual pieces of the book in parallel—then backfilling continuity and flow afterwards as part of integrating chapters together.   If a new topic needs to be covered, treat it like another requirement, write up a post-it and stick it into the appropriate chapter.

Similarly, one could envision an agile kitchen where, rather than having a hierarchical set of chefs and sous chefs, a set of discrete tasks are put up on a whiteboard like: “mince garlic”, “boil potatoes”, or “brine turkey.” Individual contributors note the tasks that need to be done, pick them up as they are ready and then add new tasks as the evening evolves (“open another bottle of wine”)… 

…this may or may not describe a standard dinner party between Safari employees.

Screen Shot 2013-11-07 at 3.24.04 PM

Screen Shot 2013-11-07 at 3.22.54 PM

We’re big fans of agile development at Safari, not because it’s a cool, hip thing to do in the world of software, but because we genuinely enjoy the human interactions that can emerge from deep, thoughtful, and genuine collaboration. There’s nothing that says that it has to be limited to “writing the codes.”

Continuous Integration for Chef with Vagrant, Jenkins, and Gitlab


What did we have?

We use Chef for infrastructure management at Safari Books Online. We have a Production Chef (ChefProd) server that performs standard tasks such as putting users on machines and setting up monitoring. Chef cookbooks also perform specific tasks such as setting up web, database, and application servers. In addition to the Production Chef environment, we also have Chef Development (ChefDev) environment used for testing Chef cookbooks.

We run a Gitlab server for version control. Gitlab is the open source project for self hosted git management. It is a git server and web UI written in Ruby on Rails and it works great.


What did we want?

  • Goal #1: No knifing in anything to production manually.
    • This was for fat finger errors as well as a lack of version control backup.
  • Goal #2: Everything in Chef was in version control.
  • Goal #3: To have our entire Chef ecosystem within a testing framework.


How we did it.

We built a Jenkins VM (provisioning users and monitoring through Chef) for our CI (Continuous Integration) testing server. Jenkins is a great tool for testing out software.

Each Chef cookbook is stored in version control with Gitlab. For each git cookbook repository, we made an identical Jenkins job. This Jenkins job would run all the tests on the cookbook on one of its nodes, searching for bugs. We added a git hook on merge to master for each cookbook. This means every time one of us git committed and merged to master, Jenkins (who was always listening for the Gitlab hook) would fire off the cookbook test.

All this happened in the Chef Development (ChefDev) environment and we wanted to accomplish Goal #1, which was put tested code into production without using knife. We needed a way to push changes to production, the simpler, the better. We arrived at having a trigger file, i.e. a file that would send the signal that we wanted to push to production. If and only if this trigger file was git committed and merged to master, Jenkins would deploy to production. We decided to use a CHANGELOG file (with the added bonus of frictionless deploy comments) but any file would suffice.

With this system, we could test out cookbooks on the ChefDev environment, and have Jenkins knife them into production at will. All code was in version control and tested. This fulfilled Goal #1, Goal #2, and Goal #3.


Vagrant makes development better. We use the above workflow and leverage Vagrant VMs for local testing before this entire process. With new cookbook development, it’s nice to be able to move quickly into writing tests and software. This is where Vagrant shines! We made special Vagrant VMs that mimic our production environment. DevOps can test new cookbooks locally before creating Jenkins jobs and Gitlab hooks. Existing cookbooks can be tested locally before the Jenkins tests, so you can develop and iterate quickly when starting out on a new feature.

How to fake a product management job interview

I had no idea what product management actually was, or if I was qualified to do it when I started a job hunt this time last year — a path that ultimately lead to me joining Safari as VP of Product in August 2012.

Modern tech product development is surprisingly poorly documented in books, so before I got on the plane, I turned to turned to Google and started pillaging information as quickly as I could about what product management means at the big Silicon Valley firms. Looking back now, it’s easy to see how my checkered career — producing 50+ websites for cash-strapped publishers in a hurry, and latterly as a failed entrepreneur in a cash-strapped analytics startup — had inadvertently given me many of the characteristics of a product manager. So for anyone wondering what Product Management means here at Safari I thought I’d share my crib-sheet here.

After making my way through the horror stories about Product interviews (comparable to the mythical “Oxbridge” university interviews in the UK) I started to find some great information on sites like Quora, Glassdoor, and a few blogs. Many of the interview horror stories are from Google, where analytical / mathematical thinking are combined with the hacker ethic. How many ping pong balls fit in a 747? How many piano tuners are there in Chicago? Luckily Google never replied to my application letter, but a post from a former Microsoft “Programme Manager” provided some helpful documentation about how to structure your thinking for an interview like that. I found it incredibly helpful in the circumstances.


Product management is about boiling things right down to the very essence of the problem you need to solve for your customer, and then sticking your neck out to prioritise and make the tough calls (hopefully supported by data) on how you get there quickest. It’s also about building and leading a team and putting them in the best situation to do better than you could ever do. Focus, discipline, and trade-offs. [Insert joke about how product managers can stop reading here]

The first documents I turned to were fairly epic posts written by a former Amazon engineer about what it’s like to pitch to Jeff Bezos. I recommend you read it and its follow up in full. The short version? Be succinct, be prepared to articulate yourself fully in writing (rather than powerpoint), and internalize the icky-to-a-Brit but informative “leadership values” of the company. I would argue that they make better products in a more disciplined way than anyone else.

Working backwards

Amazon is undoubtedly a company that is on fire, executes ruthlessly on a clear strategy, and delivers wildly successful products. They have developed a remarkably simple and powerful approach to product development that I’ve stolen much of for Safari. They “work backwards” in tiny teams. This means starting the whole process off with the press release you’ll use to launch the product when it’s done. The (flawless) thinking is that if you can’t summarise your product/feature in a headline that makes people know exactly what you’ve done and why they want it, your product will lack focus and probably suck as well. Read more about working backwards from Amazon’s CTO, and on Quora.


Product management is all about discipline and decision-making, not groupthink or consensus. That means sticking your neck out. Another no-brainer idea I stole from my research was the idea of the “Directly Responsible Individual“, which I got from Apple.

At Apple any product, and product sub-task, has a DRI attached to it. The process works incredibly well. Every project has a cover sheet with a list of names on it next to a task. So everyone knows exactly who to turn to for doing X or Y. No task has two DRIs so there’s no ducking the blame. It’s surprisingly hard to do, but a great project manager (which is not the same as the product manager) will make sure those roles and responsibilities are assigned and understood.

Product vs. project

It’s worth talking about project vs product management. Some people confuse the two, and while great project managers can make great product managers they should never, ever be the same person on a project. The two have totally opposing, although complementary, priorities.

The product manager is focused on delivering something that will delight the user and deliver on the business requirements. The project manager is focused on getting a list of tasks done in time. I have spent a lot of time as a project manager, and while I have huge respect for PMs, I absolutely hate doing it. What product managers should learn from project management is the ability to prioritise ruthlessly, make never-ending tradeoffs, and swap out tasks on the fly — especially in an agile development environment.

Last words

Finally here’s a few of quotes I found that do a great job of boiling product development down:

“Any idiot can think of new product features. Only a great product manager can take them away.”

“If we haven’t got data, then we’ll use opinions instead. Starting with mine.”

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.”

“Take the single most important feature, do just that, and polish the hell out of the experience”

And some of the sources I leaned on heavily for my research:

It turns out that these tips on how to fake it have been incredibly useful to me in the last six months, so any further advice is most welcome.

Got Issues?

Safari’s Content Team has the dubious distinction of having the highest volume of tickets in our company-wide issue management tracking system (we use Atlassian’s JIRA). We easily win this competition, with more than 1,500 open issues on any given day. But do we buckle under the psychic weight of all these tickets? Nah… go ahead, bring ‘em!

Content Issue Pie

Content Issue Pie

Why So Many, You May Ask?

The Content Team has quality-checked 12,729 brand new titles loaded onto Safari Books Online from April 2011 to last week. For the past 6 months, we averaged 753 titles/month, or 177 titles/week. We track only issues that are clearly errors (e.g., a title-cover image mismatch) or issues that seriously impact readability (e.g., all images are random color bitmaps like this one from a real book).

Mangled image

Mangled image

Each time we find an issue like this, we stop the title in the pipeline before it goes live, and follow up one way or another to correct it. We track all of these issues in JIRA, so we can manage the corrections and move each title live as quickly as possible.

At this time, we only check brand new titles, but our publishers are free to update titles at any time without oversight. And, since we only started quality-checking new titles in April 2011, but Safari launched way back in September 2001, there are quite a few titles that we haven’t scrutinized. Various problems get reported: the unavailability of practice files referred to in the text, teeny tiny images too small to make out, or broken links. An average of 200 new content issue tickets are created each month.

Issues Created Monthly

That explains where our issues are coming from. So, how do we manage them?

Standardization, Automation, and Elbow Grease

Well, managing these issues has been an evolving process. We are fortunate to have on staff not just one, but several JIRA experts, who are always willing to help us out with custom fields and productivity brainstorming.

We’ve been working our way up to several key improvements, which are now at a point where we are starting to realize the benefits. With >1,500 issues, global improvements don’t happen overnight. It’s easy to add new fields to help us organize and track issues, but then those fields need to be populated – a daunting task. And of course, in order for this system to work, everyone has to use it the same way — which means a bit of documentation, training, and oversight are needed. Here are the keys to managing this type of issue volume:

  1. Standardization: custom fields, boilerplate language
  2. Automation: QaQ, automated email
  3. Elbow Grease: Monthly issues export & follow up
  4. NEW: Greenhopper

Standardization. Custom JIRA fields help us slice and dice the issues into manageable groups. For example, we added a publisher field, which allows us to export all the open issues for a given publisher. We use a component field, which allows us to sort that publisher’s open issues by whether the issue relates to the source PDF, the source EPUB, the metadata, companion files, etc.

Component Pie

And we have boilerplated the language we use in certain fields, which serves two purposes. First, it saves the ticket writer time – she doesn’t have to consider how to explain a given issue, she can rather just copy/paste the explanatory text from our (constantly updated) JIRA Issue Map. Second, we make sure our boilerplate language is clear enough for publisher-facing communications, even if our primary publisher contact is a rights person who has no need to speak the lingo of CSS or toc.ncx, for example.

Automation. Our stellar engineering team has built us an QA Queue application (we call it the QaQ) to manage our daily load of new titles to quality-check, and this system hooks right into JIRA. After we check a publisher’s new batch of titles, we follow up via email to let the publisher know which titles are live, and which need a little more work before they can go live. The QaQ automates the creation of lovely formatted emails; for titles with associated JIRA tickets, it exports the text from key fields which detail the required fix in easy-to-understand language.

Elbow Grease. We are now rolling out a monthly export of issues for each publisher. When a publisher receives a spreadsheet listing their issues in detail, sorted by issue type, it’s a lot easier for them to follow up en masse, so they can get as many new titles live (or corrected, if they are already live) as quickly as possible. We did a pilot of this new process with a select set of publishers, with very promising results. We don’t want our publishing partners swimming in the JIRA sea, nor should we require them to rely on email alone for making sure all their titles are working well on Safari.

New: Greenhopper. This plug-in to JIRA has us really excited. We are doing a trial run with a Kanban workflow for the subset of Content issues requiring engineering work. In 2010, we were managing the long list of engineering Content issues via JIRA and email alone. Well, that doesn’t work so well once you have more than a handful of issues. So in 2012, we switched to a shared Google doc so we could be sure we were all working off the same songsheet. But even that has its shortcomings – we meant to keep notes in the Google doc and ALSO update each JIRA ticket as we worked. In theory. Often, only one or the other would get updated, and sometimes the priorities in the doc didn’t match the priorities in JIRA.

But with Greenhopper, we plan to kiss the Google spreadsheet goodbye, for the most part. We created a Kanban board with a few key buckets: Pending, In Progress, In SBO QA, and Completed. We are strictly limiting the number of In Progress tickets to 10. (If you go over 10 tickets In Progress, the whole board turns a distressing bloody red.) This way it’s very clear for engineering to know exactly what must be worked on. And the Kanban board is very easy to work with – in our status calls, we can discuss the entire board, and update each individual issue as we discuss it from the same board. No more getting lost in a sea of dozens of browser tabs or windows.

If this Greenhopper experiment works well for our Engineering tickets, we will explore creating boards for other types of Content Issues. The sky seems to be the limit in terms of how you structure your boards; they seem fully customizable based on the fields you want to use.

OK, now that we have these great tools in place and are starting to use them, we can start setting some nice aggressive goals to get our overall numbers down. (The team is going to kill me when they hear this.)  Let’s beat our current created-to-resolved ratio by summer, guys!

30 Day Summary to Beat

Conference-driven development

TL;DR — Release products at conferences. The products will be better and you’ll be happier.

Test-driven development is a technique that helps programmers build large applications from small, working components. It has been successful enough to unlock developers’ innate love of acronyms, ranging from ATDD and BDD to MDD and UGG. TDD is important in the industry because it forces a mental shift inside the programmer’s mind. Like most humans, programmers are all too willing to succumb to really lame brain bugs. Instead of falling for the trap of designing and implementing a grand cathedral in one single volcano of brilliance, TDD focuses on a continuous stream of achievable, minor, functional bricks. Conference-driven development offers similar rewards for virtuous choices, but works for the whole product development team rather than just programmers.

Continue reading

Invest in your engineers; build Connect4 in four hours

Last year, my group decided to invest a certain amount (5%) of time to unstructured self-directed activities – we call it “investment time.” We do this on every other Friday afternoon.

This isn’t a new idea. The concept has been widely touted, and according to this post, it has been in vogue, or at least in use, as far back as 1948 (at 3M). There are also many well-documented flaws with this idea; see these comments. The comments on coding horror’s post are full of examples of how this can fail.

But there are good reasons to try: In a client-driven consulting organization, engineering work is tightly constrained: by feature requirements and/or by budget. Often it’s an engineer’s role to be the grownup on a project, reminding everyone about technical constraints that will lead to scope growth and cost overruns. It can be tiresome to always be the person that says “no,” and every now and then we need a chance to think expansively, try new things, and exercise our creative juices.

So the idea isn’t new, and 5% of our time isn’t really enough time to launch major new initiatives: gmail isn’t going to get invented every working other Friday afternoon. But I want to talk about this practice because I think it has had a lot of value for us, we’re a small organization without the resources of a Google or a Microsoft, and this gives us a different  perspective. In these sessions, we have a chance to try out new things, to work with different people, and to think creatively, but it hasn’t necessarily been easy to realize these benefits. I’d like to reflect on how this has worked and not worked for us, and then I’ll describe what we did in our most recent session.

Since we started this six months ago, we’ve had mixed experiences. Sometimes interesting things that provide tangible benefits have happened. We built an XSLT code coverage tool and integrated into our unit tests. We worked through some incompatibilities in our core platform so we could deploy <a href=””>NewRelic</a&gt; to monitor it (which by the way has been a huge help). Other times people drift off and work on their regular work. A few times people have left early. My feeling is it’s OK that that happened because this is an experiment, but we do want to get the most out of the time we’re spending and so we try to learn from the failures as well as benefit the successes. Here’s a quick run-down on what seems to work and what doesn’t:

1. Celebrate success. OK this is just like mom and apple pie, but it’s easy to forget to do. We follow up each session with a report out to the whole company about what happened. It’s a good opportunity to let people know what the engineers are wasting their time on so they can see just how
useful it is.

2. Do it on a regular basis, at a predetermined time. This is really critical: it ensures that it will actually happen. The whole idea is to be open to new ideas, so you don’t know *what* you are going to do exactly, which lends a bit of an air of unreality to the whole enterprise. To combat that, you have to be very concrete and specific about when you are going to do it, who’s going to be involved, and where it will happen. Beer and food help too.

An important corollary is: no Friday releases. If you can make this part of your company culture, you will benefit regardless of whether you also have investment time. Friday releases are bad because nobody tests them until Monday except your customers – nuff said. But it’s especially important to keep releases away if you are trying to reserve some unscheduled time.

3. Have everybody in the same place together. This has been really important: the best weeks have seen a low hum of activity in the office, and significant exchanges have occurred from people spontaneously walking around the office and looking over other folks’ shoulders. However, one thing we need to get better at is involving our remote developers. There’s a tension around encouraging collaboration: some people work better alone; others in groups. We’re still learning the right balance.

4. Don’t force people to be creative if they don’t want to, or feel like they’re too busy. People shouldn’t be made to feel guilty if they’re not inventing a cure for cancer in their spare time.

Also, sometimes there is a monkey on someone’s back that they need to shake. Ideally this shouldn’t happen, but if it does, delaying work you really absolutely need to do just so you can take time out to come up with other freakin’ stuff to do obviously makes no sense.

5. Find a way to encourage everyone to generate good ideas in advance of the investment time. We’ve run an exercise with colored markers and sticky notes that was fun and generated all kinds of great ideas. Sometimes just going around the room and having everyone say what they’re planning to do
is enough.

6. Add competition to the mix. From time to time we like to issue a programming challenge to the engineers at our company. This gets folks thinking about work in new and creative ways, and well – it’s fun. We
strove to build the fastest sudoku solver; we competed in robocode matches. Hilarity ensued: programming chops were rewarded.

The Connect4 Challenge

Recently one of our engineers, Mark LeMay, came up with the idea of a framework showdown. The idea was to learn more about different programming languages and web application frameworks by devising a simple problem, applying various tools to it, and comparing notes.

The problem we chose to work on was Connect Four. This is a simple two-player game, familiar to many. You drop disks into a 6×7 array of cells, where they fall to the bottom of their column with the object of getting four in a row of your color before your opponent does the same. It seemed ideal from the perspective of being easy to program, but would require some server side programming in order to manage the game state, since it must be shared by multiple players.

We came up with a scoring rubric for evaluating entrants that awarded points for everything from “return HTTP OK” to stress testing and unbeatable AI. Pretty ambitious for 4 hours on a Friday afternoon. Yes, well it turns out that 4 hours is not enough to learn a new language, and a new framework, and to code a perfect Connect4 AI that can run while being stress tested by North Korean hacker bots (actually we didn’t try that last one, but I’m pretty sure all the entrants would have failed it).

However, it is almost enough try out some new tools and get a feel for what it might be like to do some real work with them. Here are the ones we tried: Ruby on Rails, Grails, Google Web Toolkit, Node.js, Lux (XQuery), Go and Google Apps, Clojure, Wicket, and Django. Some newish stuff, a lot of stuff that is not super new, but this was an opportunity for folks who don’t get out that much to try out a newer, younger model, um as it were.

A few things people wanted to or suggested trying were but never got to were: Scala, ChicagoBoss/Erlang, and HapiJS. Maybe we’ll check them out later.

I’m not even going to attempt to give you a run-down on all these tools in this post, but in some later posts we’ll cover some of them (we’ve already heard from Robert Hall re: sockets in node.js).