Metaprogramming with the type function

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

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

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

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

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