Business Tech: Building MV Staff: Part III

Finding people who have no exposure to programming is becoming much less common. That doesn't mean they are well grounded in what they do know. As with databases, I'm going to start very simplistically, not because people are starting from zero, but because far too many people are starting from way down in the negatives.

The school of "but it works" has been producing vast herds of terrible coders in every language. So, I don't teach programming initially, I teach analysis. When people start from a position of "my job is for the problem to stop being a problem" instead of "my job is to personally code our way out of this hellscape-nightmare that every problem is" we get better employees.

Is It Right?

Go to a Ren Faire and look around. Colorful costumes, amusing performers, sure. But is it accurate? No, not really. It isn't an accurate representation of a time period. It is a facade designed to evoke a feeling. So, I guess Ren Faires are terrible?

No. They would be if exacting historical precision were the goal. Likewise, before we judge a business situation where MIS is required to solve the problem, we need context. We need to ask: What is the thing being accomplished?

I go to Ren Faires to have fun. I go to soak up a different sort of experience and be with people who have all agreed to suspend disbelieve to some degree. I don't fly into a rage when I find out the bathrooms available to us commoners have indoor plumbing. The fact that I'm allowed to drive there instead of hiking or going by drawn cart… also not offensive.

So my first avocation to a new employee is to understand the problem and the context before leaping in to save the day. Analysis is about doing the homework, not about doing the heroics.

If the goal is slaying the dragon, we may need to fire up the forge and make a better sword. If the goal is for the dragon to stop eating the sheep, we might have a vast array of solutions available that don't involve violence.

Ask Again, I Dare You

One of the first questions I teach people to ask is: What is the urgency? An answer of "not very" is not a conversation ender. Having a backlog of nice-to-do projects is worthwhile. Additionally, the part that Mary the A/R Clerk is asking about might be a lower priority while still being the tip of a bigger iceberg. Her not-a-rush might also be Joe in A/P's top issue. The person reporting it may not be the best arbiter of the need.

So, why ask it if we can't trust the answer? Several reasons. First off, it conveys respect in their expertise. Secondly, they are often correct. Perhaps more importantly, it is an equalizing question. If Mary demands I do something, she needs to take responsibility for it bumping other things. If Mary assigns it a lesser position on the queue, she cooperates with us in de-drama-ing the problem in question.

I don't discount someone saying the priority is high but I often disbelieve a claim of low priority.

Is This trip Really Necessary?

The next good question is something along the lines of: What if we just stop doing the entire thing where the problem shows up?

I'd rather show them a different report which has what they need rather than refactor the report they are using to work a little less worse. I'd rather find them a better way.

I can't understate how often the problem I'm asked to solve is a symptom of a solution someone else thought up. If you can get to the root issue, often you can do less work and create more success.

To be clear: This is a problem caused by people trying to do the right thing. They didn't just dump their problem on us, they tried to work out a solution. Most of these stage-two issues come from the homebrew solution failing, combined with the person being emotionally invested in the current path. It is their idea, their contribution. Respect that.

Remember When You Were Six?

You'll notice that I have barely said anything technical at all so far. Analysis has very little to do with technology. Computers, all of tech, is just one possible route to a solution. Analysis is about people and their expectations. Being an analyst is a human-to-human skill, not a coding skill.

Some people are stuck in a loop. They have a limited approach and they enact it over and over, even when it stops working. Even when it never really worked. Our job as analysts is to help them get at least an inch past their pattern so that better solutions can be found.

Likewise, it is easy for us to get stuck in other people's opinions. If everyone says Joe is a whiner, dismissing Joe's complaints becomes easy. Now, Joe might be. Or, based on how he is treated, he whines but would respond differently to a smidgen of respect.

If we don't want people to endlessly re-enact their past behavior, we need to see them as more than that behavior. There was a sitcom where one of the kids is going back through their report cards and realizes that each teacher started with assumptions based on how the teacher before them had seen the student… the notes in the file. The question became: Am I in an Honors Program because I impressed my Kindergarten teacher with the symmetry of my mud pies?

The brilliant employee sitting before you can give you inaccurate details. The put-upon drudge in the back office might have their finger on the pulse of this particular crisis. Don't judge people on who they were when they were six.

Teaching That

Respect and empathy are the real lesson. People at ease are more likely to give you more complete information. They are more likely to go along with your systemic, step-by-step approach. And nothing puts people more at ease than being treated decently. Are some people immune? Are some people just terrible? Yep. But I tend to attract better people and better nature from not-better people with this approach. I teach decency both because it is morally right and because it is pragmatically better.

Negative Review: Zero Stars

People who know me know that I don't think programming should be a job. Not what you expected to hear in a business article in a tech publication, but there it is. I believe that coding — coding brilliantly — should be part of the analysts job. Separating problem, and interpersonal analysis, from coding is a bad path.

is a bad path. Banging on keys to create more lines to maintain is not the best plan. I won't debate if it was ever a good idea in the past, but today, no. Just, no. We have low-code solutions. We have no-code solutions. We have non-tech solutions. Can technology, coding specifically, be the right answer? Frequently. Should it be done by people who didn't go to the meeting and are isolated from the people who will have to live with their solutions? I'll give that a firm no.

And yes, programming is a muscle. We should generate metric tons of code early in our career to develop that muscle. We should periodically do it throughout our career to maintain and build that muscle. That doesn't mean that code should all end up in production.

Nathan has raised this flag periodically: If you only code at work and to-task you aren't really improving yourself. Musicians don't only play at the concert. They do the work at home. They try things out alone or with their team. We need to acknowledge that and act on it.

I certainly haven't presented you with a master class on analysis here. I've touched on a few things that should be part of any new programmer training. Next issue, we'll start the coding part. Please don't skip over this article in your rush to get them to the next one. There are already enough bad programmers in the world.

Featured:

Jan/Feb 2020