Takaaki Kato

A Good Company

• Everybody is a good writer (English and/or a language of stakeholders). Everyone avoids any grammar errors and typos.
• Everybody has his or her own blog whether or not the topic is tech-related.
• Everybody learns the wiki syntax of the wiki engine they have chosen.
• Make a wiki with minimal content and keep it up-to-date. Wiki with obsolete content is useless. A company or team considers a 10 min wiki cleanup time for each week.

Productivity

Everybody is a productivity hacker. Always share tips and tricks to increase the productivity in the company in general. Not necessarily about programming, but about everything the company is involved in. (Gmail, email clients, phones, communication with clients and so on in the team.) Make company cheat sheets or a productivity wiki.

Communication

• Every programmer/developer learns to communicate directly with the stakeholder. Reduce the burden on the manager. If there is a basic agreement about, for example, a new feature, some of the details can be directly talked between developers and the stakeholder. That is, each developer establishes trust with the stakeholder a little by a little. (This is quite difficult, but hiring a manager is more difficult. A company needs to educate programmers/developers.)
• Every developer is a good communicator. Loves to write a blog, attend workshops/conferences, and speak at conferences.
• Every developer is supportive for business/sale people learning the wiki, bug trackers and other tools.

Money and Time

• Time is money.
• Don’t waste your time because you are wasting money.
• Budget means both time and money.
• Calculate how much a meeting costs.

A hosted Solution vs. A Company Hosted Solution

A company hosted server is good if many of the developers are good at servers. But with few good at servers, it will take time to fix a problem when a problem occurs. The company is still paying time for the server guy. The server guy needs to stop his work to fix the server. Using hosted solutions (Google Apps, GitHub, Basecamp) might be cheaper solutions. Always consider how much you are paying for each developer an hour.

Programming Practices

Consider Extreme Programming Practices where possible. (Don’t have to follow everything.)

Pair Programming

• Have a standup meeting every day. You don’t necessarily have the meeting in early morning. It’s actually productive, communicative and fun.
• Everyone reads Getting Real and Agile Manifesto.

Pair work/programming is encouraged. The number of programmers should be even. If a developer with good skills doesn’t share his knowledge, the company itself cannot benefit fully from the knowledge. If he or she leaves the company, the others will be left alone without necessary skills. (If you are not pair-programming and want to secure a job, write code that is complex and nobody can read. You will never be fired.)

• Collective Code Ownership
• Pair Programming
• Pair programming - Wikipedia, the free encyclopedia
• Hashrocket Series: Jon and Sandro on Pair Programming
• Obie Fernandez: The Hashrocket Way: Pair Programming

One of the big obstacles of pair programming is occasions where your partner is absent.

• Consider a story card based project management such as Pivotal Tracker.
• Consider Scrum.

Even office work can be done in pair. A small company needs sharing of knowledge and skills. Pair work encourages communication between workers.

Test-Driven Development and Behavior-Driven Development

They are often called TDD, BDD respectively.

• Test-Driven Development in Wikipedia
• Test Driven Development
• TATFT — I feel a revolution coming on
• Behavior-Driven Development on Wikipedia
• Lightning Talk: TATFT - Test All the F***in Time

TDD/BDD reduces anxiety and stress from programmers. Produces fewer bugs, and find and a bug quicker.

Web Development Practices

• A programmer is willing to learn (a) learning more server/low-level development or (b) more frontend technology. (a) is mainly for security and network/server/database performance while (b) is for more Ajax, CSS and ActionScript, Flash, Flex, AIR.
• A graphic designer is willing to learn more frontend development (CSS, JavaScript and basic programming and different template systems).
• A developer tries to learn about finance/company management a little by a little.
• Always keep in mind that developers work on cool languages and frameworks. The language and frameworks will evolve over time. Don’t forget to include the time for keeping up-to-date with the language and framework the company is using. That should be included in estimate. Nothing is worse than joining a team and notice that the company is using a very old version of a very cool framework.
• Don’t use notebooks without an extra keyboard (and an external screen). RSI is killing people.

Hiring

• A company encourages developer’s activity. Open-sourcing a company internal plugin is a big plus for recruiting another hungry developer. If letting employees speak in conference, the company needs zero yen for recruiting. Good people come to the company.
• Everyone is involved in the hiring process even when the decision on hiring is not based on everybody’s agreement. Everyone learns to be a better job interviewer.
• Every employee has a hobby other than programming/designing. Thinking only about a job 7 days a week doesn’t last. Good leisure time makes good concentration time at work. If you are workaholic, set a time limit. Ask what’s his or her pastime in a job interview.

Business

Understanding the whole company as a team is critical. Developers try to understand more and more about business. Business people, on the other hand, try to understand more about developers, by avoiding mass emails, guarding their attention and learning how to use tools such as bug trackers and wiki.

Consider incorporating some practices from Rails Maturity Models.

• Get things done. A company gets money by delivering. The development process doesn’t yield to money. Everyone in the team considers delivery over process.
• Non-flexible hours are encouraged. Otherwise, people working early end up with receiving calls and getting packages. There’s no time to concentrate on early hours. A company should set business hours and put that information on the website, and ignore any phone calls before/after the hours. A company could have a lunch break, where no phone calls are taken.
• Each task should be S.M.A.R.T.
• Be influential to other companies. Have a company tech blog or lab blog.
• Non-smoking. Allowing smoking is kicking out those pregnant.

Emails and Other Communication Tools

• Don’t abuse BCC.
• Write a better (e.g., concise, meaningful, well-formatted) email. Use spell checkers for any emails. Bottom-posting is encouraged. Use plain text emails.
• If you send any off-topic emails, you can start a title with distinction such as “[OT] Funny pictures” or “[Inspiration] Elegant examples of forms built with jQuery” Decide such “tags” in your team.
• Don’t assume that developers check their email every 5 minute. Set a rule on how often or when emails should be checked.
• Don’t allow employees to check their private emails and RSS or surf websites in work hours. Pair programming solves this problem. If your employees spend 8 hours with good concentration, they will have plenty of time to spend on private things. Of course, some breaks are needed during the 8 hours where employees can check private emails.
• Fewer emails. Everyone refrains from unnecessary emails. Always send an email only to those who need it.
• When Skype is used, everyone makes a new account for usage during work.
• Build a communication central. Wiki, Basecamp, Campfire, presently. Discuss with everyone. Don’t let specific people decide. Use the system. Don’t complain about the system that everyone decided upon.
• Make a rule for which kind of information can be transmitted via which method (e.g., email, phone, Skype, Basecamp, Backpack, Campfire). Write the rules in the wiki so that a new hire can learn about the rules quickly without interrupting others.
• Guard attention from programmers. Programming/designing requires concentration. There should be a rule on who is in charge of getting calls. If every developer needs to try to answer a call, it’s a complete waste of time. Coming back to the state of mind of concentration takes about more than 10 minutes.
• Consider using Twitter-for-enterprise solutions. Yammer and Present.ly
• Have a dedicated time for direct communication. 50 minutes for working on their own tasks and 10 minutes for direct communication with others. Developers then secure their attention to their tasks for 50 minutes.

Equipments

• Allow developers’ machine HD to be clone-backuped up. Reinstalling the OS and every tool takes time, and the company is paying for the time as well. External HD’s are inexpensive.
• Coffee and water server (LOW PRIORITY, but if your location is not close to a vending machine or a grocery store, it will be time-saving.)
• Different people have different tastes and flavors. A chair, a desk, a screen size, OS, a text editor, mouse… Ask each developer and find out if there’s anything that can be improved. What you think is the best is not always the best for everyone else. (Needless to say, online tools are important as well.)
• Headsets are essential for those responsible for getting calls.

Ruby

• Ruby at ThoughtWorks. (Of course, Ruby doesn’t solve every problem.) Python is a dynamic language, too.
• Choice of languages and frameworks doesn’t matter to customers in most cases. Pick solutions that are fun and energizing to employees, not to employers.

Postscript

Not everything of what I mentioned above applies to a company. Flexible hours does have an advantage, and remote workers have some advantage. Coding solo isn’t bad at all. I am lacking in arguments from the management side. I wrote this with a company of 5 to 30 people in mind. I am spending each day to be as much efficient and productive as I can in doing anything. Group/organiization productivity is harder to achieve than personal productivity.

In summary:

• Share your knowledge and skills with others.
• Be productive, but help productivity of the company as a whole. You are not the only one to work in the company. Don’t disturb each other.
• Time is as important as money.
• Consider how much each developer cost per hour.