Archive of published articles by

Back home

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

Japanese vs. Western models of decision making

11/09/2014

I was reading a book about The Toyota Way last year (sorry, can’t remember which) and something that stuck with me was a section on Japanese versus Western decision making*. The diagram was something like this:

japanese-vs-western-decisionmaking

The crux of it is, Japanese companies like Toyota spend more time preparing for a decision, and less time executing. Western companies reach a decision earlier, and then execution has all sorts of problems. It’s also important to note that Japanese companies often reach the “end goal” sooner.

Preparation involves building consensus, but that doesn’t mean it’s all talk. Japanese companies pioneered set based design and prototyping, which allows them to try out a huge number of ideas cheaply. By the time a decision is made, they’ve “thrown out” about 90% of the work they’ve done!** However, once the decision is made the execution goes smoothly.

It is easy to see how Japanese decision making maps to businesses with a clear distinction between preparation/pre-production and execution/production, such as traditional manufacturing. It can be difficult to map to pure product development. Keep a few things in mind.

  • Consensus isn’t just discussion and design. Big-Design-Up-Front is not preparing for execution. BDUF is a woefully incomplete form of execution. Building consensus means actually implementing things in order to rapidly learn.

  • Consensus isn’t a democracy. Toyota has a very hierarchical structure and people have very clear responsibilities. The goal of consensus-based decisions is to make better decisions, not to achieve some Platonic ideal. Difficult decisions are still made, but the role of the executive is to manage the consensus-building process, rather than “just hurry up and making a decision.”

The Japanese model is built in to cross-functional teams. Consensus isn’t achieved by the heads of Engineering and QA signing some agreement in blood. If that agreement ends up not being a good idea- and it almost never is!- you end up with the Western execution experience. On the other hand, cross-functional teams have much more interactivity and iteration going on, and overall execution is much faster.

People will get upset. Take responsibility for your decisions, and acknowledge some people will get upset by them. However by making sure their concerns are thoroughly heard and discussed before execution, you will make sure they don’t keep pulling things off-track.

Anyway, there’s lots of good writing on this topic, and I highly suggest checking some of it out if it interests you. This is just my software development-centric take.


* I’m just calling these the Western and Japanese models of decision making. They are clearly not the way all decisions are reached in the respective countries. In fact these generalizations may not even be true anymore. Whether Japanese or American companies behave this way is irrelevant. The names are just proxies for different types of decision making.

** Obviously the work isn’t thrown out, since they’ve learned so much from it. But if the effort were raw materials, I suspect 90% of it would end up in the trash, depending on how a set is developed and culled.

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

Can you quantify trust?

4/09/2014

In a previous article, commenter Robert Kist asked:

How are you going to judge if people trust you – what would your indicators be, if you decide to treat it as a metric?

This is tricky. I don’t think there’s a good answer. Bad managers, who are by definition less trusted, can easily rationalize away any attempt at quantification. One quantifiable measure would be employee turnover. However turnover tends to be ignored in the aggregate, since the sample size is necessarily small. Individual departures are blamed on “incompatibility” or “burnout,” when it is without exception due to mismanagement.

Another potentially useful metric is the employee survey. This is an unequivocal disaster, because there are just endless ways to explain away poor ratings. I’ve heard bad ratings blamed on bad weather!

What about the venerable “360 review”, where your direct reports and peers give feedback? This would require some sort of survey, and we know how that goes.

In the end, bad managers will be able to rationalize away poor trust metrics. Unfortunately they are also universally unable to qualitatively identify a lack of trust. Good managers, on the other hand, intuitively know whether trust is getting better or worse. They should make sure there are many avenues of feedback to inform this intuition, but I’m not sure any are worth quantifying, if they are quantifiable in the first place.

Someone please tell me when I start to become a bad manager, please.

No Comments

Metaprogramming with the type function

1/09/2014

In my book, Practical Maya Programming with Python, I use Python’s type function for dynamically creating custom Maya nodes based on specifications, such as input and output attributes. I really love the type function*, so I thought I’d post another cool use of it.

I recently wrote this gem as a way to dynamically create exception types from error codes (it was for a now-defunct REST client):

def get_errtype(code):
    errtype = _errtype_cache.get(code)
    if errtype is None:
        errtype = type('Error%s' % code, (FrameworkError,), {})
        _errtype_cache[code] = errtype
    return errtype

Next is an uncommon form of Python's except statement. Its argument can be any expression that evaluates to a single exception type or sequence of exception types. You can actually call a function in the argument to except!

try:
    return framework.do_something()
except framework.catch(404):
    return None

The framework.catch function is below. It looks up (and potentially creates) error types based on the error codes being caught:

def catch(*codes):
    return [get_errtype(c) for c in codes]

This sort of utility is why I wrote the type of book I did. Learning how to program in Python instead of MEL is all well and good. But you need to really see what Python is capable of to make big strides. I hope that with a more advanced understanding of Python, 3D developers can start creating frameworks and libraries, just like PyMEL, that other developers will work with and on for many years to come.


* I love the type function for a vain reason. It's more obscure than decorators, but not as difficult to understand as metaclasses.

No 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

GeoCities and the Qt Designer

25/08/2014

In a review of my book, Practical Maya Programming with Python, reviewer W Boudville suggests my advice of avoiding the Qt Designer is backwards-looking and obsolete, such as writing assembler instead of C for better performance, or using a text file to design a circuit instead of a WYSIWYG editor. I am quite sure he (assuming it is a he) isn’t the only person with such reservations.

Unfortunately, the comparison is not at all fair. Here’s a more relevant allegory:

Hey, did you hear about this awesome thing called geocities? You can build a website by just dragging and dropping stuff, no programming required!

We’ve had WYSIWYG editors for the web for about two decades (or longer?), yet I’ve never run into a professional who works that way. I think WYSIWYG editors are great for people new to GUI programming or a GUI framework, or for mock-ups, but it’s much more effective to do production GUI work through code. Likewise, we’ve had visual programming systems for even longer, but we’ve not seen one that produces a result anyone would consider maintainable. Sure, we’ve had some luck creating state machine tools, but we are nowhere close for the more general purpose logic required in a UI. And even these state machine tools are only really useful when they have custom nodes written in code.

Finally, WYSIWYG editors can be useful in extremely verbose frameworks or languages. I wouldn’t want to use WinForms in C# without the Visual Studio Designer. Fortunately for Pythonistas, PySide and PyQt are not WinForms!

I have no doubt that at some point WYSIWYG editors will become useful for GUI programming. Perhaps it will require 3D displays or massively better libraries. I don’t know. But for today and the foreseeable future, I absolutely discourage the use of the Qt Designer for creating production GUIs with Python.

12 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