Hello, I'm Rick! Welcome to another issue of The Rising Dev, a newsletter where I share career experience, insight, and strategy for getting promoted and rising as a software developer. If you're already a subscriber, thank you so much for your support. If you're not - subscribe.


How Building Domain Knowledge Raises Your Value

As a software developer, I’ve had the opportunity of working in various industries throughout my career, these include automotive, property management, e-commerce, gaming, and streaming media.

In all cases, I was able to build some level of expertise—domain knowledge. Domain knowledge is the industry-specific understanding, insight, and experiences you gain while focusing on a specific area for a while.

For example, in the few years that I focused on e-commerce, I built domain knowledge around PCI compliance; how credit card data is securely transmitted, processed, and stored. While working in streaming media, I built domain knowledge around digital asset management and distribution, how video assets are captured, encoded, and streamed to various TV, computer, and mobile devices.

As a software engineer, this domain knowledge made me more valuable. It differentiated me from other developers and helped me advance my career.

Why Domain Knowledge Matters to Companies

Domain knowledge is like a power-up; it makes you run faster and jump higher; in a software developer kind of way. When you have it, companies pay attention, and usually more money.

As a hiring manager, and someone who seeks to help developers get hired and promoted, I have some opinions on why domain knowledge matters to a company.

  • When you have domain knowledge related to the industry you are in or the role you are working towards, you will be on-boarded much faster—allowing you to make valuable contributions to the organization and team much earlier in your transition. An additional positive side effect is that these early wins will help you build confidence and trust.
  • Domain knowledge is often built on the back of failures. Having domain knowledge likely means that you’ve seen what works and what doesn’t, and you will be in a unique position to identify and mitigate risks while proposing more thoughtful solutions.
  • Knowledge sharing, mentorship, and coaching are vital parts of building great teams. If you have domain knowledge, you have the experience to catalyze learning and growth in others.

A more direct way of putting it is, hiring and promoting great software developers with domain knowledge saves time, money, and energy.

Why Domain Knowledge Should Matter to You

You don’t "need" domain knowledge as a software developer. Your technical skills can be enough to get you contributing to teams and getting features and products across the finish line. However, having domain knowledge can be a differentiator, something that separates you from the rest.

If your goal is to level up, to work on more challenging projects while rising in your career, building domain knowledge can help you do that; here’s how:

  • Generally, domain knowledge changes less than technical knowledge. You can invest time and energy and be confident that the domain knowledge you acquire will likely keep a longer shelf-life. There’s efficiency in intentionally pivoting some of your time to building domain knowledge.
  • Domain knowledge within specific industries can help you make data-driven decisions early. There are constraints or guard-rails already set at the industry level that can benefit you and your team. For example, in the case of video-on-demand (VoD, think Netflix or Hulu), there is a wide range of public data and metrics around quality of service (QoS). When you have the domain knowledge to know that a 3-second delay in a video starting might mean losing 13% of your users or that an 8-second delay could cause you to lose 50%, you may want to focus on optimizing for performance over aesthetics.
  • Having domain knowledge can help you make decisions around priorities and tradeoffs. In the case of an e-commerce domain, companies like Shopify and BigCommerce have already set consumer expectations and established the table stakes for features. You become quicker in analyzing their product offering and those of your competitors, and you can more quickly devise a strategy for what to build vs buy.

When you focus on technical skills alone, you can easily miss some of the advantages I just described. A lack of domain knowledge may not stop you from rising, but you would be missing out on some acceleration.

Domain Knowledge: Depth and Competency

Having domain knowledge isn’t necessarily about specializing. You still need to be a good software developer with a well-rounded set of hard and soft skills. Think of domain knowledge as a multiplier; it can make you and your team more effective while reducing risk to an organization.

Something to consider is the variability regarding how deep you might aim to build domain knowledge. You can go deep and become an expert or simply learn enough to be competent. I mention this because if you’re like me, you may prefer to build domain knowledge in multiple areas at once, and going shallow may be the best strategy for managing time and energy.

Let yourself explore multiple areas. The notion of T-Shaped skills applies here. A T-Shaped developer will have a breadth of knowledge across several areas and more in-depth knowledge in a more narrow area. An example of this could be a developer with a range of expertise and experience across UI development, testing, browser compatibility, and troubleshooting. Additionally, and in contrast, they have more in-depth knowledge in areas like accessibility or performance optimization as it relates to video streaming, or e-commerce, or gaming.

The point is you don’t need to get bored building domain knowledge. Breadth of expertise in other areas helps you maintain flexibility so you can alter your career course as your goals change.

Domain Knowledge Is a Strategy

Building domain knowledge needs to be intentional. You should focus on it and study it as you would any new coding language or framework. There are a couple of reasons for this:

  1. Domain knowledge can overlap and stack atop other domain knowledge. Some domain knowledge in payment systems, coupled with user management systems, would help you stand out within any company focused on building and maintaining a subscription service. You can be strategic about how you combine this knowledge to achieve your career goals.
  2. Having domain knowledge equips you to mentor and coach others, to share your knowledge. It allows you to build strength in others—this is how personal succession planning for getting promoted starts. You build others up so they can fill in for you as you rise in your career.

One last thing, experience has taught me that domain knowledge in most fields is relatively scarce, and it comes and goes as people move between industries. Consider the last time you watched a video or took a 30 minute course on a specific field or industry (not just code languages and frameworks); not many developers do this.

The journey between being a competent developer and being a competent developer with domain knowledge can be quick. A single hour of study per week can quickly put you in the top 5-10% of developers within a given industry—this is an opinion, of course, but it’s an opinion informed by 20+ years of observation and experience. We are leaving way too much of our value on the table as developers.

If you believe the data, there are about 24 million developers worldwide right now and growing. Differentiating yourself within software development has never been more critical to your career success.


Imposter Syndrome is one of my favorite topics, mainly because it can mean so many different things to different people. Yes! The strategies for dealing with it are numerous and yes, I'm throwing some more your way.

If you haven't listened to it yet, here's the conversation I had with Mark Snyder on his podcast Building Better Software Teams, about Imposter Syndrome of course.

BBST Episode 2: Dealing with imposter syndrome (Guest Ricardo Luevanos)
Ricardo Luevanos is the director of engineering at Zwift and also runs his own site dedicated to sharing his experience and expertise with other developers. In this episode we define what “imposter syndrome” is and explore some of the tools he has developed to help deal with it.

Give it a listen, let me know what you think.


On the topic of differentiation, and on being a better developer overall, I want to share some recent reading on the topic of Effort and Impact.

Source - Staff Engineer: Leadership beyond the management track

In Will Larson's newest book, Staff Engineer: Leadership beyond the management track, Will mentions a few common ways we get tripped up when we run out of low effort / high impact work, the work that can matter most in my opinion. He describes these as:

  • Snacking: This is the low effort / low impact work.  This work can give you a sense of accomplishment, making it feel rewarding. It's ok to snack occasionally, especially in between the bigger stuff, but don't overdo it.
  • Preening: A subset of snacking, where you are still focused on low effort, but in this case the work has high visibility, to the point of being confused with low effort / high impact work. Your essentially doing low-value work that is frequently recognized as wins for the company—this is a trap! You get short-term gains here.
  • Chasing Ghosts: This is the high effort / low impact work. These are the BIG things you think need to get done, either due to ego or past experience. This makes me think of the folks that champion rebuilds from scratch, or moving an entire software stack to a new platform, because thats the way they did it in previous organizations, or because thats the way the other companies are doing it. Here, there be dragons!

If you're a software developer and haven't picked up a copy of this book, I strongly suggest you do, regardless of the level you are at.