When we hire developers at RIVER, we spend very little time on frameworks. React, Angular, Vue, TypeScript. These are tools. You can learn a tool. What takes longer to develop is domain understanding, clear communication with non-technical stakeholders, and the discipline to write code that someone else can maintain in three years. Those three skills determine whether an enterprise project succeeds.
What You Need to Know
- Technical proficiency is the entry ticket, not the differentiator
- Enterprise development requires domain fluency, communication range, and maintainability discipline
- These skills compound over time and determine long-term project outcomes
- They're rarely taught, rarely tested in interviews, and consistently undervalued
Skill One: Understanding the Business Domain
Most developers build what they're told to build. Good enterprise developers understand why they're building it.
The difference shows up in a hundred small decisions every week. When a developer understands the business domain, they catch requirements that don't make sense. They suggest improvements the business analyst didn't think of. They design data models that accommodate future needs because they understand the direction the business is heading.
On my first enterprise project at RIVER, the first thing I did was not set up the dev environment. It was spending a full week understanding the client's operations. Sitting in on their meetings. Reading their process documents. Asking questions that had nothing to do with technology.
By the time I started coding, I had caught three requirements that contradicted each other, identified a workflow the client had not documented because "everyone just knows how it works," and proposed a data model that handled an edge case the business analysts had missed entirely.
That week of domain immersion saved months of rework.
The best code is not technically impressive. It reflects how the business actually works, not how someone described it in a requirements document.
John Li
Chief Technology Officer
How to Build Domain Fluency
Spend time with users. Not the project sponsors. The people who do the work. Watch them. Ask about their day. Understand what frustrates them. This is user research, but done by the person writing the code.
Learn the vocabulary. Every industry has its own language. When a developer uses domain terms correctly in conversation, the client's trust increases visibly. When they use them incorrectly or avoid them entirely, a gap opens.
Ask "why" relentlessly. "Build a dropdown with these twelve statuses" is an instruction. "Why are there twelve statuses? How many are actually used? What triggers the transition?" is understanding. The second set of questions produces better software.
Skill Two: Communicating With Non-Technical Stakeholders
Enterprise projects have steering committees, project boards, and executive sponsors. These people make decisions about scope, budget, and priority. If the developer can't communicate with them, someone has to translate. Every translation loses fidelity.
29%
of enterprise project failures are attributed to communication breakdowns between engineering and business teams
Source: Project Management Institute, 2018
This isn't about being a charismatic presenter. It's about being clear.
When a engineering constraint limits what's possible, the developer should be able to explain it without jargon. Not "the API rate limit means we can't process that many records in real time" but "the external system can only handle a certain number of requests per minute, so we'll process the large batches overnight and show the results in the morning."
When a decision needs to be made, the developer should be able to frame the options in business terms. Not "should we use websockets or polling?" but "do you want users to see updates instantly, which costs more to build and run, or is a thirty-second delay acceptable?"
The Translation Skill
Every developer at RIVER is client-facing at some point. We talked about this when we wrote about building teams. It's not optional. And the ones who do it well aren't the ones with the most polished communication skills. They're the ones who've developed the habit of translating.
Technical concept to business impact. That's the translation. Every time.
Skill Three: Building for Maintainability
The first version of any system is written by people who understand it. The second version is maintained by people who don't. In enterprise, systems live for five to ten years. The original team moves on. New developers inherit the codebase. The code needs to make sense to them.
This is the most undervalued skill in software development.
Writing clever code is easy. Writing code that a junior developer can read, understand, and modify two years from now is hard. It requires deliberate discipline: clear naming, consistent patterns, meaningful comments that explain intent rather than mechanics, separation of concerns that make it possible to change one thing without breaking three others.
What Maintainability Looks Like
Consistent patterns. When every module follows the same structure, a new developer can navigate any part of the codebase. The surprise factor is low. Predictability is a feature.
Tests that document. Automated tests, when written well, serve as living documentation. They describe what the system does and what it expects. They're more reliable than comments because they fail when they're wrong.
Strategic simplicity. The temptation is always to build the elegant, generic, reusable solution. But generic solutions have generic maintenance costs. A simple, specific implementation that does exactly what's needed is easier to understand, easier to modify, and easier to replace.
I have never regretted writing code that was too simple. I have regretted writing code that was too clever more times than I can count.
John Li
Chief Technology Officer
Documentation of decisions. Not just what the code does, but why it was written that way. What was considered and rejected. What constraints existed. A future developer looking at a puzzling implementation needs to know whether it's a mistake to fix or a deliberate choice to respect.
Why These Three
These skills compound. A developer who understands the domain communicates more effectively because they speak the client's language. A developer who communicates well builds more maintainable code because they think about the next person reading it. A developer who builds maintainable systems has more time to understand the domain because they're not trapped in a cycle of rework and firefighting.
Most hiring processes test none of this. They test algorithms and framework knowledge. Those are the easy things to test, not the important things. At RIVER, we've learned to hire differently. Not for what someone knows about the current stack, but for how they think about the work. The frameworks change every two years. The skills that make someone effective on an enterprise project are the same ones they'll need in ten years.