The unspoken assumptions behind scary phrases

There are certain phrases that developers use that mean something is underfoot that could jeopardize development schedules.

  • We want to make this dynamic so we don’t need to deploy code to change it.
  • The algorithm is not optimized, I’d like to take some time to optimize it.
  • When we were refactoring this component, it looks like it’s going to take longer than we think, and we’ll need to rewrite <x>.
  • The great thing about <technology x> is <feature that matters primarily to developers>.
  • We should use <framework x>, it’s the future. <Framework y> is dead. (examples: We should use React, Angular is dead (and vice versa)).
  • When we do <large thing x>, it will allow us to do <thing that business wants a short term solution for>. “If we move from SQL to a Document Database, we’ll be able to have faster queries in the future.”

All of these are perfectly normal things to say, in the right circumstances. But, all of them require business context and an understanding of business needs in order to be a “good idea”.

Here are those phrases with business context and developers assumptions built in:

  • “We want to make this dynamic so we don’t need to deploy code to change it, and we spend a lot of time deploying code for minor fixes. (The problem here is the deployment pipeline, and the assumption is they can’t fix the deployment pipeline or don’t know to, so they’ll change the code, because they understand that).”
  • “The algorithm is not optimized, I’d like to take some time to optimize it, because I believe it’s the most used algorithm and that shaving time off this business process will result in <value>”
  • “When we were refactoring this component, it looks like it’s going to take longer than we think, and we’ll need to rewrite <x>. We’ve known <x> has been a large problem for a while but we haven’t had the agency to fix it. We’re hoping you’ll let us because <x> is really bothering us and we believe it’s slowing us down from delivering <feature set y>, that you really want.”
  • The great thing about <technology x> is <feature that matters primarily to developers>. We don’t think it matters to you but we believe you may have ancillary benefit <y>.
  • We should use <framework x>, it’s the future. <Framework y> is dead. Framework X has been hard for us to adopt and we are having daily issues with it, and the public sentiment around <framework y> is better. We think it’ll solve these problems we’re having.
  • “If we move from SQL to a Document Database, we’ll be able to have faster queries in the future. We believe the business doesn’t need the ease of relational querying and since the customer doesn’t need reporting or querying, they just prefer to access business data directly by its key, we can move faster by not dealing with the relational database at all”.


In each, there are lots of unspoken assumptions about technology, the team, and the business direction whenever you hear one of these phrases. I’ve watched businesses chase their tail because these unspoken assumptions weren’t surfaced in time. Contrawise, with few exceptions, technology stack changes offer incremental improvement (if any) instead of evolutionary improvement. Act accordingly.

Junior vs. Senior Developers

Junior Developers are working on mastering the code, the structure, the system. They’re worried about whether they can even do the task they were assigned.

Senior developers are working on mastering the impact, the tradeoffs, and effectively communicating with business about issues and opportunities. They’re worried about whether they can effect the change the business wants.

Each segment will want to understand different aspects of the problem in detail. For Juniors, they really want a well specified problem. For seniors, they want a well specified goal and outcome.

Do the Short Film First

We know Pixar as the company behind Toy Story, but Toy Story wasn’t Pixar’s first film. Toy Story is perhaps its most memorable first feature film, but it wasn’t its first film. Pixar had five short films before releasing Toy Story in 1995. These shorts, although not revenue grossing themselves, were used to show off the technology behind Pixar, demonstrate their director’s ability to tell stories visually, and garnered experience for the Pixar team.

One of the continual Pixar traditions is to have up-and-coming directors to create a short film first and demonstrate that they can tell a story visually, and they still use Short films to show off new technology.

We tend to do things differently in software. It’s hard to get stakeholder buy-in for a small pilot first — something that ultimately may not even be folded into the project or product, but something that demonstrates either the technology, or the problem domain, or the team’s ability to build software together.

That learning and melding of a new team is critical to success. It’s not a stretch to say that without those five shorts, Toy Story wouldn’t have happened. If it took Pixar five short films to get their hit, what would it take for your team to hit a home run for your business?

You have a big idea and your team is working towards launching that big idea. Instead of trying to tackle the big hairy problems in that big idea, focus first on one of the smaller ancillary pieces. Your build pipeline, or a small web application that exposes a piece of it — whatever it takes to prove that your team can successfully launch the solution to that big and hairy problem.

How can you tell when a programmer is stuck?

There’s a famous quote, “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.”

As Homer might say, It’s funny because it’s true.

But how can you tell when a programmer is stuck on a problem?

One way is to pay attention to their behavior, and if anything is out of the ordinary for a day or two, then you know something’s up.

Another way is to scope all work such that they should be implementable in a day, and this certainly has the side effect of it being easy to tell when a programmer is stuck, it also has the unwanted side effect of putting more overhead into planning — not something anyone wants.

This is one of the areas where daily standups — properly used — can help. Weekly “status” meetings don’t invite the sort of conversation you need to uncover problems people are encountering, and normal daily standups reward papering over problems if you’re not in a high trust environment (if you are in a high trust environment people will likely tell you when they’re stuck — so before all else, think about how you can increase trust).

During a standup, most programmers aren’t going to say, “I’m stuck on X”, and it’s not because they’re afraid of getting in ‘trouble’, it’s because they don’t want to lose face in front of their peers. However, they will give hints that they’re having issues, and you can take that as an indication to follow up with them alone, away from their peers.

So how do you ask a programmer non-confrontationally if they’re stuck?

Try these:

“Hey, it looks like <that thing you’re working on> is a bit more involved than we initially thought; who do you think would be best able to help you make forward progress on this?”

“I can tell that you seem frustrated by what you’re working on. I get that. Hard problems have a way of being frustrating and draining. How can I help, or who can I enlist to help you get un-frustrated by this?”

Use your own terms of art; but there are three things you want to communicate when dealing with programmers:

1. Programming — even things we’ve done hundreds of times before — is hard. A minor update to a library can steal days worth of effort.
2. Because it’s hard, programmers aren’t to blame when things slow down. It’s either a combination of understanding, alignment of skill to the problem domain, or general difficulty of the problem domain. If you ask direct questions, “How do we unblock you?” You’re inadvertently challenging the competency of the programmer, even if you don’t mean to (a literal programmer might say, “I’m not blocked”, even though they’ve spent a week on something they thought would take a day, and a programmer that has an ego might think their peers would think less of them if they answered truthfully).
3. You’re there to quietly help them move forward. No fuss, no muss, no loud hullabaloo about their progress. You’re there to get them unstuck, without them feeling embarrassed by it.