4 ms·

I once had the misfortune of working at a company whose rockstar developer was a bad developer. He could crank out reams of working code as easy as breathing it

I once had the misfortune of working at a company whose rockstar developer was a bad developer. He could crank out reams of working code as easy as breathing it seemed. My misfortune was being assigned to take over one of the projects he threw together. My god, what a mess. He literally had 10 to 20 boolean flags in every pages long functions so that it was extremely difficult to tell what path the code would take under what circumstances. I got fired because I couldn't understand the code enough to enhance it. I was judged inadequate. A couple of years later I had lunch with the developer who took my place. She told me what code she was working on. When I casually said "Oh, that spaghetti code is still used?" she let out a big sigh. She thought the problem was with her and finally someone had come along to call out the crappy code this "rockstar" was foisting on everyone.

cogman10 5y ago
This is a major industry problem. Business managers often care about how many features devs churn out. Quality generally takes a backseat. Devs that churn out more features are generally perceived more favorably than devs that churn out fewer lower maintenance features. There's no linking to "The guy that original wrote the code wrote a mess".
- okareaman 5y ago
  You raise a good point. I don't see maintainability and extensibility discussed very often, except for jokes about Perl being a "write only language." The ironic part of it was I fired because of a bug in his code. One of the flags he was using was set wrong. It cost the company a contract worth a few hundred thousand dollars and since I owned the code at the time it was my fault. I didn't even try to argue because programming jobs were easy to find at the time and I wasn't sticking around to deal with their mess.
overgard 5y ago
I remember this one job, I got assigned to this team because their rockstar left the company and I had similar overlapping talents. His code generally wasn't terrible, but he had this habit of being /way/ too clever for his own good. For instance, we had this 3d mesh file loader (for a game). We wanted to add another file format, since the legacy one we were using was some ancient outdated thing from 3ds max that only one artists could export from their machine, so it was a bottleneck in the pipeline. Anyway, this fricking mesh loading code should have been, if well designed, super easy to update right? Hell no! This guy attempted to use every template meta-programming feature available in C++, so even adding a method to a class would suddenly result in this nightmare cascade of indecipherable template issues. There's this phase any every developers career, my own included, of "being just smart enough to be dangerous". It's like, you're smart enough to use those kind of features, but not smart enough to realize that just because you can doesn't mean you should. The worst part though is, when you take it over, the expectation from non-technical people is "well this guy wrote the feature in a weekend, why can't you update the feature in a weekend"? So you end up looking worse in comparison because your predecessor set you up to fail. I would implore anyone writing code that has some empathy: try to setup the people working on your code for success.
- dorgo 5y ago
  >try to setup the people working on your code for success. yeah, but that would take more than a weekend..

cogman10 5y ago

This is a major industry problem. Business managers often care about how many features devs churn out. Quality generally takes a backseat. Devs that churn out more features are generally perceived more favorably than devs that churn out fewer lower maintenance features. There's no linking to "The guy that original wrote the code wrote a mess".

okareaman 5y ago
You raise a good point. I don't see maintainability and extensibility discussed very often, except for jokes about Perl being a "write only language." The ironic part of it was I fired because of a bug in his code. One of the flags he was using was set wrong. It cost the company a contract worth a few hundred thousand dollars and since I owned the code at the time it was my fault. I didn't even try to argue because programming jobs were easy to find at the time and I wasn't sticking around to deal with their mess.

overgard 5y ago

I remember this one job, I got assigned to this team because their rockstar left the company and I had similar overlapping talents. His code generally wasn't terrible, but he had this habit of being /way/ too clever for his own good. For instance, we had this 3d mesh file loader (for a game). We wanted to add another file format, since the legacy one we were using was some ancient outdated thing from 3ds max that only one artists could export from their machine, so it was a bottleneck in the pipeline. Anyway, this fricking mesh loading code should have been, if well designed, super easy to update right? Hell no! This guy attempted to use every template meta-programming feature available in C++, so even adding a method to a class would suddenly result in this nightmare cascade of indecipherable template issues. There's this phase any every developers career, my own included, of "being just smart enough to be dangerous". It's like, you're smart enough to use those kind of features, but not smart enough to realize that just because you can doesn't mean you should. The worst part though is, when you take it over, the expectation from non-technical people is "well this guy wrote the feature in a weekend, why can't you update the feature in a weekend"? So you end up looking worse in comparison because your predecessor set you up to fail. I would implore anyone writing code that has some empathy: try to setup the people working on your code for success.

dorgo 5y ago
>try to setup the people working on your code for success. yeah, but that would take more than a weekend..