How Can You Increase Your Value as a Software Engineer
Shockingly, it’s not by learning new hot framework or language 😉
🙏 Many thanks to Daniel Grooms for editing.
This post is a bit “meta” in its nature. Instead of sharing code snippets w we will be building a mental context that will ultimately make way for actionable ideas.
We all strive to be the best version of ourselves. In both our personal and professional life we want to grow, taking on new challenges and responsibilities. This enables us to provide increasingly more value to the teams and organizations we’re part of.
The beginning of a software development career is usually about getting to a basic level of competence. This is necessary to be considered effective and to be able to provide any value whatsoever.
It usually goes something like this. First, learn a chosen language with all its peculiarities. Then proceed with learning the whole ecosystem around the language. Popular libraries, frameworks, build systems, conventions, best practices, you name it.
All of these skills enable you to get things done. Preferably in a maintainable, well-tested, and timely manner.
Delivering all the requested features and bug fixes is nice and necessary, but why stop there? You might add another language or two, keep on learning every new hot framework that pops up, or expand your DevOps know-how.
All of these skills are definitely useful. Unfortunately, they don’t bring qualitative improvement that would match the initial jump from not being able to code to delivering useful features. We’re encountering a case of diminishing returns and there is a more valuable way of investing your limited time and energy.
That doesn’t mean you should stop following all the recent developments in software engineering. It’s always good to be up to date on your favourite stack.
Over the course of many years, different teams and organizations will uncover some recurring patterns. Most business out there actually don’t have to deal with problems which are result of their global scale. Similarly, they usually don’t deal with challenges that mandate deep algorithmical expertise. Strategies such as improving graph traversal times by small amounts to save millions in hardware operation costs…
Real challenges usually lie somewhere else. To put it bluntly, it’s more about understanding what to build and if it’s worth building instead of how to build it. This means challenges are usually on a level that is higher than that of a Software Engineer. Positions like Business Analyst, Product Owner, or Manager deal with these issues.
These people then have to pass on their ideas about what to build to the developers. Requirements communication is an inherently noisy process. People with knowledge about “what” might not be so competent in the matters of “how”.
Unclear requirements that change often lead to implementation of vastly suboptimal solutions. This outcome can be prevented. Single person possessing knowledge of both “what” to build and “how” to make it happen can deliver superior results.
Leveraging this fact can help you become a much more productive and valuable member of your organization.
The key is to learn more about the core business of the organization you are working for. For example, knowing how to calculate an insurance premium, understanding the inner workings of the tax system of your target country, or learning characteristics of the financial instruments on the stock market; whatever the domain calls for.…
“Hey Tomas, that sounds great, but it will take so much extra time to do so. It’s the responsibility of an analyst.”
And of course, you are 100% correct. Then again, it’s one of the most effective things to do in many situations.
Most software developers know how to iterate a collection in many languages, use some decent framework, or make a back-end request. But do they really understand the domain at hand?
Understanding the core domain will translate into many benefits. You will be able to expect new requirements. Correctly estimating scale will result in the understanding of possible performance bottlenecks. Having a domain overview will help you to better structure the codebase into modules.
These are some of the many possible benefits of domain knowledge. Becoming a de-facto product owner or domain expert will enable you to deliver superior results in a shorter amount of time.
Is it easy? No… Is it effective ? Damn right it is!
How to get expertise in core domain
So what are the concrete steps you can take to embark on a journey to become well-versed in the domain of your choosing?
The key is to take interest & initiative
- Use the product yourself (eg: real product, demo account, simulator)
- Search and read blogs and books about the domain topics
- Talk to colleagues on the business side during the coffee and lunch breaks. They are usually more than happy to tell you about nuts and bolts of their work if you show genuine interest
- Join online & offline communities like forums, sub-reddits, or meetups that are related to your domain
- Follow important figures on twitter
Basically all the things you’re doing for the software development domain already 😉
By doing all this you will build strong competence in the target domain. This will enable you to provide even more value to the organization and people around you!
🎉Finale
That’s it for today! I hope you found these ideas helpful and if you did, please share them with your friends and colleagues. Also, feel free to check some of my other articles about Software Engineering and Front-End Development.
Follow me on Twitter to get notified about the newest blog posts and useful front-end stuff.
And never forget, future is bright
