Archive of articles classified as' "quotes"

Back home

Hire talented people and get out of their way?


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.


GeoCities and the Qt Designer


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.


The low status of software engineers


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

“Do you expect too much from people?”


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


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

There is no essence of Agile


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:


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.


Deploying a C# app through pip


“If we bundle up this C# application inside of a Python package archive we can deploy it through our internal CheeseShop server with very little work.”

That sentence got me a lot of WTF’s and resulted in one of the worst abuses of any system I’ve ever committed.

We had a C# service that would run locally and provide an HTTP REST API for huge amounts of data in our database that was difficult to work with.* However, we had no good way to deploy a C# application, but we needed to get this out to users so people could start building tools against it.
I refused to deploy it by running it out of source control. That is how we used to do stuff and it caused endless problems. I also refused bottlenecks like IT deploying new versions through Software Center.

So in an afternoon, I wrote up a Python package for building the C# app, packaging it into a source distribution, and uploading to our Cheese Shop. The package also had functions for starting the packaged C# executable from the installed distribution. The package then became a requirement like anything else and was added to a requirements.txt file that was installed via pip.

What I initially thought was an unsightly hack ended up being perfect for our needs. In fact it caused us to eliminate a number of excessive future plans we had around distribution. I certainly wouldn’t recommend this “technique” for anything more than early internal distribution, but that’s what we needed and that’s what it did so effectively.

Getting something up and running early was extremely useful. It’s important to walk the line between the “we need to do several weeks of work before you see any result” and “I can hack something together we’re going to regret later,” especially for infrastructure and platform work. If code is well-written, tested, documented, and explained, you shouldn’t have qualms about it going into (internal) production. If the hackiness is hidden from clients, it can be easily removed when the time comes.

* Reworking the data was not an option. Creating this service would have allowed us to eventually rework the data, by providing an abstraction, though.


The myth of the brilliant jerk


Do not tolerate brilliant jerks. The cost to teamwork is too high. – Reed Hastings, Netflix CEO

So I was all prepared to write about how much I hate this quote, but Freddy Nager already did. It is thorough and insightful and explains how out of context this quote is. Thanks to Freddy for doing a far better job ripping this apart than I did. (It also reminds me the difference between real writers/bloggers and people who just have a blog, like me…) Here’s his conclusion, but I suggest you read the whole thing:

In short, Netflix wants only stars who are passionate and courageous and innovative and always do A-level work while abhorring process and questioning assumptions yet working as a team — otherwise they get fired. Sounds brilliant. And jerky.

Why is the Hastings quote so popular? The Netflix presentation is a really excellent one and full of interesting advice and strong statements. I’d even say the brilliant jerk of corporate culture presentations! Why does this quip about “brilliant jerks” resonate with people so much? Probably because we’ve all run into the “brilliant jerk” and the idea of just firing him or her is so pleasing. It also remains cowardly.

This hits particularly close to home for me because I have seen the mistreatment of far too many brilliant jerks. Brilliant jerks are necessary to grow and innovate. The difficult part is to figure out how they can be brilliant but be less jerky.

Firing brilliant jerks is the absolute worst thing to do for teamwork, or indeed the health of the company as a whole. I could spend more time convincing you, or you could view the Netflix slideshow that spawned the quote!


Results are not the point, followup


In response to a previous post explaining the phrase “Results are not the point“, commenter RenRen Gabás says:

Both approaches have their own place. It’s easy to see why Toyota/Lean works well with manufacturing and operations. Continuous service and operations needs continual improvements. However, there are times when you need to forget all about process and workflow in order to break new ground. I would place breakthroughs in research and product development right in the Danny category.

Unfortunately, history (and logic) shows that Jess (continuous improvement) is still going to out-innovate Danny (gets drunk and makes stuff) and come up with far more breakthroughs.

  • Exhibit A: The Prius (first successful hybrid car) and Lexus (Toyota’s first luxury line) demonstrate that continuous improvement is not limited to operations. These were successes of product development and marketing.
  • Exhibit B: Google, a company filled with innovation, research, products, and big ideas, is also a world leader in analytics and iteration! Who do you think their process most closely resembles?

Do not confuse the stifling bureaucracy of a large company to embody Jess, and the creative chaos of a startup to embody Danny. This is a fallacy. Large companies are more stifling, and startups are more creative. But this is due to intrinsic properties, not continuous improvement.

Another way of saying “results are not the point” is “do not trust your fortune to randomness.” I don’t know anyone who would disagree with that! Yet when we take the Danny approach, that is exactly what we are doing, no matter the nature of what we are working on.

1 Comment

An Unfoolish Consistency: Introducing PEP8 to a legacy codebase


Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

The EVE source code, being initially developed before PEP8 existed, was based on Microsoft’s C++ style. Mostly this is manifested in UpperCamelCase function and method names, mixedCase parameter and variable names, and file headers and class/method delimiters. There was also a style guide that was probably larger than PEP8 (though included a bit more than basic style).

Today, most new code is PEP8 compliant. “What!?” I hear you say. “A foolish consistency is the hobgoblin of little minds!” I agree, and I’ll get back to that at the end. But first, what was involved in introducing PEP8?

The move started when I asked my team if anyone wanted to keep using the headers and delimiters. No one did. So we took out the headers and delimiters before we did any modifications to a file.

A while later, I asked all the programmers on the project if anyone felt strongly about keeping the existing style. No one did. So we started writing new packages with PEP8. The rationale was that our code was already calling code using lowercase_underscore in the stdlib, so it’d be no different for that same code to call a relatively independent, though still project-related, library.

Yet a while later, I started slipping some PEP8 code into modules or packages that weren’t PEP8. I was worried people would get upset. No one did.

And finally, in preparing some basic utility libraries for usage on other projects, I converted the function and method names to PEP8. This involved find-and-replace or CamelCase aliases. I bet you can guess who cared about these “superfluous” edits, or objected to the fact that parameter and variable names remained mixedCase? No one did.

Emerson’s quote “a foolish consistency is the hobgoblin of little minds” is often used as a reason to not change existing code to PEP8, or introduce it into a non-PEP8 codebase. But the quote means the opposite. Foolish consistency” is being unable to change your mind because it would contradict something you’ve believed or said. So PEP8 has it so right but so wrong: the foolish consistency is to keep things the way they are, even though we know what the right thing to do is.*

* I would recommend introducing PEP8 incrementally. I also suggest keeping things backwards compatible when it is more prudent, such as if the changes are expansive, or you do not control all the code. I also don’t suggest being a stylistic nitpicker when it comes to non-functional aspects such as line length. There may also be times to break the rules (a class that behaves like a function, or function that behaves like a class def). As always, good sense should be applied when considering any viewpoints on this blog.

No Comments