You’re not writing code, you’re solving problems

I imagine that how it was in the '90s so all business people were there to make UML and "proxy code" that was supposed to be typed in by code monkeys. Code monkeys also would handle all those "not important technical details".

But you have other type of places where one can work. Where you work with sales or business people together on solving problems. In those places it is more like described in the article.

This second type of places in my opinion started winning, because you cut out middlemen who don't code. So in startups you should sell or code there is no place for middle management who rounds up code monkeys. In those places devs get some power because usually it is a company that sells software so they are not cost center but competitive advantage for company.

All too often developers seem to be bent on the idea that they have been hired to write code and so the solution to any problem they are asked to solve must be more code.

The truth (or at least the way I understand it) is that writing code should be something that happens when you have explored every other option possible.

Even if it is easy to write, code is expensive to maintain later on and the costs do not add linearly.

The larger the project the more it costs to maintain anything. Simple operations become huge projects.

The best bet, in my mind, is to try to have as little code as possible by treating the code as a liability and trying to curb the amount of it from the start.

Even if you need to add code to add a functionality, it is frequently possible to shift it from somewhere else. Refactoring as you add functionality is a good way to curb the size of the code base.

Another way I have noticed that seems to be frequently overlooked is to have the object model as close to your real problem. Any inconsistencies between real life and software object model seems to result in heaps of code in multiple components to deal with various exceptions, translations, mappings, etc. and this seems to grow exponentially with time. Sometimes there is no better way than just do it right from the start.

I work for a large bank on a system that deals with risk calculation. It seems every part of organization has a slightly different understanding of what a trade is or definitions of its properties. The net result is that, in my estimation, there is about 3 orders of magnitude more code that would be necessary if there was single shared definition of all those properties.

This seems like preventing new problems from happening. Which is indeed a wrong thing to do if the metric for evaluating employees is "number of problems solved".

If you create a fizzbuzz application with good performance and clean code, you have solved one problem. If you create a fizzbuzz application first, then fix three bugs in it, and then improve the horrible performance, you have solved five problems.