career

Show, don’t tell

During my first few years working in software, I had the opportunity to work with a mentor who had the best approach to introducing new ideas that I’ve seen. The best way I can sum up the approach would be “Show, don’t tell. And don’t be a jerk.”

To give some more context, we worked in an organization where change was widely viewed as something to be feared, rather than something to be embraced. Ideas for change were often met with resistance, especially by management.

The primary way that he worked his magic was through small experiments – with the bulk of the work done on his own time. If there was something that he viewed needed to be changed, he would take a small slice of that problem, and apply the new idea to it. It might not solve the whole problem, but it showed the path toward it. For example, if we had a problem with triaging production issues from messy logs, he might take a crack at changing the styling of alert emails that got sent out to be cleaner (this was before Splunk and other tools). But not everywhere, maybe just in one place on just one of our many applications.

Then, he’d show it to the team to see what they thought. He did this without explicitly  selling the idea – just stating the facts and showing off a working example. Seeing the idea actually working, the team would often embrace it. We also had a working template to start from, should we decide to pursue it. This was a seed that he planted, and if the team decided to nurture it, that idea would grow a life of it’s own with just a little bit of initial effort.

What didn’t happen? Talking about the idea for change before starting. You didn’t hear “I think we need to change X to Y because…” followed by an hour of debate.

I’m guilty of doing this, and it doesn’t work. Talking about an idea for significant change, without action, dooms it from the start. Imaginations run wild and what-if scenarios scurry about like frightened mice. All the time wasted pontificating could be spent doing a small experiment to see if the idea really works.

If you do a change experiment simply, and test it cheaply, chances are you have a lot less to lose than a meeting where the whole team talks for an hour. Paradoxically: if the idea is complex and hard to start on, sometims the best, cheapest experiment to run is a thought experiment and asking people what they think. You have to use good judgement, but avoid the dangers of the hour long debate!

We also can’t forget that people sometimes are apprehensive of change in a team. They’re comfortable working the way they already work. Why would they change? But if you have visible progress on that something works, instead of just words, it’s hard to be afraid of or argue with. Also, don’t forget to hear them out. Why are they resistant? Simply letting people talk through their feelings goes a long way to helping both you and them understand the new idea. They may have very good reasons for feeling as they do.

You have to be prepared for this strategy to fail. You will have ideas that are great and your team just isn’t ready for. Or, you will have terrible ideas that are rejected for good reasons. You cannot get defensive if these experiments do not pan out. You cannot under any circumstances get upset if those ideas are not embraced immediately. If they aren’t, try again, softly, with a slightly different experiment.

Many of us in software work with Agile processes, quickly iterating over software features until we hit on what our users want. Think of changing an organization the same way. If it doesn’t work the first time, what can you do better? Was it a problem with your idea, or was it just not communicated successfully? Was your example too small, so that it didn’t really present the power of your idea?

Above all: Don’t be a jerk. Lasting change on a team requires buyin, and that doesn’t happen if you’re not empathetic.

So go out there, do good work and plant some seeds for change in your team.

Ask “Why?” to Make Better Software

As a coder, it can be easy to get mired in details. Our job is to manage the details of a business in code. And with the best of intentions, we may even create more details for ourselves through our designs and technology choices.

Worrying about so many little things, it’s easy to lose sight of why we’re putting fingers to the keyboard in the first place. Asking a simple question: “Why?” can help you rise above all the details to see the forest through the trees and make better software.

Technology First?

When assigned a task or project, many times my first reaction is to think of which technology is most appropriate to complete the task, and then quickly after that, start formulating how I would code it.

The technology is the fun part! And it’s our job, right? Well, yes and yes, but immediately jumping into a technical solution is a guaranteed way to make things more complex than they need to be.

And while you’re making things more complex for you and your team, you might be hurting your customers by not delivering what they really need or want.

Next time you get a project, instead of opening up an editor, or Googling, or drawing a diagram, first ask “Why am I solving this problem?”

Ask Around

If you don’t know why, ask the person who gave you the task. If they don’t give you a satisfactory answer: ask more questions. If they still can’t answer your question, and you can feasibly do so without getting fired, ask them who else can tell you why.

“My boss told me to.” is never an acceptable answer on your part or anyone else’s.

What is a good answer? I don’t know, stop asking questions! Just kidding. But, it should probably address one or more of the following:

  • A specific use case. For example: C-Level executives need this new report to make decisions about budget next year. Or: All users need to be able to save their login credentials in a cookie so they can save time each time they access the app.
  • Ease of operations. For example: Formatting log messages in XYZ format will allow the application support team to parse them easier and identify causes of bugs in logs quicker and make our customers happier.
  • Speed or quality of changes. For example: Writing an automated acceptance test suite will help us react better to customer needs by getting features out faster.

But ultimately, a good answer to “Why?” is one that makes sense to you and isn’t simply “It’s my job to write code” or “My boss asked me to.”

It is staggering how a simple “Why?” can halt people in their tracks and cause them to change their decisions, often for the better.

Especially on a team of seasoned people who have been with an organization for a long time, it’s good for someone to keep asking “Why?”. Chances are, there’s a bunch of people in the room with differing opinions, and the question will get them out in the open. Sometimes, it might even turn out that the task shouldn’t be done at all. Which is good, that frees you up focus on more important things. At the very least, you’ll probably dig up some serious “gotchas” about your task in the process.

Your Leaders Are Human

When you’re looking for answers, be patient and remember that the product owner/architect/supervisor/bossman/leader you’re asking is busy and he is human, just like you. He has lots of stuff he needs to get done, and sometimes he make mistakes and has lapses of judgement. Your job is to consult with him to get things done for a business. You can’t consult with him if you don’t fully understand why you’ve been assigned work.

If you don’t understand why, or he didn’t explain: Consider it part of your job to ask more questions. If he is at all a decent leader, he will take the time to explain the value of the bug you’re fixing or the enhancement you’re doing.

If your leader’s answer ends up being “because my boss told me to” and you can’t get any further then, well, it might be time to find a new organization. Unless, of course, you’re up for the task of managing upward, which is probably a good topic for another post!

Reducing Accidental Complexity

Earlier, I mentioned that we sometimes create unintended details through our everyday choices of technology and design. These unintended details are generally referred to as accidental complexity. This is opposed to essential complexity, which is solving the “real problem.”

Accidental complexity is part of our job and we can’t avoid it. But we can mitigate how much of it we create! Asking “Why?” helps.

When you ask why you’re doing something, the answer of “Because technology X needs technology Y” should be an immediate red flag that someone doesn’t fully understand the business problem at hand.

Writing code to solve a problem that other code created, or to solve a shortcoming of the AnguReactBerJS framework is not providing any value to the customers of your software. You are probably just creating more accidental complexity instead of solving a real business problem.

Asking “Why?” will help you focus on the simplest way to solve a real business problem instead of simply fixing technology. You might be able to bring your solution up a level to eliminate a technical issue or shortcoming altogether.

Sharpening Focus

Say you’re given the task to add a set of Automated Acceptance tests for your application. Do you know why you’ve been given that task?

Is it because we want to use SeleneCucumBybara, the latest, greatest testing framework? Probably not. Is it because we want to shield ourselves from creating bugs and allow us to be more flexible with the codebase so we can get features out quicker? Now you’re probably on to something.

Knowing “Why?” will help guide you through the immense pile of decisions you’re going to make when you start writing code. You’re probably going to make multiple decisions per line of code you write. You want your coding decisions to be made with the right values in mind. For instance, if you want to safeguard against a changing codebase, knowing this might help you target tests for the area of code which changes the most.

Knowing Where To Cut Corners

“Cutting Corners” is a phrase engineers hate, myself included. But in the reality of most business software development, a shipped product is better than a perfect product, so there’s going to be some paint dripped on the floor.

Asking “Why?” will help you know where it makes sense to spend less time polishing code and where a cut corner is acceptable.

For instance, if the answer to “Why?” is “We need to get this feature out fast so we have first mover advantage” (meaning time to market is important), maybe it’s more important to have a few solid end to end automated acceptance tests than it is to have good unit test coverage.

Or, if the answer is “This bug is causing customers to be charged $5 per order by mistake”, you probably want to spend more time writing tests for your code and less time polishing the front end.

Remember that the concepts of Technical Debt and Backlogs (in Agile) exist to help us make sense out of the imperfections we might create. These are ways for you to quantify your technical risk, track it, and hopefully address it later.

Systemic Problems

Does a problem happen often? Ask “Why?”. This will help you figure out if a problem is systemic. Fixing the cause of a systemic issue will save the team repeated effort which will allow everyone to focus on solving problems with more value.

Disregard Experience

If you’re new to software development, it might seem intimidating to ask such a simple question all the time. You might be afraid of seeming like you’re not good enough. But newbies are in a perfect spot to ask “Why?” A good team should have an understanding that a person new to software won’t know it all and needs some help. They should also come to realize that questions like these will help the whole team get a better understanding of what they’re doing and if it needs to change.

I think it can be harder for someone who has a lot of experience to ask a simple question like “Why?” all the time. With more years of experience come greater expectations on the part of others. This makes it more likely for a seasoned developer to perceive themselves, or possibly even be perceived, as being incompetent, even though they are anything but.

Regardless of your experience, it takes some courage to ask “Why?” Just keep on asking and feel dignified knowing that you’ll find better answers and do better work than those who don’t.

Show, don’t tell

During my first few years of working in software, I had the opportunity to work with a mentor who had quite possibly the best approach to introducing new ideas that I’ve ever seen. The best way I can sum up his approach would be “Show, don’t tell. And don’t be a jerk.”

To give some more context, we worked in an organization where change was widely viewed as something to be feared, rather than something to be embraced. Ideas for change were often met with resistance, especially by management.

The primary way that my mentor worked his magic was through small experiments. The bulk of the work done on his own time. If there was something that he viewed needed to be changed, he would take a small slice of that problem, and apply his idea to it.  It might not solve the whole problem, but he showed the path toward it.  For example, if we had a problem with triaging production issues from messy logs, he might take a crack at spiffing up the styling alert emails that got sent out (this was before Splunk and other tools).  But not everywhere, maybe just in one place on just one  of our many applications.

Then, he’d show it to the team to see what they thought.  Seeing a working example of his idea, the team would often embrace it. We also had a working template to start from, should we decide to pursue it. This was a seed that he planted, and if the team decided to nurture it, that idea would grow a life of it’s own with just a little bit of initial effort.

What didn’t he do? Talk about his idea for change before he started. You didn’t hear “I think we need to change X to Y because…”

I’m guilty of doing this, and it doesn’t work.  Talking about an idea significant change without action dooms it from the start. Imaginations run wild and what-if scenarios scurry about like frightened mice. All the time wasted during this pontificating could be spent doing a small experiment to see if the idea really works. If you do that experiment simply, and test it cheaply, chances are you have a lot less to lose than a meeting where the whole team talks for an hour.

We also can’t forget that people sometimes are apprehensive of change in a team. They’re comfortable working the way they already work. Why would they change? But if you have visible progress that something works, instead of just words, that’s hard to be afraid of or argue with. Also, don’t forget to hear them out. Why are they resistant? Sometimes simply letting people talk through their feelings goes a long way. And they may have very good reasons for feeling as they do.

You have to be prepared for this strategy to fail. You will have ideas that are great and your team just isn’t ready for. Or, you will have terrible ideas that are rejected for good reasons. You cannot get defensive if these experiments do not pan out. You cannot under any circumstances get upset if those ideas are not embraced immediately. If they aren’t, try again, softly, with a slightly different experiment.

Many of us in software work with Agile processes, quickly iterating over software features until we hit on what our users want. Think of changing an organization the same way. If it doesn’t work the first time, what can you do better? Was it a problem with your idea, or was it just not communicated successfully? Was your example too small, so that it didn’t really present the power of your idea?

Above all:  Don’t be a jerk. Lasting change on a team requires buyin, and that doesn’t happen if you’re not empathetic.

So go out there, do good work and plant some seeds for change in your team.