Google Hangout for Standups and Interviews

We’ve been experimenting with Google Hangout for meetings such as daily standups with remote team members and interviews with remote candidates.

We concluded this experiment was a success.

It’s nice to have a recurring calendar invite to open, click “Join Hangout” and start talking.

Google Hangout is sometimes choppy over wifi. The settings need to change when we switch from laptop to monitor, so we often are without sound for a few seconds before changing the “FaceTime Camera (Built-In)” setting to “FaceTime HD Camera (Display)”.

We’ve noticed in longer meetings, we sometimes need to refresh the page if sound starts to get choppy, presumably to clear some buffering.

We’ve noticed during Hangouts that the sound captured by a Macbook Air’s internal microphones is often muffled. We generally have Macbook Pros for better performance of test suites, but there are a few of us who have Airs. We have started to fall back to phone calls for sound in those cases.

Overall, it’s always better to see someone’s face.

Written by Dan Croak.

From the desk of a thoughtbot apprentice

First, let me introduce myself, my name is Alex and I’m an apprentice here at thoughtbot. You may recognize me from this, this or this.

As an apprentice I get to immerse myself in the world of thoughtbot. I sit next to amazing developers and designers, and do work on the exciting projects that come through the door. As a result I’m learning crazy fast, every day I write code that I could not have written the day before. However, even bigger than the knowledge I’m gaining about how to write code is what I’m learning about process of developing software. One of the things that’s really important is the way people work.

I had heard words like XP, agile, and scrum used to describe software development but had never seen them in practice. After 5-plus weeks here I can tell you that the way they do things works.

Standup

Every morning at 10:00 am the entire team gathers in the conference room. We each go around the room and say something along the lines of the following:

Alex: Yesterday I worked on ______, I implemented ______ I had to do ______ to make it work. Today I will be working on ______. I am blocked on ___________.

Someone else: Yesterday I worked on ______, I did ______. Today I will be working on ______. I have no blockers.

These standups are the lifeblood of thoughtbot. They improve communication internally and provide accountability. If I say I’m gonna do something in standup then I do it. It ensures that if someone is blocked on a problem that someone else can solve, then that problem gets solved.

Retrospectives and teams

We work in teams. Each team usually consists of one designer and 2 to 3 developers. Each team dedicates its time to one project. Once a week each team meets with the client to discuss what was done during the week. As part of the retrospective each person on the team as well as the client goes around the table describing how they are feeling about the project and airing any grievances they may have about the way the project is progressing. These meetings make sure that the team is all on the same page and that we are doing work that our clients approve of.

Airing of grievances

Client Pitches/Caring about what we’re working on

Before we work with a client we ask them to pitch to and converse with the developers and designers (not just the management) on their product. We want to know:

• What’s their business model?
• Who are their competitors?
• Why is it a good idea?
• Will they be fun to work with?
• Do they get the principle of an MVP?

The reason we do this is simple. People do better work on projects that they’re excited about. By having potential clients pitch the product to us we can choose products that we want to work on.

TDD

Before I started at thoughtbot I was of the opinion, like many others, that testing your code is a waste of time.

It was part of my job as an apprentice so I did it. But I was not as exuberant about it as most of the other people here.

But then something changed.

I began to write cleaner code that solved real problems and when code introduced breakages I knew about it right away. 

Now I get scared when I see code without tests and I am test driving all my code, even the stuff I work on outside of thoughtbot.

Trajectory

We practice what we preach and use Trajectory to manage product development. What this means is that there are no emergencies. If a client finds a bug or needs a feature developed, they simply put it in Trajectory and prioritize it. The developers and designers are able to take the top story off the stack and have a discussion around it. All from within the app.

Campfire

We use Campfire extensively. We have a bunch of rooms:

• General Discussion, for company wide news, blog posts, etc.
• Dev Discussion, filled with vim tips, bugs and other geeky goodness.
• Design Discussion, I have no idea what goes on in here but it involves designers.
• A room for each project, in these rooms we post feature branch code reviews as well as project specific questions.
• Last but not least is everyone’s favorite room, Watercoolor (or WC, as we call it). You see images of people’s heads photoshopped onto other people’s bodies as well as other off topic discussions If any of the other rooms go off topic, someone, usually Mike Burns, will chime in with WC reminding us that the current chat belongs in the watercooler room.

These Campfire rooms provide a non interruptive internal dialogue. People can look into the room when they want to and ignore it when they’re busy coding (or designing).

Pace

One of my first days here, someone was explicitly told not to work on a client project on the weekend. This threw me for a loop. Shouldn’t a company want its employees to work all hours of the day?  The thing is that thoughtbot understands that the best code is written during bank hours. This doesn’t mean that thoughtbot employees don’t code at home. Everyone is encouraged to work on open source and side projects at home; however, all client work is done during bank hours when we are writing our best code.

A better way to build software

One of thoughtbot’s informal mottos is there is a better way to build software. After 5 weeks here I can tell you that the fine folks here have got something right. They write great code in a great atmosphere with no stress.

Ongoing refactoring and client work

Anyone who has done client work or worked inside an organization where the priority is on “new” has faced this dilemma: how do you “sell” housekeeping/maintenance and refactoring tasks up the chain of command to your boss or your client? Often times developer claims about wanting or needing to do refactoring work, maintenance tasks, “small tweaks”, etc - are dismissed because they don’t demonstrate immediate progress to the application, or don’t deliver on any new business requirements.

What is refactoring?

By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.

-Joshua Kerievsky, Refactoring to Patterns

That definition is fine for my purposes here, let’s use that.

I think most of the objection to “allowing” developers to do refactoring tasks come from a misunderstanding, but it’s important as a developer to make sure you’re on the right side of the fence on this matter. There are certain tasks which really are a huge waste of time, there are certain tasks which are almost critical to stop what you’re doing and deal with, but the majority are probably somewhere in the middle.

It’s about the context

I think things are somewhat context specific. If your manager has let you know about an important feature that needs to get out, and you insist on renaming some variables instead, that’s probably not legitimate refactoring - you should get the feature out. If the only tasks in the feature queue are things like copy changes and style tweaks, you’ve probably got time to proactively go in and move some code around. Those are the edge cases though, ignoring the majority is how you get into trouble.

The majority? Yes. It takes day to day refactoring to stay on top of problems. If you ignore developing code smells, long methods, crazy hacks that were done to solve a problem quickly, they’ll start to accumulate. Pretty soon you cross over the line from “I wish I had a few hours to clean up these small things” to “I really can’t get any work done at all because this is such a huge mess”. The key is to explain to your managers that there’s nothing wrong about that. Even the best programmers will accumulate code cruft if things aren’t revisited from time to time.

Requirements change over time. Best practices are moving targets. Web frameworks and languages add new features. New libraries are released that solve old problems in new elegant ways. And so on.

Get a boss that understands that. Work for clients that trust you on those facts. Give them my phone number if they don’t believe you.

What to do

Here are some things we do to encourage code quality and commit to ongoing improvement:

Explain the agile process to clients. Specifically, explain how things are in an ordered queue, and how they have a priority. Once that’s done, you can work as a peer to make sure that refactoring and maintenance tasks get into the queue and prioritized alongside new feature work.

Do periodic code reviews. If you can do this weekly, great. At worst, do it monthly. On some projects, we’ve made it a requirement to use a “feature branch” in the git repository, and required that another developer review literally every commit before it makes it’s way into master. This can be overkill on a small project, but it’s worked great once you get more than a few developers.

Have written code standards that evolve over time. It’s important to write them down, because it creates an objective reference to point to when you see someone else do something weird, or aren’t sure what to do yourself. It’s important that they can evolve, because when there’s legitimate disagreement about how to best do something on the team you need to take a moment to revise the standards to account for whatever differences you have. When that fails, call in a third party to help sort it out.

Explain the TDD process. Make sure clients and bosses understand why you write tests. When you explain Red Green Refactor …. don’t skip the refactor step!

But how do I show the client what I did?

It’s all about trust and expectations. If you haven’t explained how this works to clients who don’t know any better, they have every right to demand that every hour of time you put into their project result in something new they can see. If you do explain how maintenance and refactoring and constant quality improvement works, then you’ve set the expectation correctly and they shouldn’t be surprised when tasks that “just change code you already wrote” are showing up in the queue, the changelog and the invoices.

Do any of you have stories of success (or failure) in explaining this issue to your clients, managers or coworkers?

How To: Take Notes Like a Champ

Information Overload

One of our newest projects here at thoughtbot is a taxonomic naming app called GNITE which we’re building for the Marine Biological Lab. As designer on this project my first challenge was to get a basic understanding of the subject matter and the goals of the project, but I found the information to be complicated especially for someone new to taxonomy. We had the pleasure of visiting the Marine Biology Lab in Woods Hole, MA on Cape Cod recently and in the meetings I dusted off an old note taking trick I frequently used in college but with new tools — an iPad and Adobe Ideas app.

Taking notes vs. absorbing information

Design is often about reducing complex systems to their simplest form. Our meetings at the Marine Biology Lab could have produced pages and pages of comprehensive notes but my goal was to organically absorb as much information as possible without the distracting task of transcribing information. Using Adobe Ideas, an iPad and a stylus, I took visual notes, writing down key pieces of information, embellishing them, and organizing them visually. The embellishment is the key part - it leaves your ears open to what’s being discussed. When looking back at my notes I can clearly remember who was talking, what the sentiment was, and other subtle things that could be forgotten during normal note taking. The visual nature of the notes jogs my memory in a way pure text or handwriting doesn’t. The outcome is an understanding of a simplified gestalt which isn’t burdened by details.

Click each image to view it larger:

Adobe Ideas allows fractalesque zooming. You are able to use vast scale differences to communicate importance as well as benefit from a very flexible canvas, so you almost never run out of space taking notes.

Check out that mushroom! Someone said “fungi” so I drew a mushroom. As my theory goes, I absorbed whatever was said after that (it was an anecdotal tale of conflicting fungi names, I believe).

But won’t you miss important details?

The drawback to taking notes like this is that many details will never get written down. If those details are critical bring a voice recorder. In my case there were two developers in the meetings as well, so I was confident our team-like approach would yield all necessary information (and it did).

Life after NDA’s

One of the most exciting aspects to this project is it’s open source which opens the possibility to documenting the building process in ways we usually can’t with most client work. This is the first in what I hope will be a series of posts documenting the design process all the way through to the final product.

Doing Stupid Things Is A Choice

This is the first post in what will be possibly be a 25-part series of business mantras. Each day I will select (or possibly create on the spot) a barely-thought-out phrase, motto, slogan or saying – back it up with a flimsy circumstantial account – and steadfastly insist that it’s correct, possibly in the face of evidence to the contrary.

The mantra of today, day one in this twenty five part series, is “Doing Stupid Things Is A Choice”.

If you work in a large organization, or for the government, or for a smaller organization with an inexplicable bureaucracy problem—you probably know a person or a whole team of people within your organization who have a consistently defeatist attitude about things. They assume deadlines will slip. They assume that work of a subpar quality will be delivered internally. They assume that the messy, complicated and useless processes that exist are “just the way things are” and they don’t care enough to change them.

Similarly, maybe you’ve known that there was a “right way” to do something, but felt that because of organizational politics or incompetence, you needed to find a round-about way of getting there—usually by doing 10 things wrong first.

These systems don’t come into existence by themselves, and they don’t perpetuate themselves either. Each of these attitudes and views about the way things and the way things must be is the result of constant decision making that could be stopped at any moment at all by anyone involved.

No matter what you’re doing or why you’re doing it—you only get one life. In my life, accepting failure and incompetence just because “that’s the way things work here” simply isn’t good enough.

So stop making excuses next time you feel resigned to failure because of some entrenched practice in your organization. By perpetuating the attitude of disappointment, you’re part of the problem.