I touched on this subject in my very first post and I believe it deserves a little more fleshing out. Understanding and using the language of software engineering is the single biggest challenge I faced in breaking into the industry and improving as a developer. This is a battle on two fronts: understanding others and making yourself understood.

How I Got It Wrong

My first job in the industry was for a tiny startup in Las Vegas, Nevada. I worked directly for the CEO and he preferred me speak in plain spoken english about technology terms. He advised me that it took more skill to communicate in more universal terms and I can see the logic in that. What this meant for me was eschewing the more specific jargon I was used to and relying more on finding similes and analogies for the concepts I tried to convey. I came to see those who spoke in obscure, specialized terms as somewhat self-aggrandizing.

Of course, landing my first agency job with a team full of bona fide developers and an actual CTO woke me to the flaws in this mindset. Right off the bat I struggled to communicate anywhere near competently. It was the height of frustration.

The Importance Of Terminology

For the first several months of my agency job I toiled away on tasks feeling completely overwhelmed because I misunderstood what was actually asked of me. I felt dumb. Nowhere was this more apparent than in our weekly developer meetings where ideas were expressed in arcane nomenclature. I couldn’t follow along at all. Only after the meetings were over and I researched our talks did I realize I did in fact ‘know’ the material that was covered, just not the language.

Equally frustrating was the inability to express my ideas or voice valid concerns about the validity of instruction I was given. On more than one occasion I went down a known dead-end because I couldn’t figure out a way to say this won’t work ‘for this reason’. This resulted in a lot more work and wasted time.

The Fix

There was no quick fix to this problem. The solution involved me first getting over my knee-jerk reaction to esoteric language. The second part was just increasing my familiarity with development terms through exposure. There simply isn’t any substitute for experience. I still hang on to my love for making concepts universally understood. And I think this will serve me well in the future, particularly when bringing clients into the fold of what we’re actually doing with our time and THEIR money.