4 ms·

> there’s no difference between ridiculously shitty code that works, and beautiful, well-organized code that works. Unfortunately that's not true. If "shitty c

by zldkz5 8y ago

> there’s no difference between ridiculously shitty code that works, and beautiful, well-organized code that works. Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue and three days in a problem that can be solved in one hour are $$ that somebody is paying. In addition "shitty code that works" most of the time has scalability and performance issues sooner or later you need to address if you don't want it to implode. > where would you like to go from there? I can also keep staying in this position, I just don't like to have a manager that I'm not even proud of. And, by the way, I'd like to be in a position where decision making is more stronger also in a business perspective. There are a lot of ridiculous choices that some people makes that are not very effective in some ways let alone make data driven choices. As the organisations today claims to be "agile", most of the time they're not at all. They just use a new word but act as old school (long feedback-loop just to give you an example)

oblio 8y ago
I had a cat. The cat would do stupid stuff while I was away and when I'd get home I'd get angry and smack the cat with a newspaper. Then someone told me: the cat is like a small kid: if you punish it after more than 5 minutes, it doesn't associate the punishment with the "crime". People outside your team won't understand your reasoning. They'll see code working one day and a random failure a long time after that, which might or might not be related to the previously working code. They're just like my cat. If you want to act for "shitty code", act before it's in production. Afterwards it's very hard to dislodge. And even harder to pinpoint the blame, as the author will definitely protect his back, ethically or not. I'd take the experience as a lesson in human interactions :)
Rooster61 8y ago
> Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue and three days in a problem that can be solved in one hour are $$ that somebody is paying. In addition "shitty code that works" most of the time has scalability and performance issues sooner or later you need to address if you don't want it to implode. I think you might be missing their point. From the perspective of a programmer, yes, these things are true. Code SHOULD be Good and Right™, and that is very easy to see and grok from a programmer's standpoint. But to a manager? These things usually have to be stated explicitly, and that isn't entirely the manager's fault. It is easy and pervasive in the industry to write crappy code that works for a variety of reasons (time constraints, incompetence, poor decisions from on high, etc...). Even the best managers have some degree of "out of sight, out of mind" because they rightly delegate the responsibility of making sure the code works AND minimizes tech debt to the developer. It doesn't become apparent to them (and by proxy, the business) that the code was poorly written until the shit hits the fan. Also, it is unfortunate that you have to leave that job. In my experience in the industry, being able to go back and fix tech debt like you are describing is very uncommon.
- zldkz5 8y ago
  Has I said in another comment it was made out of request by the manager and director. They asked us to clean the code since we were experiencing issues due the volume. Without the changes that we were asked for today the company could not even be able to sell their product online.

by zldkz5 8y ago

oblio 8y ago

I had a cat. The cat would do stupid stuff while I was away and when I'd get home I'd get angry and smack the cat with a newspaper. Then someone told me: the cat is like a small kid: if you punish it after more than 5 minutes, it doesn't associate the punishment with the "crime". People outside your team won't understand your reasoning. They'll see code working one day and a random failure a long time after that, which might or might not be related to the previously working code. They're just like my cat. If you want to act for "shitty code", act before it's in production. Afterwards it's very hard to dislodge. And even harder to pinpoint the blame, as the author will definitely protect his back, ethically or not. I'd take the experience as a lesson in human interactions :)

Rooster61 8y ago

> Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue and three days in a problem that can be solved in one hour are $$ that somebody is paying. In addition "shitty code that works" most of the time has scalability and performance issues sooner or later you need to address if you don't want it to implode. I think you might be missing their point. From the perspective of a programmer, yes, these things are true. Code SHOULD be Good and Right™, and that is very easy to see and grok from a programmer's standpoint. But to a manager? These things usually have to be stated explicitly, and that isn't entirely the manager's fault. It is easy and pervasive in the industry to write crappy code that works for a variety of reasons (time constraints, incompetence, poor decisions from on high, etc...). Even the best managers have some degree of "out of sight, out of mind" because they rightly delegate the responsibility of making sure the code works AND minimizes tech debt to the developer. It doesn't become apparent to them (and by proxy, the business) that the code was poorly written until the shit hits the fan. Also, it is unfortunate that you have to leave that job. In my experience in the industry, being able to go back and fix tech debt like you are describing is very uncommon.

zldkz5 8y ago
Has I said in another comment it was made out of request by the manager and director. They asked us to clean the code since we were experiencing issues due the volume. Without the changes that we were asked for today the company could not even be able to sell their product online.