It’s that time of month again! Or rather, it’s one week later. But we’ll pretend it is the second Tuesday of the month, because that is T-SQL Tuesday day! The host for edition #163 is Gethyn Ellis (b|t), and he asks us to share the best career advice we have ever received.

Nineties

Let’s go back to the previous century. To the nineties, to be precise. I had been active as an IT professional for a few years already, but my lack of formal education held me back to get the promotions that I felt I deserved. And so, when I saw an advertisement for a very fast-paced course, guaranteeing an officially recognized diploma in just eighteen months, I signed up for it.

The key focus of the course was on database design. Or rather, on a very practical applied method of database design that was, and still is, very much unknown. But that, in my opinion, is a very good, strong, method, that has a much better chance of leading to a correct database design than most of the more popular methods.

However, this post is not about that method. It is about two elements that I learned as part of that method, as part of its foundation, and that have served me very well in all the years since, in all aspects of my job, and even outside of it.

The user is always right

This suggestion came as a bit of a surprise to me. I had already worked a few years as a programmer. And my experience, and that of my colleagues, was that, often, the user, or rather the person representing the user organization, often had no idea what our programs actually did. And that made us very suspect of many of their requested code changes.

And then the teacher of that course surprised me by claiming that, within our field of work, we should consider the user (or their representative) to be always right.

Now, that is of course a slight simplification of reality. Nobody is always right. Everybody makes mistakes. But there is a very important truth at the core of the statement that the user is always right. Because, yes, it is true that the developer know the intricacies of the code way better than any end user ever will. But the flip side is, that the end users know the reality of their day to day work endlessly better than any developer, designer, or architect ever will. They know exactly what they have to do every day. They have had angry customers on the phone. They experience the frustration of not being able to enter the details for a new customer, because the system thinks reality is not permitted. (“I assure you that my last name really is Von Gröningen” “I know, sir, but in our system the ö is not permitted, and neither are spaces in a last name. Can’t you supply a different last name? Oh, and it does have to match the last name on your passport”)

When a user (or representative, or client) makes a request that feels wrong, feel free to double check. Let them know that you have your doubts, and why you have your doubts. But if, after that, they still tell you that this request needs to be carried out, take them seriously.

Before I learned this lesson, I myself have been guilty, multiple times, of leaving old versions of program code as comments within the program. With a comment saying that it had been disabled or changed by user request, but I left it in, in case they changed their mind. Others did it the same way, and it felt right and proper, when I was convinced that the user was wrong. (Note that this was before version control systems existed, so there was no easy way to restore old versions).

But after getting this advice, I started to notice just how many of such comment blocks there were in our code. And in the code of other departments, when I had a chance to see their programs. And I realized that all those commented out code blocks would show up whenever an impact analysis was done. I myself have done impact analysis for a planned change, doing a hard search for a filename or field name to assess what programs would be impacted if we change that field, and finding lots of programs that have that field … in commented out code. And in many cases, that code was commented out many years before, by a developer who was sure that the user would change their mind. But they never did.

Every impact analysis was affected by those old, commented out, code blocks. And every time, a developer had to choose. Update the commented code as well, just so it would work after the field change, in case the users need it again? Keep it as is, with the risk that, if it ever gets restored, we forget to adjust for changes since it was commented? Or finally remove that multiple-years-old legacy from the past?

At that point I realized that this third option was the only correct answer. But even then, I still had a hard time convincing my colleagues!

Make the abstract concrete

As mentioned, the course I followed was for a large part devoted to a method of information analysis and data modelling that was extremely practical. A large part of the method was designed to cover the communication gap between IT professionals and end users.

Every professional has their own jargon. We, IT professionals, have ours. The end users have theirs. But they are not compatible. So how do you bridge that gap? I learned several tricks and methods to assist in just that. The method was so effective at teaching a data modeler to speak the jargon of the end users, that the students were even able to ask the correct questions and draw the correct conclusions when they were given an assignment with totally made up words. (“A company tracks information about flurgs. Most flurgs own two or more kerfuffles, but there are also kerfuffles that are not owned by any flurg.” And so on)

A second key point in the method I learned was to avoid abstractions at all cost. Most IT professionals have been trained their entire life to think in abstractions. They aren’t fazed by questions at that abstract level. But when talking to users, especially the end users, the field workers who will use the designed system on a daily basis, we are often talking with people who struggle with abstractions, especially when they get more complex.

Most IT professionals can rather easily parse a question such as: “Is it allowed for a parent and child to sign up on the family discount program, when the child is over 21 and lives at another address than the parent? And what about when just one of those conditions is true?”

But when I interview the desk clerk of the gym club in order to find out what constraints I should build into the data model, this question has a high potential to leave them glazy eyed. That not only affects their willingness to communicate and help, it also effects the credibility of their answers. How can you answer a question if you don’t understand the question to begin with?

But if I fill out a stack of membership application forms with fake (but realistic!) data, while ensuring each one tests for a case I need to test, and then ask the desk clerk to indicate whether they would accept or reject that application and why, I will very quickly learn that the actual rule is that the child must be under 21, and must live in the same city, but not necessarily the same address. And all that without ever requiring that the desk clerk adapts to my jargon, or adjusts their thought process to my level of abstraction.

And to be honest, even when communicating with other IT professionals, I have found that a few well-chosen examples often clarify a lot more than any amount of abstract descriptions.

Conclusion

When talking about complex subjects, increase the chance that everyone involved understands the topic, and understands it the same way, by making the abstract concrete. How? By using concrete examples, rather than abstractions. It may seem silly and childish at first, but you will avoid lots of miscommunications.

And when in doubt whether a user realty understands the implications of what they request, then of course feel free to point out those implications (in concrete terms, so with examples!). But then accept their final words. Sure, they might be wrong. But so might you. And between you and the user, chances are that the user understands the business and the messy reality they often have to deal with far better than you ever will!