Archive of published articles by

Back home

Long live Slack, down with egotistical email

17/11/2014

We use Slack for team communication at Cozy. I struggled with the transition. When I reflected on my struggles, it made me better understand what a destructive format email is for workplace communication.

A quick disclaimer. This is only about work communication and not personal communication. I love email. I think email will be around for a long time and I will lament if and when it goes away. I just don’t think we should be using email for work.

Oration is the highest form of feeding an ego. You craft your message carefully. You research, write, and rehearse. Finally, you take the stage. You command everyone’s attention. And once you’re done, an important topic has been thoroughly addressed and everyone can go on with their lives, better off after hearing what you said.

Email is oratory without the speaking* (or skill). My problems with email stem from when it is used for one-way communication. I suspect that most emails I’ve ever received from anyone in management have been one-way. Generally these emails are meant to, first and foremost, communicate the sender/manager’s self-importance. Often the email contains a nugget of actual information which should be hosted elsewhere. Sometimes the email is an announcement no one understands. And as a rule, you can’t rely on people reading the email you send anyway.

When you craft a long email, like an orator crafts a speech, it is an ego boost. Each one is a masterpiece. You are proud of your fine writing. When you craft a long chat message, on the other hand, you look like a dramatic asshole. It puts in stark perspective how awful the written format is for important or high-bandwidth communication. I’ve never seen someone post a 300-word message to chat. How many 300-word emails do you have in your inbox?

Removing email also levels the playing field for communication. You don’t need to be a manager or orator. Everything you write has a visibility you can’t change. You choose your audience based on topic. Is there a question about a product’s design? Well, it goes into the product or design channel, whether you are Executive Emperor or QA Associate II. Also, no one really wants to read your dramatic flair so please keep it short and to the point.

I used to get frustrated when I’d write an excellent email, send it out, and within a few minutes someone would reply with a message like “Yeah, just to build on what Rob said, it’d be a good idea to do X.” You idiot! You are an Ice Cream Truck driving through the State of the Union. But of course, the problem was mine, playing a manipulative game, focusing too much on this amazing message I’d created. Sometimes these emails would be about the manipulative games people were playing and how we weren’t focused on the employees and customers and things that were actually important.

Email in the workplace is a systematic problem. We take it for granted. We use it constantly. We don’t question it. But email has a cost. It feeds into the already inflated ego of managers. It encourages one-way communication. It is wonderful for grandstanding. We spend a lot of time crafting museum-quality correspondence no one wants to read. And in the end, there are better ways to accomplish what we use it for.


* One of the greatest “speeches” of all time, Pro Milone by Cicero, was written, not spoken. We know great orators by their writing, not their speaking.

No Comments

First, do no harm

13/11/2014

From a wonderful post by Matt Williams about the type of business he is looking for:

A Business Manifesto
We are uncovering better ways of running a business and helping others do it.
Through this work we have come to value:
People and interactions over profits and prestige
Quality service over quantity of service
Customer relationships over contract negotiation
Flexibility over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

In a nutshell I want to work for a company which values people — both inside and out of the company. I want to work where people strive to do things right.

When I go home, I want to be able to look in the face of my daughter and not have to make excuses for the work that I do and the effect it has on others.

Sums things up nicely (and definitely what we aspire to at Cozy, by the way we’re hiring).

It is a reason I left the video games industry. I wanted to use my skills to do something I felt was more constructive.

But more than that, I was amazed and frustrated with how the industry was run (almost as bad as films). Mass layoffs even on successful projects. Over-managed projects that go on for 4, 5, 6 years and are cancelled. Creating an exploitative product in order to milk a customer base. Huge budgets, huge marketing, appeals to lowest common denominators (often sexual). There are good companies but the business models are so insane that you can be around for 10 years and fold tomorrow.

2 Comments

Behavioral testing is the bee’s knees

10/11/2014

I have been doing Test Driven Development (TDD) with xUnit-based frameworks (like unittest and NUnit) for a number of years now, and started with RSpec in Ruby and Jasmine in JavaScript a few months ago. RSpec and Jasmine are behavioral testing frameworks that facilitate Behavioral Driven Development (BDD). BDD is really no different from “normal” TDD except for the frameworks used. BDD frameworks facilitate a different way of designing tests.

Behavioral testing is awesome and makes xUnit-style testing seem barbaric and uncivilized in comparison. I didn’t see the big deal for a long time. My xUnit style tests served me just fine. But now I’m hooked.

If you are a TDD person (or do any unit testing), I encourage you to try out BDD. You should get the hang of it quickly. It can take a little while to learn BDD idioms, but once you start doing things like custom matchers, it’s absolutely amazing.

In future posts I’ll try to discuss more of the differences between TDD and BDD, but for now I just provide a hearty endorsement of BDD and frameworks like RSpec and Jasmine.

3 Comments

If you hear “perception is reality” you’re probably being screwed

27/10/2014

I was once told in a performance review that “perception is reality.” I was infuriated, and the words stuck in my mind as the most toxic thing a manager could say to an employee. I have avoided writing about it, but the “This American Life” episode about Carmen Segarra’s recordings at the Fed has inspired me to change my mind. Here’s the relevant section, emphasis mine:

Jake Bernstein: Carmen says this wasn’t an isolated incident. In December– not even two months into her job– a business line specialist came to Carmen and told her that her minutes from a key meeting with Goldman executives were wrong, that people didn’t say some of the things Carmen noted in the minutes. The business line specialists wanted her to change them. Carmen didn’t.

That same day, Carmen was called into the office of a guy named Mike Silva. Silva had worked at the Fed for almost 20 years. He was now the senior Fed official stationed inside Goldman. What Mike Silva said to Carmen made her very uncomfortable. She scribbled notes as he talked to her.

Carmen Segarra: I mean, even looking at my own meeting minutes, I see that the handwriting is like nervous handwriting. It’s like you can tell. He started off by talking about he wanted to give me some mentoring feedback. And then he started talking about the importance of credibility. And he said, you know, credibility at the Fed is about subtleties and about perceptions as opposed to reality.

Well shit, if that doesn’t sound familiar. Here I was, doing work that was by all measures extremely successful, yet pulled into a feedback meeting to be told “perception is reality.”

Let me tell you what “perception is reality” means, and why you should plan on leaving your job the moment you hear it:

The arbitrary opinions of your manager’s manager defines your situation. And they don’t like what you’re doing.

Your manager may be well-meaning (mine was, as was Mike Silva), but at the point you get this “perception is reality” bullshit, you can be sure there’s nothing that they are going to do to help you. Someone above them has taken notice, your manager has probably heard hours of complaints, and you can either shut up or get out. Perception isn’t reality everywhere; it is only the mantra in sick organizations totally removed from reality.

1 Comment

Technical debt takes many forms

23/10/2014

Most people are familiar with “technical debt” in terms of code or architectural problems that slow down development. There are other forms of technical debt, though, that can be overlooked.

Dead Code: There are endless “dead code as debt” scenarios. You have a “live” function that is only used from dead code, hiding the fact that this function is also dead (this situation is cancerous). Every time you grep, you have to wade through code that is dead. Every time someone stumbles across the dead code, they need to figure out if it’s dead or alive. There’s no reason for any of this (especially not “keep it around as reference”). Dead code is a debt, but it’s also easy to pay back. Remove your dead code.

Unused Repos or Branches: Every time a new person starts, they will ponder what code is dead and what is alive. This pondering includes code, issues, and documentation. It is sloppy and unnecessary. Put unused repositories in cold storage. Delete stale branches.

Large Backlog: The larger the backlog, the worse the experience of using it. It’s harder to find, reclassify, and prioritize. Some developers will not even bother. A backlog is not a place for everyone to list anything they think should ever be done. Close stale and low-priority tickets. Close “symptom” tickets that you know won’t be addressed until a system is rewritten. Close everything except 3 months of work (and manage further out work on your roadmap, which should not be in your backlog).

Dirty Wikis/Documentation: Why out of date documentation is harmful should be pretty self-explanatory. Don’t let it get that way (or just delete the documentation). Make documentation someone’s responsibility, or make it part of the “definition of done.”

Every organization has these things. By recognizing them as debt, and thus detrimental to development, it can perhaps simplify any argument about what to do.

3 Comments

PracticalMayaPython: RuntimeError: Internal C++ object (PySide.QtGui.QStatusBar) already deleted.

19/10/2014

TLDR: If you get that error for the code on page 163, see the fix at https://github.com/rgalanakis/practicalmayapython/pull/2/files

In August, reader Ric Williams noted:

I’m running Maya 2015 with Windows 7 64-bit. On page 163 when we open the GUI using a Shelf button, the GUI status bar does not work, (it works when called from outside Maya). This RuntimeError appears: RuntimeError: Internal C++ object (PySide.QtGui.QStatusBar) already deleted.

I no longer have Maya installed so I couldn’t debug it, but reader ragingViking (sorry, don’t know your real name!) contributed a fix to the book’s GitHub repository. You can see the fix here: https://github.com/rgalanakis/practicalmayapython/pull/2/files
And you can see the issue which has more explanation here: https://github.com/rgalanakis/practicalmayapython/issues/1

Thanks again to Ric and ragingViking. I did my best to test the code with various versions of Maya but definitely missed some things (especially those which required manual testing). If you find any other problems, please don’t hesitate to send me an email!

No Comments

High performance, poor morale, and the Niko-niko calendar

2/10/2014

I was introduced to Niko-niko calendars by Max Webster at Niko Niko. Basically, they are a way of tracking a team’s mood over time. At the end of the day, team members put in a smile/frown/whatever face indicating their mood. You can see when people were happy or sad and coordinate that with other events (what tasks they were working on, what happened at work, etc.).

Initially, I thought this was a pretty useless metric. What good leader or manager wouldn’t always know this information? I can tell if things are going well because I speak to the team regularly as I make changes. But it can be useful to track mood for when things get lost in the cracks or regress. It’s also useful as an outside-facing metric, to show people how their decisions impact the team. The more I thought about it, the more I wished I had known about Niko-niko calendars earlier!

I would only consider Niko-niko effective on an already well-performing and generally happy team. It is a pretty high-level metric, so if people are unhappy for many reasons, I doubt you’ll get much useful data. So, with that, how about some scenarios that I would have used a Niko-niko calendar for, had I known about them?

  • Process tweaks like shortening sprints or requiring more code reviews. People are resistant at first but usually accept it. Is this because they get happier over time? Or because they do not feel empowered to change things back?
  • Changing the branching/integration strategy. At previous jobs we seemed to have a new one every six months. At my current job there are fans and detractors of git flow. Does morale go down or stay the same when integrations happen more often? Is this better or worse depending on the branching/integration strategy?
  • How much do people actually hate planning days, and what can we do to improve them?
  • How painful are releases? People should be happiest, not unhappy, before and after a release!
  • Does a team hate what it’s doing? How much does dumping work on a team impact morale? Do they not believe in the product or are expectations out of whack? What can be done to help the team “own” the project rather than resent it?
  • How does changing team composition cause morale to be affected?

I’m sure there are more, but I thought the idea of using a Niko-niko chart could be interesting. I won’t have a chance to try one out for a while, but will post a followup after I do.


I wrote this draft a couple months ago and finished it recently. Since then I’ve seen a few other apps in a similar space, such as Know Your Company and Know My Team, that focus on tracking morale. I think it’s a good trend. And it’s a reminder that what may appear as a management fad can often have deep, established roots.

No Comments

Old towns, and legacy software

25/09/2014

On our road trip from Austin to Portland, we stopped in a handful of towns that were booming in the late 19th century. In particular, Pendleton, Oregon made an impression. They were exhibiting serious effort and success revitalizing the town. Pendleton has a rich and interesting history, but has shrunk (relatively) over the last hundred years. It apparently used to be Oregon’s 4th largest city. There has clearly been a big effort to keep buildings in good condition, create interesting businesses, establish modern dining and arts, and maintain a beautiful and safe river walk. The people who live there seemed to hold a special bond.

Pendleton was quite different from many other towns we saw, which were in decline, derelict, or abandoned.

Pendleton reminded me of my experiences working on legacy software projects. Projects that no one wants to own, that have a successor “coming soon,” or are seen as unimportant; these are depressing to work on. On the other hand, where people have stepped up to really take control of the situation and invest serious passion into a legacy project; special bonds form that are as strong or stronger than can be forged when working on something new.

A town like Pendleton, like a legacy software project, is not going anywhere soon. You can invest in it, make it special, meaningful, and historical. Or you can make it a place for people too old or passive to move from. Towns and legacy software can deteriorate and die. Many have met this fate. Alternatively, they can embrace their legacy and reinvent themselves, with great pride, in the glow of their former selves.

A country of Pendletons is probably not very healthy, but a country with none would lack character and history.

No Comments

Keeping talented employees

18/09/2014

I saw a tweet the other day about the eight things that keep talented employees:

I’m normally not a fan of reducing human behavior to a list like this, but it seems pretty complete, and the words resonated.

As a technical leader I am a fan of metrics and dashboards: tests passing, code coverage, static analysis and metrics, velocity, bugs, takt time, and other indicators that you wouldn’t focus on individually, but are very useful collectively.

I wonder if, as a manager, assuming trust is in place, is it worthwhile to go over these things explicitly? To make a “private dashboard” to cover in 1-on-1s, and see where the problems are?

  • If everyone is not feeling challenged, why is that? Is it because the work is boring? If so, why? Is it temporary grunt work that can be augmented with some side projects? Or is the product becoming less exciting to work on?
  • Who doesn’t feel like they’re on a mission? Is it because they are disillusioned, or is the mission bullshit. Are more people disillusioned each month?
  • Which individuals are trending up and down? Is the organization as a whole trending up or down? Which attributes are trending up and down? For all these questions, you must answer “why“!

I’m not sure this is something I will start using immediately, since I am just getting to know my team and I don’t want overly formal process to get in the way of a human connection. But it’s certainly something I would have done at CCP. It’s very convenient for bad managers to rationalize poor ratings, but perhaps some tracking on these eight points can be a start towards providing quantitative evidence of employee satisfaction.

1 Comment

Two weeks is the worst sprint length

15/09/2014

Mike Cohn over at Mountain Goat Software says this in My Primary Criticism of Scrum:

In today’s version of Scrum, many teams have become overly obsessed with being able to say they finished everything they thought they would. This leads those teams to start with the safe approach. Many teams never try any wild ideas that could lead to truly innovative solutions.

I believe a great deal of this is the result of the move to shorter sprints, with two weeks being the norm these days. Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.

Most teams I have joined have been working in two week sprints, and it has always seemed like the wrong length. In fact, at CCP, I championed “anything but two weeks.” I saw teams unable to get features done and tested in two weeks, which caused teams to not take the “shippable increment” idea very seriously. Nearly every sprint was a failed sprint in one way or another.

My preferred solution was to move to one week sprints. I’ve written about one week sprints before. If Agile is all about feedback, then halving your sprint length gives you double the feedback and chances to improve. You can try something out for a week, find it doesn’t work, and move on without putting a release at risk. A sprint twice as long carries twice the risk. I feel this, more than longer sprints, much better addresses Mike’s goal to get back to creativity. That said, it requires an intense commitment from the team to adopt Agile and eXtreme Programming development practices, such as through automated testing, shared code ownership, and more. It also requires a team that can function and perform well, and someone to coach. Without these things, one week sprints will fail.

My backup solution, when I feel a team isn’t yet ready to go through the transformation one-week sprints bring about, is to move to longer sprints. This does not encourage the behavior I ultimately want to see, but at least it allows more experimentation. More importantly, teams can take the “shippable increment” ideal seriously.

This reasoning can be taken to absurdity, but avoid it. I once had someone seriously suggest two releases a year was too often, and we should go down to one release a year, so we could make sure it was high quality and bug free. These people just need a reminder of the history of software (and often their own company). Even stuff like printer firmware can be iterated on less than 4 weeks.

In the end, I still prefer one week sprints, which isn’t surprising as I’m an XP advocate. But if a team isn’t able or willing to move to one week sprints, don’t default to two weeks.

1 Comment