I have a coworker who _excels_ at writing code - one of those engineers who can metabolize caffeine directly into code.

They write code to implement the all-important features. They write code to work around lack of process. They write code to work around problem people not doing their jobs well. They write code to work around buggy code by other developers. They write code to work around their own code, written weeks or months earlier.

I've been encouraging them to _reduce_ the amount of code they write, and instead consider the context around why they're writing the code. Code is just one way - and not always a particularly good way - that we can solve people and process problems.

Best Software Engineering advice I ever heard was at a conference talk by a guy called Dan North: "Think of code like surgery".

Basically Surgery is a means to an end (patient gets better) and a useful tool for achieving that but it's also dangerous so only used when necessary. If other treatments can fix the problem you try them first. If surgery is required you only do the minimum required to treat the issue.

Code is similar. More code means more maintenance, more tech debt, slower deliverables in future and higher risk of dependencies no one understands. So when coding ask "Can I fix this without code?" because if yes it's often easier in the long run and "What's the bare minimum/simplest code I need to write to fix the issue?".

I try to write as little code as possible. I do love writing code, but I've learned to love removing code even more.

The big problem in many companies is that often programmers are kept out of that context. Problems are discussed without programmers, and only tossed to programmers once non-programmers have decided what they need to do. I think we need to be more involved in those decisions.

I'd be trying to make better use of this tendency and talent, not trying to curtail it.