Archive of articles classified as' "rant"

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

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

Escaping the Windows prison

8/09/2014

My friend Brad Clark over at Rigging Dojo is organizing a course on Maya’s C++ API (I am assuming it is Maya but could be another program). He had a question about student access to Visual Studio, to which I responded:

As a programmer, the experience on Windows is pretty horrific. No built-in package manager. A shell scripting language designed in hell. A command line experience that is beyond frustrating. A tradition of closed-source and GUI-heavy tools that are difficult or impossible to automate. A dependence on the registry that still confounds me.

My eyes weren’t opened to this reality until I switched to Linux. I was on a Windows netbook that was barely working anymore. I installed Linux Mint XFCE and suddenly my machine was twice as fast. But the much more important thing that happened was exposure to modes of developing software that I didn’t even know existed (Python, Ruby, and Go made a lot more sense!). Programming in Windows felt like programming in prison. Developing on Linux made me a better programmer. Furthermore, If I didn’t end up learning the Linux tools and mindset on my own, working in the startup world would be basically impossible.

Programming on Windows revolves around Visual Studio and GUI tools. If you need evidence at how backwards Windows development is, look no further than Nuget. This was a revolution when it was released in 2010, changing the way .NET and Windows development was done. In reality, the release of Nuget was like electricity arriving in a remote village. It took ten years for C# to get a package manager. And it is for the rich villagers only: older versions of Visual Studio don’t work with Nuget.

The ultimate problems Windows creates are psychological. The technical differences change the way you think. It echoes the “your Python looks like Java” problem. Is the Windows mentality what we want students to take on? My last two jobs have been on Linux/OSX. I honestly cannot imagine having kept my head above water if I didn’t have a few years of self-taught Linux experience.

Windows still dominates in desktop OS popularity. That is all the more reason to make sure we are exposing student programmers to alternative ways of developing. I want new developers to be exposed to things outside the Microsoft ecosystem. It is too easy to become trapped in the Windows prison.

5 Comments

Hire talented people and get out of their way?

28/08/2014

Whenever I need inspiration for a blog post, I check my LinkedIn feed. I am bound to find a stupid inspirational quote. Today’s is:

In most cases being a good boss means hiring talented people and then getting out of their way.

This advice (hire smart, don’t micromanage) is so simplistic, it’s hardly worth saying. The profound stupidity is equating this with “being a good boss“.

No, hiring smart people and not micromanaging them is the absolute, bare minimum you should be doing as a boss. Basically, if you call it a day there, you are a worthless, paper pushing, pointed headed body in a seat. If not today, then soon.

What are you doing once you get out of the way? Meetings? And how can you be sure you’re hiring good people, if you’re not closely engaged with the work? Should you offload that to your team? And then what is left to do as a “good boss“, by your definition?

In reality, where being a good boss is incredibly difficult and rare, being a good boss means:

  • Earning trust, and learning to trust others.
  • Improving how decisions are made.
  • Making sure people are learning, challenged, and growing.
  • Mediating business pressures with craftsmanship.
  • Creating a greater context for the work of employees.
  • Fighting fires and doing drudgery without becoming a bottleneck.
  • A thousand other things that don’t make good motivational posters.

You work on these things every day. It’s slow and painful. There’s no secret algorithm or technique. You could take all of these cute little quotes about how to be a good boss, and it’d cover maybe 1% of what actually goes into being a good boss.

5 Comments

The low status of software engineers

21/08/2014

A couple weeks ago I read an article by Michael Church titled “How the Other Half Works: an Adventure in the Low Status of Software Engineers“. It is the story of Bill, who had two very different experiences interviewing for two different positions at two different companies: one as a software engineer, and one as a VP-level manager. Bill’s experience is as you would expect from the title. The article is well worth reading.

It was difficult to process the article’s conclusions, because my interview experiences have not been like Bill’s. In fact, in some cases it has been the opposite. I once interviewed for a management-level position that I was woefully unqualified for. Once it was clear I wasn’t the person for the job, they changed the day’s schedule to allow some engineers to unnecessarily hammer me with technical questions. Likewise, I recently interviewed for a software engineer position at a healthcare company with a very small programming team, yet was treated extremely respectfully by everyone, including the CEO. Furthermore, I know I am not guilty of holding software engineers in low status, as anyone I have worked with will tell you.

A few days later, after thinking about the article some more, I started to get some flashbacks*.

I wanted to make changes to scrum teams, consolidating several smaller teams into fewer larger teams. I was told “if we do this, it must be secret. We cannot discuss team composition with developers. They just gossip and act like children.

I was discussing systematic problems with management structure with a sympathetic senior manager. I was told “I once put forward a proposal that employees should choose their own managers. I was laughed out of the room.

We were considering two senior developers for a second Technical Director position. I was told “you must leave this to me to handle, we do not want them to know the other is being considered.” Of course they were good friends, and eventually made the decision themselves.

I raised an objection to a workflow a tools team had put together, concerned it put a large and unnecessary burden on content creators. I was told, “if they don’t want to deal with it, they don’t need to work here.

A team griped frequently about their tools, which were both essential and horrific. Management felt they weren’t sufficiently appreciative when any minor fixes were made. Instead of fixing the tools, they and I were told “there will be no more discussion of these issues, except as initiated by management.

Until now, I thought of these events as incredibly stupid decisions made by unqualified and disconnected individuals. Unfortunately, that’s not the case. These are incredibly predictable decisions made by normal individuals who are produced by a totally unsurprising system. Once the engineers are no longer running the show, they are quick to lose social status. Engineers remaining in management will be assimilated, demoted, or their position removed entirely. There’s no way to reverse this, and I think it’s why culture can so quickly spiral from enjoyable to miserable.

Finally, it’s also interesting to think about this in the context of the Silicon Valley “anti poaching” conspiracy which depressed employee salaries. It demonstrates the systematically low status of software engineers better than anything. Management at Apple, Google, Adobe, Intel, and more, saw engineers as mere pawns, while simultaneously acknowledging how vital they were to the success of those companies. What a world!


* If you’ve worked with me before, you can probably guess who some of these nameless individuals are. I have not obfuscated things for the sake of protecting the innocent, because I don’t find these shitty managers innocent.

1 Comment

A short letter to a unit testing newcomer

18/08/2014

One of my friends asked how to get started with unit testing and Test Driven Development and figured I could write a short post. I also mention TDD a few times in my book so I think it could use some more attention.

I got started with unit testing when I wrote a smallish Python project, and realized I couldn’t maintain large Python projects without tests*. So I wrote unit tests for my code. I then quickly got into TDD. I don’t remember what resources I used, but there are plenty.

I’d encourage you to start unit testing by writing your code first, then the tests. As soon as this becomes easy and is paying off, start writing the tests first (TDD). You will come to appreciate that this is a powerful way of thinking and working. Even if you don’t ultimately stick with this approach, it is worth becoming skilled with it. You will uncover many suboptimal areas in your coding process that are otherwise extremely difficult to find and fix.

Keep in mind that learning TDD isn’t like already knowing Mercurial, then reading a book about Git**, and then being skilled with Git because you are skilled with Mercurial. You are embarking on a long journey, and will need to refer to many tutorials, blogs, and books. You will do some TDD, and look back on that code and process in a year and be horrified, just like you were when you started programming. Do not think of unit testing and TDD like learning a new framework or library. Think of it like learning how to program all over again.

So I don’t know exactly where to get started, only that you must, and keep going once you do start.


* I’d soon realize that no project was really maintainable without tests.

** Pro Git is my favorite Git book, by the way.

1 Comment

You must manage what you can’t measure

8/08/2014

We all know the quote:

You can’t manage what you can’t measure.

The quote is often incorrectly attributed to W. Edwards Deming. Thank goodness, because that sentiment is absolutely ridiculous, and Deming is one of my heroes. In fact, a more accurate Deming quote is:

The most important figures that one needs for management are unknown or unknowable… but successful management must nevertheless take account of them.

It’s very important to understand how absurd the “can’t manage what you can’t measure” idea is. It leads to articles like this:

It is an old management adage that is accurate today. Unless you measure something you don’t know if it is getting better or worse.

No, it wasn’t accurate when Peter Drucker promoted it, and it isn’t accurate today. This quote is so counter intuitive, I’m not sure it became popular. Are your managers idiots? Are your employees automatons? Do you believe you can measure everything about your business? That the more you measure, the more successful you will be?

If you want to truly engage with employees as empowered and creative individuals, you must manage what you can’t measure. If you want to create a learning organization optimized for long-term health, you must manage what you can’t measure. To forget this is to engage in one of the great sins of management.

An absolutely wonderful book on this topic is Measuring and Managing Performance in Organizations. I really encourage anyone who believes that measurement is a prerequisite for management read it. It explains, with anecdotes, statistics, and logic, how depending on measurement will lead to deep organizational problems.

1 Comment

Code separators and headers are more than a matter of style

4/08/2014

IDontCareIfYouPreferPascalCase, ifCamelCaseIsForYou, or_if_you_prefer_lowercase_underscores. They all have their merits. However, there is one element of many style guides that I have come to vehemently disagree with: function/class headers* and separators. I bring it up because I’ve encountered them in pretty much every codebase I’ve worked with, but never found it difficult to convince people to stop using them.

Many people have the belief that there’s no inherent superiority between having and not having headers and separators. Separators vs. no separators is like PascalCase vs. camelCase. “It’s just the way it is, follow the guide, be consistent.”

It’s a reasonable opinion, but wrong.

Headers and separators are more like the comments that say #Open the file directly above the line that says with open(somepath) as f. Or more likely, a comment that says #Don't write the file yet above the line that says requests.get(someurl). Wait, what does that comment refer to? No idea, because someone edited the code but not the comment.

We’ve known these sorts of comments are harmful for a long time. They involve out-of-band, redundant information that quickly rots. Having to create purely formal, redundant information (“a new function becomes here!”) is extra work that cannot be justified. Headers and separators are the same. “Added missing separator above function” is a commit message no one should ever have to write or read. Separators and headers are not a debate about readability. They are harmful because they are an impediment to changing code.

Please, if you use separators and headers, stop it immediately, or at least listen to the next jerk that comes in and wants to stop using them.


* : I am also against file headers, but I know they can be useful in some cases, such as when your code is mingled with client code and it can be important for people to know what code came from where. I can tolerate overhead that has a demonstrable benefit.

2 Comments

There is no essence of Agile

30/05/2014

real agile is: talk to the users directly, know their pain point, address it, repeat. -someone on Twitter who I disagree with

In many conversations about Agile, especially as of late, I read something like the above tweet. I don’t know where the idea that Agile can be distilled down into one or two practices or principles comes from. Thinking this way is extremely harmful. If you think like this, I’d love to hear your explanation.

Agile methodologies come out of Lean thinking which comes out of the Toyota Production System (TPS). The TPS is incredible. It mixes explicit practices such as 5S, ideals such as JIT, and principles such as “respect for people” into a unified, harmonious way. TPS is often represented using a house metaphor as in the following image:

house-of-lean1

The house is an apt metaphor because every single component is structurally vital. “Talking to users” and “addressing pain points” corresponds pretty closely to “customer satisfaction,” which is the roof of the TPS house. The roof is elevated by the walls, which are secured by the foundation. The roof is integral to the function of a house, but no more so than any other component. Customers can only help inform what you produce. If you are unable to produce those things at high quality, speed, and efficiency, and improve over time, then it doesn’t matter how much you talk to customers.

Adding an Andon cord to an assembly line does not make a manufacturer Lean. Being Lean requires a whole set of practices, ideals, and principles working in unison. It can be TPS, or your adaptation, but it requires incredible rigor, skill, and learning, and it’s not simple. Likewise, no single practice, from TDD to iterations to talking to users, creates a well-performing Agile organization.

There are plenty of pseudo-Lean companies, just like there are plenty of pseudo-Agile shops. On the plus side, the damage from Six Sigma Black Belts is far more severe than the Certified Scrum Master racket.

Companies that are Lean are rare, and have been at it for a while. It’s silly that every JIRA jockey thinks they have learned the essence of Agile. Being Agile is difficult, complicated, and takes a while. Let’s not try and distill it down so much that we totally dilute it.

5 Comments