The worst kind of programmer

I'm sure there are circumstances where there's good reason to firehose thousands of lines of complex unmaintainable code. But how common is such "throwaway" projects?

Your question is grammatically correct but doesn’t make any sense. Software isn’t an industry, it is used in every industry.

I somewhat identify myself as being such worst kind of programmer.

I like to tackle hard problems. I like playing around with new technology. I like to try out new ideas how to solve problems. I started coding since I was a child, around 10 years old. I tend to code many hours non-stop on interesting problems. (Now with family and kids, I'm somewhat limited in doing that, though.) Many people say that they admire how productive I am and how much I accomplish.

Sometimes some of the design decisions of some projects seem to be bad and lead to lots of overhead later. Basically the wrong kind of abstractions were chosen. Other parts of the software are much better and the abstractions seem to be quite nice, but this is not true for everything. (Related recent discussion here: Goodbye, clean code (2020): https://news.ycombinator.com/item?id=38566235)

I often tried to discuss some of the designs with more people, but noone was really interested in this work, so to push things forward, it was still often just me doing the decisions. I think the management just does not want to invest more resources into the software development. After all, the software works and does its jobs, but it's messy and I think it holds us back in some ways. But my manager keeps saying, we are not a software company, the software is just there to solve some problem.

So, how to improve myself? I was trying to improve on basic design decisions of the software. The feedback loop here is very long though, and then difficult to really pinpoint it in the end. I also tried to improve my communication skills, but here it's even harder to tell whether I improved. At least every decision I do is discussed and communicated in many ways.

I definitely learned already that the simpler the solution, the better, as also this article is pointing out. But that comes back to the problem of making exactly the right kind of abstractions, i.e. the right design decisions.

Often I think I overthink some of the problems now to come up with the right abstraction. I want to get back to my older habit to just do things and iterate. But I'm afraid that this again leads to more messy solutions.

I mean Rust code can become really opaque very fast, as there are macros and a ton of meta programming features that can make it very hard to know what a given piece of code is doing exactly (in my opinion). Golang is very straightforward in that sense, reading and understanding code seems much easier. It’s of course possible to write simple, straightforward Rust code.

> The org in the article sounds like it's missing CTO/engineering management.

Not necessarily. I’ve worked in a company where the CTO itself was encouraging those employees. He established a clear list of goals to achieve to climb to the next seniority level.

To be promoted you _had_ to do stupid shit like hacking the framework (which was Angular so I let you imagine the potential), be the architect of the project, or make company-wide presentations of your original solutions.

Of course, a team full of people hacking things, trying to be the architectural leader and solving old problems with "invented here" solutions can’t really exist.

So you were either in the promoted hackers camp or in the camp of people trying to do their job of delivering value and quality at the lowest cost, which in a CRUD SaaS business means that most of the time you just have to do the old boring things "by the book" that have proven to just work. But if you were in this camp you were seen as underperforming because you didn’t do what was expected but also you were underperforming for real because adding a single API in the back or a component in the front was just a hell of stupid work.

The "high performers" were just the people who created this hellscape because since they invented it they’d be the only ones to have a full mental model of the team’s codebase.

Now I just avoid any company who promotes their team as "the most talented engineers" because it’s either false or worse. I’d rather work with average coworkers who have a life outside computers and who just want the work done by 6pm.