We’re Bad at Interviewing Developers (and How to Fix It) – Interview with Kerri Miller

In this interview with Kerri Miller, Lead Software Engineer at LivingSocial, we discuss how to hire and interview developers. We typically don’t get trained on interviewing and we’ve all experienced the haphazard approaches of those new to it – poor organization, repeated questions, fizz-buzz… Kerri tells us how to run interview days, the types of questions to ask, how else we can evaluate candidates and what to do after the interview. For more tips, Kerri writes about software development and hiring on her blog.

Introduction

Derrick:
Kerri Miller is a lead software engineer at LivingSocial. She is also a RailsBridge instructor and frequent conference speaker. She talks about software development and hiring, including the talk, ‘We’re Bad at Interviewing and How to Fix It’. Kerri, thank you so much for taking the time to join us today. Do you have a bit more to share about yourself?

Kerri:
I am actually, in fact, a lead software engineer at LivingSocial. Part of that is working with junior developers, or more junior developers, leading software teams and projects, and I also do a fair bit of work in our engineering culture team, so doing things like how do we propagate a good culture for code reviews, post-mortems, and hiring.

“You want them leaving the interview process regretful that they didn’t get hired, not resentful that they didn’t get hired”

What’s Broken with Developer Hiring?
Derrick:
What do you think is broken with the current way a lot of companies hire and interview?

Kerri:
We don’t do a really good job of hiring with intent. We decide that we need more people, but we don’t do a really good job of figuring out what we need those people to actually do, and who we actually need to hire. I like to think of my software teams as little ecosystems, little, tiny arcologies that exist in a bottle. They’re not entirely a closed environment, and, like any ecosystem, anytime you introduce anything new to that realm, there will be changes. There will be impacts.

Any time you hire somebody, you’re changing that ecosystem. You’re introducing a new species or a new variable to things and it’s going to change. Thinking about what you want to change means that you have to have laid that groundwork to understand where you are at the moment. A lot of teams and companies don’t do a really great job of understanding that. They’re just simply, “We need more bodies. Let’s hire bodies.” They don’t go into these things with a conscious sense of where they are and what they need, and how the future’s going to change by adding more people.

How to Structure and Run Interview Day
Derrick:
Let’s talk about the interview day. How should we structure it, and what are some key aspects you need to get right?

Kerri:
You need to go into it having a plan, and that plan starts with knowing what questions you’re going to ask and why. Understanding that every question you ask that a candidate can’t answer, or every step of that process is an opportunity for a candidate to filter themselves out of that process, it’s a point for you to get information to make that final decision. I think it’s really important that you take a look at what that plan is going to be. If you have, say, three people, and you’re hiring for a front-end developer, you should have one person ask about JavaScript. You should have one person ask about, perhaps, browser interaction, or working with designers, or what have you. Just splitting up that interview so that you’re not asking the same questions over and over again, you’re really able to get really solid signal on a person’s skill sets, what they’re comfortable with, and what their concerns are. What kinds of decisions are they making?

Good Types of Questions
Derrick:
What are good kinds of questions that we should be asking?

Kerri:
Well, I’m not a big fan of whiteboarding, because I think that’s something that we just automatically do, and we don’t think about, “Well, what questions are we trying to answer by asking a candidate to solve a problem?” Are we dinging people for trivia questions, for not remembering, “Oh, I need this third option flag or an obscure method from a core library.” Instead, I really want to focus on questions that are asking about decisions that they’ve made, what choices have they made, and what choices would they make again in the future? Are they reflective about mistakes that they’ve made? Are candidates looking for opportunities to improve, and how do they actually go about it? Do they make plans for themselves, like how they would improve a certain skill set, whether that be a technical skill set or a more soft skill set, for example, management, or project shepherding for example. Those are the kinds of questions that I think really get you at the heart of not necessarily what somebody knows, but what they’re capable of.

Beyond the Interview – How Else to Evaluate Developers
Derrick:
You’re a proponent of evaluating candidates in other ways than just an interview. How else should we be finding out more about potential employees?

Kerri:
I’m a really big fan of pairing on projects, like actually working with somebody. It doesn’t have to be a formal or traditional pair programming situation with one computer and two people, talking through the technical choices that they would be making as they programmed on something. At LivingSocial, we do a code challenge like a lot of companies do, using that as, then, a launching pad to have a discussion with a candidate to say, “You solved the problem using this technique. Why didn’t you choose this other technique? Why did you choose this one? How would you do it better? What if we sat down and refactored?” That’s one really good way to really get the heart of why are they making the decisions they’ve made? Not just did they make this choice because they didn’t know, or are ignorant, or did they make this choice because they had a certain belief about what the requirements of a given project were? That’s one way to do it.

Other ways you can be finding out more about potential employees … I’m a really big fan of asking the employee to explain something to me or teach something to me. In the past, we’ve done this with simply just saying, “You can teach me anything, something that I don’t know, and preferably is non-technical.” How well do they communicate about something that they’re a local expert in but they’re intended audience is not? Could they then go off and go and learn a new framework, or go have a meeting with, perhaps, a stakeholder, or a client, and come back and explain what the actual requirements are to me, to distil down what I need to know and communicate that well? Communication is such a big part of what we do in this job, and so testing for that essential skill in a really clear and explicit way can be really useful and get you a really good signal about who that candidate is and how they’re going to fit into your organization.

“We don’t do a really good job of hiring with intent”

After the Interview – Making the Hiring Decision
Derrick:
After the interview, what are key things that employers should be doing?

Kerri:
I think it’s really important that we don’t just say, “We’re going to get back to you,” but to say, “We will get back to you by Thursday, end of the day.” Then, if you can’t make your decision within those three or four days, communicating that to the candidate so they have expectations that you can meet, because it’s not just good for the candidate, it’s good for you as a company to have that discipline, because you want people to, whether you hire someone or not, you want them leaving the interview process regretful that they didn’t get hired, not resentful that they didn’t get hired. Being professional and upfront and just friendly and encouraging about the entire process is great.

I try always to make sure that, if we can’t hire somebody for whatever reason, we make sure that we give them constructive advice or feedback afterwards, or at least make that available. If you did like somebody, if it came down to either Joe or Mary, and you hire one or the other, keep that person on file, and follow up with them in a few months to see how are they doing, what’s going on? “Hey, we have an open position, would you like to re-apply, or would you like us to consider you for that?” That gets into the part of how you keep metrics on things as well because if you didn’t hire somebody, figure out why you didn’t hire them and then follow up and see, are they actually doing that work, and did we hire the … Not necessarily the wrong person, but did our process let us down? If you assume that somebody didn’t know anything about, say, SQL, and now they’ve gone on to work on a SQL-heavy project, for example, what in our process missed that step?

“It’s really hard to look at who you hire and decide that you have a good or bad process. But you can look at who you don’t hire.”

Derrick:
Great, so we talked about having a plan as part of the hiring process, what’s a good process to follow to make a hiring decision?

Kerri:
When you split up the interview topics, the questions you’re going to ask, and you’re going to consistently ask all of your candidates, it feels a little bit like reading a script, but it really lets you compare apples to apples as much as possible. Once you’re done with your little section of the interview, you should immediately go back to your desk and not get back to work but write down what your impressions were. What were the pros and cons, the bullet points, and find something good about the candidate and something not-so-good about the candidate, something that you wish they did have? Doing that at that moment and passing that back to a central person so as not to … Don’t pass it back to a group, pass it back to a central person, whether that be an HR or the hiring manager, to collect that, so you’re not coloring the impressions of other people.

When you get back into that room with everybody else, whether it’s virtual or real, to really discuss your opinions, you’ve got your opinions of the moment and you can’t be swayed by the impressions of somebody else. For example, if you were supposed to interview them about JavaScript, and the senior JavaScript person, who’s got twenty years of experience in JavaScript, just really did not like that person, how would that color your opinion if you had to give your opinion in that moment? If you wrote it down previously, no, this person really is good at JavaScript, then you’ve captured that honestly and you can really give honest feedback about what that person’s qualities are and what their strengths are without being colored by other people in that discussion.

Measuring and Improving Your Hiring
Derrick:
You hinted at this earlier, but a key part of your approach to hiring is measuring the process to improve it. How could we go about measuring the effectiveness of our hiring?

Kerri:
It’s very seldom that we ever hire anybody bad. When you hear horror stories about hiring, it’s always somebody else’s team that hired that one jerk, or that one idiot, so it’s really hard to quantify because now we know that person, and we’ve worked with them, and we understand their strengths and their weaknesses. It’s really hard to look at who you hire and decide that you have a good or bad process. You can look at who you don’t hire. You can look at that in terms of what were the false negatives? Did we bounce this person out of the process for a specific reason and then it turns out that that reason wasn’t good based on where they ended up going to work?

It’s really easy to LinkedIn stalk people, and peak into their GitHub profiles if they’re doing that sort of work, to see what they’re doing a few months later. It can be really useful to, four, or five, six months down the road, go back and look at the candidates that you passed over and see what they’re doing to understand, if you keep records of the questions that you ask, and the reasons why you maybe didn’t hire somebody, to see if those reasons are still valid.

Other metrics that I think are really, really important to an organization are understanding what your pipeline for candidates consists of. At each step, you have a certain amount of leakage, because people just simply don’t make it through the process or they abandon the process, they disappear. How many people are you losing at each step, and is there one step that you’re losing a lot of people at? Maybe you need to refine that step, remove it, or move it earlier or later in the process based on what your organizational needs are. I think it’s also important to look at who you’re losing as well. Are you losing junior developers at a step that you really don’t want to be losing them at? Are you losing more diverse candidates? Are more women abandoning your process at a certain step than men are, and understanding, or questioning at least, your process to see, is that a problem? Can we fix it? How do we fix it?

“You should immediately go back to your desk, and not get back to work, but write down what your impressions were”

Common Developer Hiring Mistakes
Derrick:
What are some common mistakes you see companies making when hiring developers?

Kerri:
Some of the more common mistakes are hiring from our friend networks. I think that the friend network is such an important part of how we get jobs, but it also tends to reinforce our monocultures a little bit. We tend to be friends with people who are mostly like us, and so those are the people that we’re going to be recommending, and so those are the ones that get hired more often. When I was mentioning earlier how the team is an ecosystem, it’s important to have some diversity there, and not just the diversity we talk about in terms of gender or ethnicity or race, but age, class, looking at people’s technical backgrounds, do they come out of CS programs versus being a self-taught or a boot camp?

Industry backgrounds, did they work in, perhaps, consumer electronics testing before they became an SDET at Microsoft? Were they at startups versus large enterprise companies, or somewhere in between? All those pieces of diversity are going to be influential and improve the health of the ecosystem of your team, and so those friend networks are important for getting candidates in the door, but understanding that that sometimes is going to lead to a certain amount of self-selection for candidates.

You have to, like in soccer, they say, “Run to where the ball will be, rather than where the ball is.” If you have those early conversations about who you need to hire, and what you want to look for, what sort of energy and person do you want to add to your team, to influence it into a good direction? And then go to those people, find them, whether it be through meetups or user groups, or extending your extended network, not just your immediate friend network.

Derrick:
Are there any other resources you can recommend for those looking to improve how they hire developers?

Kerri:
Looking at the different boot camps you’re doing, and how they’re talking to their students, as well as to their sponsoring companies, or the companies that are hiring. I’m a really big proponent of hiring more junior developers, because no one is ever going to know our exact technology stack and our exact way of working, we always have to teach people, so looking at what those boot camps are doing, and how they’re talking about the industry, because they’re trying to set people up for success over the next five years. There’s a lot of wisdom. They’re spending a lot of time to gather wisdom that they can relate to us about who we should be hiring over the next five years, and what skills we should think are important.

Finally, I tell everybody this, go take a relationship skills class. Although they’re sold as being aimed at couples, a lot of that is really about listening to other people and understanding what their concerns are. Once you can start to build those sorts of skills for understanding the perspectives of other people, just generally improves everything about your hiring process, and your team, and how you work with each other.

Derrick:
Kerri, thank you so much for joining us today.

Kerri:
I’m really excited about this topic. I’m glad to see more and more people talking about it. There’s no one size fits all solution. We all face some really unique problems, but there are some commonalities.

A Guide to Open-Sourcing Your Project at Work

Congratulations! You’ve written something at work that is amazing and you want to share it with the world! This guide covers three key areas that you should consider before making the leap: Why, when and how to do it.

Why Should I Open-Source My Work Project?

Open-sourcing your project at work can be a great idea. It can:

Help you build a developer-friendly brand

  • From those with a developer-focused product, like Stripe and Twilio, to those with APIs, like Facebook, Google and Square. Open-sourcing your code can be a good way to build your company’s relationship with developers.

Allow you to give back to the community

  • Just think of all the libraries and software you use on a daily basis that make use of open-source code. Adding your own is a good way of paying it forward so that others can benefit from your contribution. We’ve open sourced a number of libraries and even whole products.

Help you to recruit

  • Take Yahoo and LinkedIn for example. They’ve found that through their commitment to Open-Source projects (like Hadoop and Kafka), that they’ve been able to encourage developers to join them who otherwise might not have.

Gain more contributors than your project ever would have in-house

  • Like for example Square’s Dagger, a dependency injector for Android and Java. Having released it, many developers are contributing to it, including those at Google. In fact, Google developers have been contributing more than Square’s developers do themselves.

When Should I Open-Source My Work Project?

There are two conditions that you would want to meet before open-sourcing your project. You want to make sure that:

It won’t hurt your business

  • It may be an impressive, complicated bit of code that would be useful for other products beyond your own. Yet if that development is your secret sauce, then giving it away would be bad for the business. Likewise, if your library is an integral part of what makes your product unique or even what makes it possible, then you might want to keep it in-house.

Your code is helpful to others

  • Consider whether anyone else would actually want what you’ve created. Is it so uniquely tied to your workflow or infrastructure that it wouldn’t be useful for others? As a rule of thumb: if making it suitable for general consumption would make it less useful for yourself, then it’s probably not worth the effort.

Ok, so you’ve met those two requirements. Then let’s move to the mechanics of open-sourcing some code.

How Do I Open-Source My Work Project?

Step 1: Audit your code for security leaks

  • Chances are higher than you might like to admit that you or a colleague have left some passwords, usernames, IP addresses, machine names, personal contact information or other security hazards somewhere in your code. Keep in mind that this applies not only to your final master code but also to all the changesets you’ve had in the past.

For that reason, we recommend you do two things:

1. Make a brand-new repository
    • Chop off all the history of the code up to that point. There will be a new history and it saves you having to audit all the historical versions of your code. Plus, no one needs to know that it took you two weeks to wrap your head around C++11 lambda syntax.
2. Audit the code for security problems
    • This will take a lot less time than you think. Look especially at test suites and any places that are near connection points to other systems.

Step 2: Strip your code of profanity and immature pot-shots

  • While you’re in there, also rip out anything inappropriate that makes you sound more like a teenager than a professional. This doesn’t mean you can’t have any humor in your source code. But it does mean that jokes made at the expense of your competitor, a customer or the decrepit browser you’re forced to support might not be appropriate.
  • If in doubt, think about whether you’d feel comfortable reading your code loud to those beyond your team.

Step 3: Make sure your code adheres to best-practice naming and formatting

  • You’ll want your open-source code to be examples of your best work. Make sure you are using good, standardized naming conventions and formatting. Use tools like pyflakes/pep8, jslint, gofmt, ReSharper and others to help.
  • Also, keep in mind that if you’ve been wanting to do the One True Naming Standardization for your project, now’s a good time. Once you open-source your code, there will be a lot of inertia to avoid breaking changes. Get those done before you release. It’ll also make it easier for other contributors to get started with your code.

Step 4: Document it

  • You don’t have to write ninety pages of info docs but you should at least have a nice Markdown-formatted README.md in your root directory that explains what your software is, how to use it, and (if applicable) how to build it.
  • If you’re releasing a library, you should also make sure your code has docstrings/JavaDoc/whatever so that you can generate API documentation.

Step 5: License your code

  • You may want to get some proper legal advice on this. But before releasing your code, you should pick a license. Unless you have a compelling reason to do otherwise, the MIT license will probably suffice. It’s short, sweet, well-understood, liberal and makes integrating third-party changes back into your own products headache-free. But if you’re contributing to the code that you want to include in a project that already has its own license, you might want to use that license instead. Here’s a useful overview of license types for more info.
  • You’ll want to put a LICENSE file in your repository and have a copyright notice somewhere prominent — either in that file or in the README. Such as ‘(C) 20XX Your Name. All rights reserved.’

Step 6: Name your library or tool

  • Pick a name. Make sure it’s not offensive and avoids having the same name with other existing libraries and trademarked products.

Step 7: Push your code

  • Put it on GitHub, create your own organization, repository and push your code.
  • Keep in mind that some communities have secondary systems that you should consider utilizing as well. If you’re writing .NET, then another one might be Codeplex. If it’s Ubuntu-specific then a Bazaar mirror on Launchpad etc.

Step 8: Publish your package in the appropriate package archive

  • If you’re publishing a library, submit it to the appropriate package manager. For .NET, that would be NuGet; for Python, it’s PyPI; for Perl, it’s CPAN; for Ruby, it’s RubyGems; for Node, it’s NPM; and so on. Also, make sure that someone else at your company, such as a sysadmin, has the ability to continue maintaining the library under the unfortunate circumstance that you get hit by a bus.

Step 9: Announce your code

  • You’re all good, time to announce it! You’ll want to blog and tweet it out. You should also consider publishing on /programming on Reddit and Hacker News etc.

And that’s it! You’re all done!

…well, nearly.

Step 10: Don’t forget about your code

  • Just because you’ve published it doesn’t mean you’re done. You’ve unleashed a new-born into the world; you need to take care of it. Monitor pull requests and bug reports on your new project. If you realize that keeping your project going is overwhelming, then a hearty congratulations! You should remember that it is your responsibility to at least find an extra or substitute maintainer. It’s okay if your project ultimately forks but it’s best not to do so just because you dropped the ball incorporating freely and submitted improvements to your code.

That’s it. For real this time. So go out, contribute, and have fun!

 

How to Organize a Hackathon?

So you want to run your own Hackathon? Great! Hackathons are a good way to meet and exchange ideas with fellow developers and creative team. They provide attendees with a boot camp style of learning and making something in just a few hours or days. They also push people out of their comfort zones so it can be a great method of getting people to work on different projects or with new technologies and programming languages. However, these events take a significant amount of planning and preparation in order to be successful. We’ve run many similar events for developers over the years and here are our tips for organizing your own Hackathon:

Pick An Inspiring Theme

There are plenty of events for developers. Pick an interesting theme for your Hackathon to help your event stand out and improve attendance.

It could be a community event based around a specific language or tool. A corporate event for an API or product. Perhaps an internal event to encourage innovation (Facebook’s Like button was first demoed at their own internal Hackathon). Or maybe one based around some special interest topic, such as a charitable cause or a hot topic. Whatever it is, it’s worth investing the time to come up with a creative spin that sets it apart from the others.

Set Event Goals and Define Success

Having a clear idea of what you want to get out of your event will allow you to focus on what matters. You might define success with the number of attendees, submissions or press mentions but identify your conversion criteria upfront to simplify the planning process.

Work Out Who You Need to Involve

Knowing your goals will help you begin to understand the scale of your event and what you need to focus on. If it’s maximizing the attendees, then you’ll want to go big. Big often means expensive and you may want to get sponsors involved to cover some of the costs if not all. If the Hackathon has a competitive edge, then that means hosting judges on duty. Maximizing submissions? Then you might want to think about offering prizes. Doing it for the coverage? Then start reaching out to your media contacts early.

Hackathons also have a lot of tiny details need to be taken care of and often all at the same time. Since you can only be in one place at once, you’re going to need assistance. You’ll need an MC to keep things organized and the event flowing. Then there are reception people in front of the doors to get attendees registered. To get the most value out of your event, you should consider recording it and taking lots of pictures so perhaps a photographer or at least a friend/colleague or two. You know the ones with the fancy cameras that they carry with them everywhere they go? If you’re doing demos, then you’ll also need people to help with the A/V equipment and be on hand to offer tech support. Make assisting people clear and visible on the day of the event with colored t-shirts.

Choose a Date and Time That Works

You need to pick a date and time that will work for your crowd. Make sure you spare enough time to plan it all and consider the day of the week that will maximize the attendance.

For work-based Hackathons around a product or service, weekday events are OK. You’ll need to provide long enough notice for attendees to get approval for the time out of the office. Also, stick to typical office hours like 9 to 5. For other types of events, weekends are better, especially for longer events. Weekday evenings, straight after work, can work well for shorter events – just remember to keep the drinks flowing.

Before you settle on your date, check out event sites like Eventbrite, Meetup and Lanyrd to rule out clashes with other events. Starting 8-10 weeks in advance is usually about right and remember to at least send out a ‘save the date’ blog post or mail once you’ve picked it.

Find An Awesome Venue

This will probably be your biggest expense but it’s not where you want to try to save money. Location can be a key factor for attendees when deciding whether to come or not. It needs to be a convenient location with easy parking, big enough for all the attendees and have the facilities to support them. That means enough space, WiFi and power. If your event runs overnight, then you’ll also need accommodation for people, blankets, stuff to lie on and maybe showers.

Make it as easy as possible for people to get there. Provide comprehensive directions, maps and transportation details. Don’t forget to spell out what to do once they get there too – signing up at the reception, how to get through the security and more. Print big signs to guide people.

Get the Kit

You’ll need A/V equipment like projectors for simultaneous sessions and microphone for slides and demos of applications. Make sure to test it ahead of time. The first time you set it up shouldn’t be the day of the Hackathon.

It’s often easier for attendees to present on their own hardware. Yet, you need to allow a quick turnaround between presenters. To save some time, have a couple of stations connected to the projector ready. This way, while one team is presenting, the next one can be set up.

If you’re filming the event, and you should, then, you need camera equipment. Unless it’s going to be a regular thing, you may want to hire the equipment or a photographer/videographer who already has it.

Get your swag on. Have a bunch of t-shirts available for giveaways and thank yous. Whatever design you come up with, make sure it doesn’t have a date on it. If it does, that means you can’t re-use any leftovers later on.

Have plenty of spare cables, USB drives, socket adapters and extenders available. Cover all connection types – Thunderbolt, DisplayPort, VGA etc.

Have Killer WiFi

This is super important but like at many hotels, WiFi sucks at a surprising number of event venues. Check this out before deciding on the venue and make sure the venue knows how important this is for you. Better yet, pick a venue where the WiFi has been thoroughly battle-tested by previous dev-related events. Make sure the venue has plenty of power sockets too. You want approximately 1.5 per attendee to cover all the laptops, tablets, phones and personal electronic devices.

Get More Than Enough Food and Drink

Don’t skimp on the food and drink. Nothing sends people home quicker than being hungry or thirsty. Have a large variety – it can’t be all Red Bulls and Oreos. So include soft drinks, tea, coffee, water and juice to your drink menu. Arrange breakfast, lunch and dinner. Have snacks available whenever people want them and include both healthy and junk food options. No matter what you do, don’t run out! If necessary, make trips to the local shops if you’re getting short during the event. You always want to end up with too much than risk having too little.

Communicate About the Event Regularly

Blog regularly before and after the event. Hit up any press contacts and influencers that you know to spread the word on Twitter and other channels. Keep in regular contact with your prospect registrants – once people know about it, you want to make sure it stays on their radar. To help you with this communication, set up a dedicated mailing list. Drip out information like venue confirmation, sponsors, judges and guests. Remember to follow up after the event as this is a good way to keep the mailing list fresh and ready for your next event.

You also want to set up a dedicated web page or site for the event which collects all the key data (date, location etc). For registration, don’t re-invent the wheel, just use Eventbrite, Meetup or similar.

Have Fun

Once it’s all over, remember that it was, in fact, a ton of fun and start prepping for the next one.

 

7 Tips for Better Developer-Designer Relations

In typical organizational groupings, designers and developers often find themselves in separate teams. Also, a common misperception of the people in these roles is that they are different — developers are logical, analytical, left-brainers whilst designers are the creative, flexible, right-brainers. And whenever people are separated like this, it’s easy for the relationship to become adversarial. Pretty soon all you do is to focus on the differences. Either they are those hippy-dippy designers with their strange and impossible requests or those vision-less, code monkeys. An ‘Us vs. Them’ mindset takes hold, leading to a break-down in communication which gets borne out in poorer products.

But does it need to be like this? I mean, there’s a lot of common ground. Both have a keen eye for detail, solve problems in creative ways and often share a love of great tools and technology. What’s more, the theory around what you can do to overcome these issues is simple. You just improve communication, empathize with the other team, respect to their contributions and build trust. Yet, actually achieving that can be tricky.

So, here’s seven practical things you can do to help designers and developers work better together:

1. Mind the Pet-Peeves

Developers:

  • Be Clear About What You Want

Often it seems that designers are expected to be mind readers. The brief for designers can be a little more than “go make this look good.” It’s just how a developer might ask for a requirements specification, a clear brief for a designer is also important. Make sure to provide examples of what you need. These might just be links to how others have approached a similar thing or even a quick sketch.

  • Be Mindful of Design Constraints

If you’re working with data, then supply real samples if possible. Knowing the data ranges you’re trapping in your code can be useful for designers to know too. Designers also need to know things like screen sizes and browser compatibility from the start.

  • Be Open About What’s Achievable

Developers can be the gatekeepers of what gets implemented. A big idea can all too often be dismissed out of hand in the name of time or performance constraints. Often though there’s a compromise to be made, with some part of the original idea being possible. So staying open-minded and working with the designer to find that compromise is important.

Designers:

  • Make Your Assets Easy to Work With

Name different file versions so that the latest version or the one you want to be used is easily found. Maintain the layers in image assets, naming them usefully and grouping them whenever you can. Don’t forget to also remove any old and no longer needed layers and files. If possible, prepare the assets for use too — cut them up so that they can be used straight away.

  • List Out Key Details

List out the names of fonts, text sizes and hex color codes used, along with the widths, heights, padding and margins you’re expecting. Doing this can be a real time-saver for developers.

With those pet peeves eradicated, you can start to focus on processes and ways of working.

2. Work Closely Together

This can be just having designers and developers sit next to or near each other. This helps encourage short, informal conversations that lead to more open and frequent communication. But this can also be applied remotely too with regular video chats and Instant Messenger or Group Chat. Either way, if you do this, then over time you’ll absorb knowledge about each others work.

3. Start Communication Early, Continue Regularly

It’s best to start a communication between the two teams as soon as possible into a project. If you build it into your process right from ideation, then there are no surprises that can cause problems later. So start off with designers and developers working together on how they can approach the project. Then continue the communication right throughout the build too. Look for opportunities to keep each other up to date on progress and developments. So, for example, when working on wireframes, designers can involve developers in deciding how to work with different screen sizes, devices, and browsers. Designers can share sketches, and likewise, developers can share links to works in progress. At all stages, bounce ideas off of each other, not just your own team, and break out onto whiteboards when you need to work through a problem.

4. Pair Designers and Developers

When the chance to work together doesn’t emerge itself, you should actively encourage it with the designer-developer pairing. For example, as Cap Watkins recommended in our recent interview, designers and developers can work together on a design bug rotation. This is where designers and developers pair up to work through a list of design issues. This involves discussing the problems, deciding on solutions and fixing them together. By doing this, designers are given insight into the code and developers are exposed to design-related issues.

5. Open Up Design Critiques

Opening up design critiques to others is a great way of helping them to better understand design work. This is something we’ve started doing at Fog Creek. We’ve seen that by showing example work and then walking through the design rationale, non-designers can better appreciate design issues. What’s more, describing how you’ve considered implementation issues shows that you’re taking developer problems seriously.

6. Run Designer and Developer Placements

For example, Etsy runs an engineering placement program. This program aims to get employees with no technical knowledge in deploying simple code changes in a few hours. Spending time working with other teams, even for a short time, helps to foster cross-team communication. This can be taken further too, with embedded team members, so designers embedded in development teams and vice-versa. Trish Khoo explained how this works with embedded test specialists at Google, in an interview with us.

7. Learn about Design or Development

Knowing even a little about code will make you a better designer. It’ll help you to understand and resolve implementation issues that you would otherwise have run into later. Similarly, some understanding of the theory and processes involved in design work will enable you to provide more useful feedback. Learning about design does not mean you have to be creating design assets. And the same goes for the code too. But by at least knowing the terminology and key concepts, you’ll be able to have more meaningful conversations about design and code issues.

By thinking through and creating opportunities for designers and developers to work on issues together, you can encourage a closer and better working relationship.

Why Your Retrospectives Have Become Unproductive?

Retrospectives provide teams with an opportunity to reflect. They’re an opportunity to discuss what is working and what isn’t with the goal of iterative improvement. The meetings should create a safe environment for team members to share and discuss processes and practices constructively so they could come up with actions to resolve problems or improve how the development team functions.

Yet, often this isn’t the case — retrospectives break down, become unproductive or just don’t happen at all.

Here are 3 core failings with retrospectives, along with potential causes and remedies:

1. Retrospectives That Don’t Lead to Real Change

The desire for continuous improvement is at the heart of retrospectives. The feedback gathered during the meetings should result in action items. These action items, upon completion, should deliver positive change. But if the action items aren’t completed or the true cause of problems is not identified, then the faith in the process can wane.

This can come about for a few reasons:

  • Too many action items

It’s important that you don’t try and tackle too much and fail to make real progress with any of them.

  • Items are vague or have no clear resolution

The action items you create need to be specific and have a definitive end point. Items like ‘improve test coverage’ or ‘spend more time refactoring’ lack specificity and need to be quantified. Concrete action items provide demonstrable results — allowing the team to see and feel the improvements achieved by following the process.

  • A lack of responsibility for actioning items

Often the facilitator can end up with all the issues or items are assigned to groups of people. This is a mistake — each item should have a dedicated owner who is in charge of ensuring to get it done, even if a team would be completing them.

  • Too much emphasis on technical issues

Working with tech is what we do so identifying problems about systems, servers, libraries and tooling are easy. But you need to ensure that you give just as much attention to working practices, communication, and people problems. Otherwise, these key impediments to improvement will hold you back.

Whatever the reason is, it’s important that you’re completing the action items. So prioritize them and focus on just a handful of items that you know can be done before the next retrospective. Break down larger issues so that you can begin to make progress with them too. Track items raised at previous retrospectives and review results in each session. This sense of momentum helps to build and maintain a belief in the process and fuel future improvements.

2. Retrospectives That Don’t Occur Often Enough

If retrospectives don’t happen often enough, it can cause a number of knock-on effects:

  • Too much to go over in any one retrospective

This results in meetings that fail to get to the cause of issues. Or due time isn’t spent on issues important to attendees, which can be disheartening.

So much has changed since the items were identified that the issues raised are no longer a priority. This doesn’t mean they aren’t important. More often, it just means you’re compounding them with others and you’re missing an opportunity to improve.

3. Lack of Participation in Retrospectives

This can often happen if the meetings aren’t managed effectively:

  • Sessions are long-winded

You should decide on the agenda before the meeting to avoid straying off the topic and unfocused discussion. You might want to consider time-boxing sections of the meeting. This helps to ensure discussion on one section or type of problem doesn’t consume all available time and attention, and that all areas get adequate attention.

  • Sessions have become stale

Change things up. Try removing seating for one session, so people don’t just sit back and switch off mentally. Or change the format so you aren’t just repeating the same old questions. There are plenty of different techniques: from the Starfish and 4Ls to FMEA if you decide to deep-dive on a specific issue. Or just pair off and discuss items to bring back to the group. Some people open up better in smaller groups. And one-to-one force a conversation, otherwise, things get awkward.

  • There’s a lack of trust

A lack of participation can also result from a breakdown in trust. You should only invite team members to take part. Observers, especially management, despite noble reasons for attending, should be dissuaded from doing so. It may seem to make sense to share feedback so that other teams can learn from it too. But the specifics should be kept in the room. People might not contribute if they know there will be a long-term record of it, or if attributable comments are shared. Just share the action items or areas you’re looking to improve.

  • Sessions are too negative

Retrospectives should encourage introspection and improvement. But this doesn’t mean it’s just a time to moan. It can be too easy to focus on the things that aren’t working or you failed to do. So it’s important to make an effort to highlight improvements, and not just from the last iteration but over time too.

With a few changes and a renewed commitment to the process, retrospectives can be a great way of ensuring you’re constantly improving. They can be an important part in making the working lives of your developers better and more productive.

Stop More Bugs With This Code Review Checklist!

Checklists are a great tool in code reviews — they ensure that reviews are consistently performed throughout your team. They’re also a handy way to ensure that common issues are identified and resolved.

Research by the Software Engineering Institute suggests that programmers make 15–20 common mistakes. So by adding such mistakes to a checklist, you can make sure that you spot them whenever they occur and help drive them out over time.

To get you started with a checklist, here’s a list of typical items:

Code Review Checklist

General

  • Does the code work? Does it perform its intended function, the logic is correct etc.
  • Is all the code easily understood?
  • Does it conform to your agreed coding conventions? These will usually cover the location of braces, variable and function names, line length, indentations, formatting, and comments.
  • Is there any redundant or duplicate code?
  • Is the code as modular as possible?
  • Can any global variables be replaced?
  • Is there any commented out code?
  • Do loops have a set length and correct termination conditions?
  • Can any of the code be replaced with library functions?
  • Can any logging or debugging code be removed?

Security

  • Are all data inputs checked (for the correct type, length, format, and range) and encoded?
  • Where third-party utilities are used, are returning errors being caught?
  • Are output values checked and encoded?
  • Are invalid parameter values handled?

Documentation

  • Do comments exist and describe the intent of the code?
  • Are all functions commented?
  • Is any unusual behavior or edge-case handling described?
  • Is the use and function of third-party libraries documented?
  • Are data structures and units of measurement explained?
  • Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’?

Testing

  • Is the code testable? i.e. don’t add too many or hide dependencies, unable to initialize objects, test frameworks can use methods etc.
  • Do tests exist and are they comprehensive? i.e. has at least your agreed on code coverage.
  • Do unit tests actually test that the code is performing the intended functionality?
  • Are arrays checked for ‘out-of-bound’ errors?
  • Could any test code be replaced with the use of an existing API?

You’ll also want to add to this checklist any language-specific issues that can cause problems.

The checklist is deliberately not exhaustive of all issues that can arise. You don’t want a checklist which is so long no-one ever uses it. It’s better to just cover the common issues.

Optimize Your Checklist

Using the checklist as a starting point, you should optimize it for your specific use-case. A great way to do this is to get your team to note the issues that arise during code reviews for a short period of time. With this data, you’ll be able to identify your team’s common mistakes, which you can then build into a custom checklist. Make sure to remove any items that don’t come up (you may wish to keep rarely occurring, yet critical items such as security-related issues).

Get Buy-in and Keep It Up To Date

As a general rule, any items on the checklist should be specific and if possible, something you can make a binary decision about. This helps to avoid inconsistency in judgments. It is also a good idea to share the list with your team and get their approval on the content. Make sure to review the checklist periodically too, to check that each item is still relevant.

Armed with a great checklist, you can raise the number of defects you detect during code reviews. This will help you to drive up coding standards and avoid inconsistent code review quality.

What A Great Software Does?

Great software helps you out when you misunderstand it. If you try to drag a file to a button in the taskbar, Windows pops up a message that says, essentially, “You can’t do that!” but then it goes on to tell you how you can accomplish what you’re obviously trying to do (try it!)

Great software pops up messages that show that the designers have thought about the problem you’re working on, probably more than you have. In FogBugz, for example, if you try to reply to an email message but someone else tries to reply to that same email at the same time, you get a warning and your response is not sent until you can check out what’s going on.

Great software works the way everybody expects it to. What great software has in common is being deeply debugged and the only way to get software that’s deeply debugged is to keep track of your bugs.

A bug tracking database is not just a memory aid or a scheduling tool. It doesn’t make it easier to produce great software, it makes it possible to create great software.

With bug tracking, every idea gets into the system. Every flaw gets into the system. Every tester’s possible misinterpretation of the user interface gets into the system. Every possible improvement that anybody thinks about gets into the system.

Bug tracking software captures the cosmic rays that cause the genetic mutations that make your software evolve into something superior.

And as you constantly evaluate, reprioritize, triage, punt, and assign these flaws, the software evolves, it gets better and better. It learns to deal with more weird situations, more misunderstanding users and more scenarios.

That’s when something magical happens and your software becomes better than just the sum of its features. Suddenly it becomes reliable. Reliable, meaning, it never screws up. It never makes its users angry. It never makes its customers wish they had purchased something else.

Getting Started with Iteration Planner for Agile and Sprint Planning

Iteration Planner unlocks the power of the project management software as an Agile planning tool for software development. With it, you can combine sprints and milestones to graphically group cases into the scope of work that you’ll complete in each sprint. You can also balance the allocation of resources by dragging and dropping cases from one assignee to another. Iteration Planner is a lightweight way to plan work and manage teams using FogBugz.

Here are a few key suggestions to help you apply priorities in your projects:

  • 1–3 Minimum Viable Product
  • These are all of the cases that must be completed in order for your sprint to provide new value to the customer in the form of a usable feature.
  • Priorities 4: Hygiene
  • This is non-essential work that improves the product but is not required in order for the product or feature to be useful to a customer. Small amounts of this work are often spread throughout sprints to continue making small improvements to the product.
  • Priority 5: Incidental work
  • Don’t allow your scope to creep from a manageable size to something so huge that it couldn’t be completed in less than a decade by Steve Jobs and a host of efficiency experts. If you add something as incidental work that needs to be done during a sprint you need to subtract or deprioritize some other work that has an equivalent number of estimated hours. Keeping all your incidental cases under one priority allows you to group cases by priority and see how much time you are spending on cases that are not part of your MVP. At the end of your sprint add up the hours and determine whether or not the interrupts were a worthwhile use of your time. This discussion can be part of your retrospectives or done separately. Either way, the numbers should be useful for evaluating whether or not the work that was done during the sprint was part of the planned work.
  • Priority 6: Long-range work
  • Frequently teams are asked to take on a category of work that is not part of the MVP but does contribute to the overall plans of the organization. These tasks may be expected to take many sprints to complete and their progress needs to be tracked across multiple milestones.
  • Priority 7: Stuff we won’t do
  • It’s useful to declare this as a way of focusing the team and managing expectations about the work that will be completed in the sprint.

For Agile software development teams, Iteration Planner is a useful, graphical tool that allows you to visually manipulate the information you need for planning Sprints. With it, you can set the direction for your team’s work and monitor progress so you can deliver on your organization’s goals.

How to keep track of cases in multiple projects at once?

Life is complicated and we all accept it. While we tend to categorize the different aspects of our lives, in reality, things rarely fit neatly inside the little boxes we carve out for them.

Our work life is another major compartment and when it comes to planning, it’d be nice if a single project captured all the details we might need to organize work for a project or product and across teams, but often that’s not possible.

This meant at times, working with the Iteration Planner and Kanban boards in FogBugz could be kind of awkward. What if you maintain multiple products and each one has its own project? You’d want the “Planner” to show both at the same time, but it couldn’t. Or, what if several teams had multiple projects relating to a single product? You couldn’t plan without affecting the other teams.

Well, such things are not a problem anymore! With the cross-project planning capabilities in Iteration Planner and Kanban, you can keep track of cases in multiple projects at once.

That means you can view all cases relating to a product on one board, even if they’re in separate projects. And multiple teams can plan things without disrupting or being interrupted by others.

Here’s how it works

Site admins can create a new planner and associate it with one or more projects. Each planner may contain any global milestones and any per-project milestones for its projects. You can also optionally filter by project or area, and filtering down to multiple projects is allowed too.

For existing customers, each of their single-project planners migrated to the new versions. If you would like to add additional projects to a planner, view that planner and click “Edit Planner Settings” in the top-right, then “Add Another Project”, select additional projects and click “Save”. With that done, you can add milestones from those projects and any global milestones, and the filter columns shown will include cases from your selected list of projects.

If you use our Kanban board, the project selections for your planner also apply to each milestone when you click through to the Kanban view.

Take a look at our help site for more details. If you have any questions or feedback, please get in touch!