Engineers do get promoted for writing simple code
12 points by lalitm
12 points by lalitm
The post is an interesting take but while simpler solutions do often lead to better results and easier long term maintenance, the implementation time of a simple solution can often be as long if not longer than the implementation time of a complex one. This is just down to the fact that coming up with a simple solution takes more work. That's why it's difficult.
The reality is also that sometimes you just don't have the time to find the simple solution, and you must deal with the complex one. That's the origin of technical debt.
“I apologize for the length of this letter; I did not have time to write a shorter one.” (Flaubert, I think?)
Finding simpler solutions is one of those tasks that may take more time but is a win in the long term, like rebalancing a search tree.
but is a win in the long term
Is a win for who, and what are the organizational and economic mechanisms that make it this way?
A win in the long term is a solution that is complex «in the correct direction» for future extensions, but guessing this needs luck…
I don't know. I definitely don't believe in the cynical “You should write complicated code to avoid being replaced”, but I also don't believe there are a lot of people who would do this intentionally. Most engineers who end up designing complicated architecture or writing complicated code believe they are legitimately doing a service to their work and to the business. Discussions of "scale" before there's a single user of a feature or entire application happen all the time.
I'm willing to admit I missed a point somewhere in this post, but I feel like it assumes functional organizations and leadership. If one of those (most often both) is dysfunctional, you end up in really bad spots where anytime somebody even looks at the code it gets more complicated. In my experience, the pressure to "just make it work" is very high, whether that's a new feature/service, or fixing the existing system. That tends to result in the first (often complicated) design being accepted and, if proposed by anybody with any level of seniority, settled upon.
The points about complicated code causing problems down the line is definitely true, but that can go unnoticed for years. Then, whenever the word "rewrite" gets brought up in discussion, it's dismissed as a non-starter.
I don't agree with all of what Rich Hickey says, but this is a perfect example of simple vs. easy.
Engineers get promoted for writing easy code, that works in the time window that there are eyes on it. If there's a problem, and someone else gets stuck solving it, and it takes them a long time, the problem may or may not get pinned on the original engineer.
I've also seen engineers who created loads of complex code, but are pretty fast at doing it, because they cut corners on sanity. In one instance, the same codebase acts as both a transactional system and an analytics system. The analytics system queries the transactional system for recent updates, and stores information about them. The transactional system then queries the analytics system for rollups about trends that the analytics server has stored. Since the system can be a server or a client, classes are helpfull label "BlahLocal" and "BlahRemote", except...both of those are used on both servers, because both servers act as both server and client.
The payload of a response is naturally List<List<Object>>.
I have had to do the tiniest tweaks to this system, and I was sorely tempted to fix it, but disentangling it would've been a significant effort--I figured out how to trace the calls, and make the change I needed to. On the other hand, I'm sure he shat it out pretty quickly while he was heads down on the product, and no one had to invest in standing up a new project and get it deployed in production.
I think there are a couple of misunderstandings and some unfounded claims as well as some theories that don't match reality of everyday work and how companies and people operate at large.
First of all, I don't think that on average the "complicated" coder tricks a lot. I think the assumption that someone is essentially a bad person for not writing simple code is silly. Adding complexity means that you will end up with a lot of complex topics that basically are on their own good reasons for a project to be taking longer and growing even more complex trying to handling them. So the work you stem actually IS big.
At the same time if you sit there thinking about how to simplify an architecture you both may seem like you're doing nothing and you will come up with something that's writing, tested, and shipped quickly.
But as a non-technical and even as a technical manager if you are not deep within both approaches you might not even be able to discern these.
If the complex project is said to take six months and the simple one two weeks and these lead to the same feature for the user then both might reach their goal only in one scenario it was a bigger project which is technically correct and not trickery.
Companies don't have two teams doing the same projects just with different technical decisions, splitting their user bases just to discern who is better at their job.
Look at how hard it is for companies to discern anything at all from job interviews.