A short letter to a unit testing newcomer

by Rob Galanakis on 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

A manager’s primary job is to build trust

by Rob Galanakis on 14/08/2014

While interviewing for my new position at Cozy, I was repeatedly asked what the job of an Engineering Manager is.* By the end of the day, I had decided (for myself, anyway) that the most important job of an Engineering Manager** is building trust.

  • Senior engineers must trust you. They can succeed without you, but you can’t succeed without them. Why does your job exist? It isn’t enough for you to trust them; that’s a prerequisite. If you don’t trust them, that needs to be rectified first. If they do not vehemently trust you, your role is not just worthless, but a net negative.

  • Junior engineers must trust you. They need to have a reason to stick around. They must trust that you are giving them opportunities, and they don’t need to leave to be treated better. They need to trust that they are learning, growing, advancing. Finally, they need to believe that if and when they leave to see what else the world has to offer, they will be welcomed back. If junior engineers do not trust you, they will leave, and take their ideas and passion with them.

  • Design must trust you. They must believe you when you present estimates or assessments from engineers. They must believe that they are getting good information from you, and you aren’t an out of touch middle manager. They must see continuous improvement and engagement from the engineers. They need to trust that you and the engineers are working towards the same goals as they are, with fire and passion. If design does not trust you, you are damaging engineers and company and should just get out of the way.

  • Management must trust you. This is generally an easy one, because if they don’t trust you, they should fix it or remove you.

  • Finally, one that cuts across roles: malcontents and metathinkers must trust you. Many people (especially engineers) just want to avoid politics and are happy to work on on their tasks and not ask questions. As long as you don’t actively screw up, these people will usually trust you. Much more difficult are the critics. They come in all shapes and sizes. It’s not that they need to agree with you, but they do need to trust you. These people often have big ideas and cultural influence. Distrust will drain your organization of talent. As a member of this category, I take this very seriously. When I’ve actively distrusted management, and subsequently left, there’s been a flight of talent afterwards as problems get worse. I’ve written about the importance of the malcontents on this blog before, and as a manager it’s always been a yardstick. If malcontents and metathinkers are leaving, something is going very wrong.

Trust is probably the most important metric for whether you’re doing a good job and your organization is healthy. It is a product of some actions, and a foundation of others. If it’s going up, your organization is getting stronger. If it’s going down, you need to get to work.


* I really enjoy interviews, especially in-person interviews, because it really helps me clarify my beliefs. This can lead to a high bounce-rate, but generally I’m left with culturally compatible companies after that. I consider this a benefit but YMMV.
** Any manager, really.

6 Comments

“Do you expect too much from people?”

by Rob Galanakis on 11/08/2014

Last year, a coworker asked me if perhaps I expect too much from other people. I thought about it a moment and said:

No. I do not accept the argument that I’m somehow inherently superior to most others. In fact it is because I know I am not superior that I have high expectations of others.

In the intervening year, I’ve come to see that this belief drives a lot of my management philosophy. In general, I assume the best of people I work with. If someone is not performing, I do not blame them; I blame myself (or whoever their manager is) and systematic problems that they are not in control of (but hopefully ones I am).

Of course people have different innate abilities and experiences. Some people have a high aptitude for certain types of work, and some have chosen a path that may not be a good fit. But the realities of business are that these things can quickly change, and an asset one day can be a liability the next. When a company has grown past a dozen people, I believe its time to start favoring nurture over nature. If someone isn’t performing, it is management’s problem.

This is true of not just employees, but other managers, and it was specifically about two other managers that this question was posed. The times were a-changin’, but these individuals were in roles they were ill suited for. They simply did not have the experience or competence to drive through the changes that needed to happen. It was up to their (our) management to take responsibility, but instead I heard apologies that “maybe they aren’t the best suited” and other meaningless explanations. I didn’t expect them to magically change; I expected management to do their job: get involved and well, manage!

If I expect something, it’s that people can both teach and learn. If the ability of people to grow is not an organization’s chief expectation- if management is not set up to grow employees, or management is not prepared to mature itself- I can’t imagine what they think their long-term prospects are. Perhaps they aren’t expecting much.

No Comments

You must manage what you can’t measure

by Rob Galanakis on 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

Portland, here we come!

by Rob Galanakis on 6/08/2014

Tomorrow, my family leaves on a four day trip to begin a new life in Portland, OR, as the Engineering Manager at real-estate startup www.cozy.co. I am incredibly excited to join the company for all sorts of reasons (the role, product, team, founders, location, pretty much everything). It’ll also allow me to focus on what I’m most passionate about: engineering and development management. So there should be fertile topics for new blog posts, though I suspect the purely engineering or Python-centric posts will get fewer (except for goless, which I plan to maintain).

Now for the heavy stuff. In addition to a new chapter opening, several chapters are finally closing. Since deciding to leave Iceland earlier this year, life has been a depressing adventure. After a promising start at CCP Atlanta, the studio was shut down. This caused us to become homeless. We were 2 days from closing on a house (for which we lost a very large amount of earnest money). So a few days later we drove to Austin and moved in with my in-laws for about 2 months. I found a new job at The Foundry, but I ended up not enjoying working remotely. I was looking for a new job just a few weeks after starting (the job was just for a 3 month contract so they were aware I was looking). We left my in-laws mid-June and moved into their lake house, which I describe as 30 minutes outside of nowhere (over an hour into Austin). We haven’t had running water for weeks due to pump-house problems. My wife and son have gotten cabin fever, unable to make friends with a culture we don’t seem very compatible with. I haven’t been able to give a concise answer to “where I live” or “where I work” since March. Moving costs keep building. My son is behind on his vaccinations due to moving around. It’s been the most difficult time of our lives.

And oh my god is it hot outside.

So here’s to a new job, a new city, a new start. See you on the other side!

10 Comments

Code separators and headers are more than a matter of style

by Rob Galanakis on 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

Everyone should take vacation at the same time

by Rob Galanakis on 31/07/2014

Throughout my career I’ve always seen people struggle with taking vacation. People are too wrapped up in what they’re doing. Managers can’t allow critical people to go missing. There are weeks of trepidation and handover and “I don’t know how to fix that” emails. To a large extent, this can be fixed with shared code ownership, comprehensive automated testing, and all those types of good development practices. I have a better idea, which I saw in great use at CCP (which for a long time did not have those good development practices):

Everyone vacations at the same time.

In Iceland, this was a cultural thing. From what I understand, employers aren’t allowed to deny you vacation between May and September. Everyone goes on vacation in July. The office is empty. Things just go relatively smoothly as no one expects anything to get done during July (its a great time for side projects). This “July slowdown” wasn’t limited to CCP, as people who need visa renewals in the summer no doubt learn.

In Atlanta, the studio just closed down for two weeks in July.

In both cases, there may be a skeleton crew to keep things running, people on call, etc. Its just that no one expects anything non-immediate to get done. This has many benefits: its easier to plan for, office costs are cheaper, there’s a single silent period rather than months of rolling disruption, everyone takes a refreshing vacation, and much more. It’s pretty much the only vacation policy I’ve seen that was largely resilient to the pressures that keep people from taking vacation. To be sure, some people were screwed over by bad managers, but (in contrast to most other management offenses) this was largely due to particular managers and not underlying cultural causes.

If you see the people around you failing to take the proper vacations everyone needs to keep going, I’d encourage you to try having everyone go on vacation at the same time.

6 Comments

Practical Maya Programming with Python is Published

by Rob Galanakis on 28/07/2014

My book, Practical Maya Programming with Python has been finally published! Please check it out and tell me what you think. I hope you will find it sufficiently-but-not-overly opinionated :) It is about as personal as a technical book can get, being distilled from years of mentoring many technical artists and programmers, which is a very intimate experience. It also grows from my belief and observation that becoming a better programmer will, due to all sorts of indirect benefits, help make you a better person.

If you are using Python as a scripting language in a larger application- a game engine, productivity software, 3D software, even a monolithic codebase that no longer feels like Python- there’s a lot of relevant material here about turning those environments into more standard and traditional Python development environments, which give you better tools and velocity. The Maya knowledge required is minimal for much of the book. Wrapping a procedural undo system with context managers or decorators is universal. A short quote from the Preface:

This book is not a reference. It is not a cookbook, and it is not a comprehensive guide to Maya’s Python API. It is a book that will teach you how to write better Python code for use inside of Maya. It will unearth interesting ways of using Maya and Python to create amazing things that wouldn’t be possible otherwise. While there is plenty of code in this book that I encourage you to copy and adapt, this book is not about providing recipes. It is a book to teach skills and enable.

Finally, to those who pre-ordered, I’m truly sorry for all the delays. They’re unacceptable. I hope you’ll buy and enjoy the book anyway. At least I now have a real-world education on the perils of working with the wrong publisher, and won’t be making that same mistake again.

Thanks and happy reading!
Rob Galanakis

5 Comments

goless 0.7 released, with Python3 support and bug fixes

by Rob Galanakis on 25/07/2014

goless version 0.7.0 is out on PyPI. goless facilitates writing Go language style concurrent programs in Python, including functionality for channels, select, and goroutines.

I forgot to blog about 0.6 at the start of July, which brought Python 3.3 and 3.4 support to goless (#17). I will support pypy3 as soon as Travis supports it.

Version 0.7 includes:
– A “fix” for a gevent problem on Windows (socket must be imported!). #28
– Errors in the case of a deadlock will be more informative. For example, if the last greenlet/tasklet tries to do a blocking send or recv, a DeadlockError will be raised, instead of the underlying error being raised. #25
– goless now has a small exception hierarchy instead of exposing the underlying errors.
– Better PyPy stackless support. #29
goless.select can be called with (case1, case2, case3), etc., in addition to a list of cases (ie, ([case1, case2, case3])). #22

Thanks to Michael Az for several contributions to this release.

Happy concurrent programming!

No Comments

goless now on PyPI

by Rob Galanakis on 12/06/2014

goless is now available on the Python Package Index: https://pypi.python.org/pypi/goless . You can do pip install goless and get Go-like primitives to use in Python, that runs atop gevent, PyPy, or Stackless Python. You can write code like:

channel = goless.chan()

def goroutine():
    while True:
        value = channel.recv()
        channel.send(value ** 2)
goless.go(goroutine)

for i in xrange(2, 5):
    channel.send(i)
    squared = channel.recv()
    print('%s squared is %s' % (i, squared))

# Output:
# 2 squared is 4
# 3 squared is 9
# 4 squared is 16

I’ve also ported the goless benchmarks to Go, for some basic comparisons to using goless on various Python runtimes (PyPy, CPython) and backends (gevent, stackless): https://goless.readthedocs.org/en/latest/#a-benchmarks

Thanks to Rui Carmo we have more extensive examples of how to use goless (but if you’ve done or read any Go, it should be relatively straightforward). Check them out in the examples folder: https://github.com/rgalanakis/goless/tree/master/examples

And just a compatibility note (which is covered in the docs, and explained in the exception you get if you try to use goless without stackless or gevent available): goless works out of the box with PyPy (using stackless.py in its stdlib) and Stackless Python. It works seamlessly with gevent and CPython 2.7. It works with PyPy and gevent if you use the tip of gevent and PyPy 2.2+. It will support Python 3 as soon as gevent does.

Thanks and if you use goless, I’m eager to hear your feedback!

No Comments