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 ViewA 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 DifficultA great bowler is not merely delivering a ball.The bowler is creating uncertainty.The batsman must deal with:Different speedsDifferent bounceDifferent swingDifferent spinDifferent lengthsDifferent linesThe 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 EffectiveThe best batsmen are not simply reacting.They are predicting.They observe:GripWrist positionRelease pointPrevious deliveriesField placementBowling patternsEvery 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 EffectiveSoftware 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 ThisIn 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 batsmanThe bowlerThe fieldThe match situationThe emerging patternsHe 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 RequirementsMany 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 ArchitectureOne aspect of cricket that is often overlooked is field placement.Field placement is not random.It reflects an understanding of:The batsmanThe bowlerThe pitchThe match situationThe intended strategyArchitecture serves a similar purpose in software engineering.Architecture is not merely structure.It is a reflection of assumptions.Every design decision assumes something about:ScaleReliabilityPerformanceSecurityFuture requirementsGood architects and good captains both attempt to position resources where they are most likely to create value.The Wicketkeeper and Production SystemsThe 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 ProfessionThis 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 ThoughtsThe 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.