Software engineering is often misunderstood.

Many people assume software engineering is primarily about writing code.

The more I think about it, the less I believe that is true.

Recently, while thinking about cricket and reflecting on why certain players become legends, I realized that software engineering has more in common with batting than coding.

The Common View

A simplified view of cricket looks like this:

Bowler bowls.

Batsman hits.

One succeeds.

One fails.

Similarly, a simplified view of software engineering looks like this:

Requirement arrives.

Developer writes code.

Feature ships.

Again, one succeeds or fails.

Both descriptions are technically correct.

Both descriptions miss what is actually happening.

What Makes Great Bowlers Difficult

A great bowler is not merely delivering a ball.

The bowler is creating uncertainty.

The batsman must deal with:

• Different speeds
• Different bounce
• Different swing
• Different spin
• Different lengths
• Different lines

The objective is not simply to beat the bat.

The objective is to disrupt the batsman's prediction.

A batsman who accurately predicts the delivery gains an advantage.

A batsman who predicts incorrectly often loses their wicket.

The contest is not purely physical.

It is heavily cognitive.

What Makes Great Batsmen Effective

The best batsmen are not simply reacting.

They are predicting.

They observe:

• Grip
• Wrist position
• Release point
• Previous deliveries
• Field placement
• Bowling patterns

Every clue helps build a model of what may happen next.

The earlier the prediction, the more time the batsman effectively gains.

This is one reason elite batsmen often appear to have more time than everyone else.

They are not necessarily reacting faster.

They are often predicting earlier.

What Makes Great Engineers Effective

Software engineering feels surprisingly similar.

Developers rarely operate in stable environments.

Requirements change.

Business priorities change.

Deadlines change.

Customer expectations evolve.

Dependencies change.

Technology changes.

The engineer is constantly receiving new information and adjusting decisions.

Just like the batsman.

The engineer is not merely writing code.

The engineer is continuously updating a mental model of the system.

Why MS Dhoni Made Me Think About This

In 2025, MS Dhoni entered the ICC Hall of Fame.

Many people immediately think about trophies, finishes, stumpings, and captaincy records.

Those achievements certainly matter.

However, what always fascinated me was how he appeared to process the game.

As a wicketkeeper, he occupied a unique position.

He could see:

• The batsman
• The bowler
• The field
• The match situation
• The emerging patterns

He was not simply collecting the ball.

He was continuously gathering information.

He often advised bowlers.

He adjusted field placements.

He analyzed batsmen's tendencies.

He frequently appeared confident in DRS reviews when others were uncertain.

When batting, he also had to perform a different type of analysis.

He had to predict deliveries.

Read field placements.

Identify scoring opportunities.

Assess risk.

And make decisions under pressure.

The more I think about it, the more I realize that Dhoni's greatest strength may not have been any individual cricketing skill.

It may have been his ability to build an accurate model of the game as it was unfolding.

The Bowler and Changing Requirements

Many developers assume the requirement document is the game.

In reality, it is only the starting point.

Business requirements behave like bowlers.

Sometimes they remain predictable.

Sometimes they change direction unexpectedly.

Sometimes they introduce hidden constraints.

Sometimes they create entirely new problems.

The engineer who expects perfect stability often struggles.

The engineer who expects uncertainty tends to adapt better.

The Field Placement and Architecture

One aspect of cricket that is often overlooked is field placement.

Field placement is not random.

It reflects an understanding of:

• The batsman
• The bowler
• The pitch
• The match situation
• The intended strategy

Architecture serves a similar purpose in software engineering.

Architecture is not merely structure.

It is a reflection of assumptions.

Every design decision assumes something about:

• Scale
• Reliability
• Performance
• Security
• Future requirements

Good architects and good captains both attempt to position resources where they are most likely to create value.

The Wicketkeeper and Production Systems

The wicketkeeper occupies a special role.

The keeper often notices things others miss.

Production systems behave similarly.

Logs.

Monitoring.

Observability tools.

Alerts.

Metrics.

These mechanisms frequently identify issues before engineers notice them directly.

When everything works, they appear invisible.

When something fails, they become essential.

Coding Is Not the Profession

This realization changed how I think about software engineering.

Writing code is important.

Batting technique is important.

Neither represents the entire profession.

Great batsmen manage uncertainty.

Great captains manage uncertainty.

Great engineers manage uncertainty.

The skill is not simply execution.

The skill is making effective decisions despite incomplete information.

Final Thoughts

The more I learn about software engineering, the less I see it as a coding discipline.

I increasingly see it as a decision-making discipline.

Code is one output.

Just as a cricket shot is one output.

The real challenge exists before execution.

Understanding the situation.

Recognizing patterns.

Predicting what might happen next.

Adapting when reality changes.

Watching cricket made me realize something interesting.

The players who appear calm are often processing the most information.

Perhaps that is why I admire MS Dhoni's approach to the game.

Not because he was merely a batsman, wicketkeeper, or captain.

But because he seemed to understand the system he was operating in.

And software engineering, at its core, rewards exactly the same thing.

Understanding the system.