I’ve been a software engineer and web developer for almost 11 years now. I was never the most technically knowledgeable nor the smartest developer in the room, far from it in fact. But what set me apart from others is desire to learn more and be different.
A software engineer or developer’s role is not to focus on vertical skills (programming, advanced design patterns, and god knows what more advanced things unicorn devs learn today).
To be an effective software engineer, you need to expand horizontally.
This means learning non-technical skills. Learning to understand how business works together with programming. Learning product design. MVP design.
And…Learning how to gather requirements with your client so you don’t develop bugs and fall into an infinite loop of writing and modifying code (every dev in the world is a victim to this).
There’s so much that can be said about the above but let’s focus on the title now.
Technical Jargon
Being too technical is a common reason why many senior developers stay developers and never get promoted far beyond their current role.
You see, product owners and managers, CTOs and those higher above do not care about your tech jargon, even though it sounds super cool and like you were born on the set of a star trek film. They don’t care about how many frameworks and languages you know, nor how well written, clean and scalable your code is. The only thing they care about is whether it works as per client/product owner requirements or not.
Many senior devs (if not most) make the mistake of not understanding this and will instead focus on talking about the Factory pattern and other advanced OOP concepts to their client. The business and product owners not only do not care about that but they won’t understand it. But they will understand that your code will save them x dollars per month because it minimizes data fetching.
Dumbing it down
Most of the time you need to make your brief explanations so simple that a 5 year old will understand. Kinda like that expression “explain it like i’m five”.
That’s a great paradigm to have whenever talking to clients and business/product owners.
Often times this also applies to junior and intermediate developers. Just because you understand it in your head won’t necessarily make it as clear in their heads. Learn to make your talk less technical and people will understand you more and find it easier to work with you.
Getting more people around you to understand you will increase your chances of being included in higher up conversations dramatically. You’ll be considered for advice on design and listened to longer.
Keep that in mind and you’ll notice the changes immediately.
Read my other articles on Medium:
https://medium.com/@atomicsdigital
I hope you learned something of value and practical to make use of for your next project!
You can follow me here for more articles:
