Developer vs. non-developer, or how I learned to speak IT

This is a guest post by Jędrzej Paulus, host of Developer Wannabe podcast. Enjoy!I started my IT career in a company with many established specialists. In a short period, three new people have joined the team - Anna, Maciej and me.She is a programmer. She works in C# and does Microsoft Dynamics. Anna is the kindest soul. Together with Maciej we worked a bit differently than the rest of the team. We were more focused on the client-side, which fortunately does not preclude learning more development. We serviced incoming tickets. Something broke in the client’s system, the client wants a change here or there, some function needed to be added fast. We moved in then.For a couple of months, I witnessed how the transfer of information between developers works and what are the consequences. How are thoughts formed, what words are chosen, how fast is the information relayed? Like some old-fashioned self-help Instagram coach, I kept a notebook nearby every day. But keeping notes meant I was more aware and I got up to speed quicker. We started a project, we learned, we stumbled often. Many times I felt impostor syndrome hitting me, or I was just appalled how little I know. The system does not bite, they say - but some days I felt like I’d be wrestling a snake or a hedgehog.The experts sitting at the next desk caught my eye. How little they knew about how much they know! For all I cared - they had IT superpowers. Ninjas! Faced with a task, they just, well, sat down and made it happen. Out of the blue. Just like that. Many of those are real lifers, submerged in their field of expertise, doing side projects at home after they leave their work. Programming, and learning new aspects of it is natural for them.And this is where a crash with a non-dev happens. A bit like a car collision, or a meteor striking the Earth. We speak to someone who understands the job differently than you do. Example - I got information from a client, that some functionality does not work as required and needs to be modified. Even worse, final sales calculations are wrong and this could open the client to real, serious financial liability. So the programmer - well, I need to get what’s going on, how it started and what is the expectation.Another example, about Microsoft Dynamics system. A client’s tool. The system was configured for selling real estate. Sensitive data saved there - building specs, thousands of contracts, payment tracking, personal data. You need to keep it under control. Best things to do - understand that no programmer can easily manage this, so probably you won’t too.

But… what happened?

"Yeah, let's blame the Junior" - every Senior dev, probably[/caption]For an “IT consultant”, a typical day is a series of translations between the client and the dev team.A message arrives from a client. It’s a print screen. A bug must be resolved, ASAP. A large investment hinges on it. You repeat the steps as the client had done, a big, red ERROR message pops up. Don’t run away, even though you would love to. You see a more experienced colleague stiff up a bit.But panic is not an option, let’s try to deal with this stuff. If you are stressed, go get a coffee, some team, take a sip of water. Breathe. Breathe deeper! It ain’t easy, but you have to manage!The crash between the dev and non-dev worlds is hard. The non-technical person needs a way to understand the issue. The developer, on the other hand, needs to remember the curse of knowledge. The way the issue is explained may needlessly complicate the problem itself!

How to communicate with a Dev?

‍

Some say, that in the vast expanse of the Milky Way, there exists a developer without communication issues.[/caption]I think talking to a Dev should more or less go as follows.Make sure to communicate everything in a way that’s easy to understand. No extras, no emojis, go low on your “lolz” and insider jokes. No extra words, no long introduction.I found myself to be too poetic with my descriptions at the begging. It was an evolution, to cut down the extras from my event and ticket descriptions. Many times the descriptions muddled the waters enough that the problem was barely understandable. I mean, it is clear, that when writing an email to report an issue, you can at the very least attach screenshots of the thing…That is because, if you know what happened (even if you are still sweaty about the “why” question) you will be calmer and act more under control. And this is why… You HAVE to read bug reports carefully. The best thing my first mentor in my first IT job did was to remind me dozens of times about the mural we had in the office. It was something like, “Read the error messages, they are written for that reason!”. Usually, the key info is placed just behind the mass of weird numbers and letters. That info can be copied and googled (in parenthesis preferably). Maybe you can find a solution yourself.If you are a rookie programmer, keep in mind the experience gap between you and the others - they breathe it for years by now. Communicate! Especially, when…

...S**t goes bad!

‍

"It works well on my side"[/caption]We often call some infoline of our telecom carrier or technical support of some software. We are very bad at giving relevant information. “This doesn’t work”, “It does not show”, “something popped on a screen”. Without specifics, the message will be unclear, hard to understand. Both sides will now waste their time asking the basics, instead of specifics. And the same goes for the developer’s work.“Hey man, it's brooooken, doesn’t work, I’m stuck!”This description does not offer much information. What does not work? What is it, that you don’t get? How it happened, what is the background? Efficient communication is impossible, you have to go back. The stress, the tension grows.Others now need to bug you more, ask many additional questions that could be answered early, they need to dig for relevant information. Some are worse at coping with this frustration, and the entire communication goes to hell - emotions win over cooperation.I set up my personal standard of talking to maser coders. I think this approach is also relevant to recruiter-developer communication.You should drop all the fancy stuff and use something like that:“I’m now working on … (details here!), when I try to do ... (what am I trying to do?), this happens …(bug description), while …(what you expected) should happen!”Or:“I tried to do this thing this way … (my attempt 1) and that way … (my attempt 2), I searched for answers here …(source 1) and here…(source 2), but the following …(the problem) still happens!”I used to write down those structures in my notepad, and I read them to myself. After a couple of short days, it became more natural for me. The schemes rooted themselves in my memory. Example:I got information from my client about a bug. Something wrong with the date of the document. I check it out, repeat the steps the client said he did. Okay, “no date found” error occurs. I Hoped to solve this by manually setting up the original file date and the date it was issued, but the error persists. So, I ask for help (using one of my schemes, of course)!

Tinker yourself a bit!

‍

Wait, now which one was it[/caption]This way you shorten the road to solving the problem by giving more good information. Additionally, you show real initiative by attempting to do the thing yourself, you are learning, you are growing. Always try doing things on your own before running for help. The senior team members, while often very busy, will probably give you five minutes - maybe not right now, but soon. In most cases, their suggestion will be to check some parameters in the system.I work with the client in various roles - a consultant, an account manager, sometimes I do programming tasks in projects. In the case of some clients, when an error happens, they just send us a naked print screen, without a word of commentary. This is a combination of stress, lack of understanding of our jobs, lack of time, and maybe some laziness and fear sprinkled on top. Only with time better communication with a client grows and becomes more functional.Sometimes I even call the client to tell him to improve their communication schemes.If the client has the time, I ask them to go over the situation step by step until the error occurs. I inform the client, that I will use a specific scheme of questioning them. It may sound forced to some, but it’s all about solving the issue faster. I ask what happens, what is going on, what messages you see on the screen if the rest of the company has a similar problem maybe. When I think about it, client negotiations are easily a topic for an even bigger article.I do not want to act as a communication master. The communication tricks I use are just that - my idea. It would be great if you could develop and test your own methods of communicating. Grow those methods, and adjust your communication to the client and to your level of professional development.If you want to talk about the pains of the first steps of a developer’s career - let me know on LinkedIn or go listen to my very own podcast for rookie developers (and more!).

JP.

About the author

Jędrzej Paulus wanted to know more about IT, so he just... switched careers and learned how to code! The story is obviously more complex than that. He studied Russian and Ukrainian philology, taught at a university, worked in an airline in the Czech Republic, spent some time working in Alaska, and now, he became one of the more popular podcasters in the industry.