This is nonsense. Sure, the company you work for might not care about your code, but the other programmers you work with absolutely do. They have to deal with what you write, good or bad. And someday, they're going to be the people who decide whether they want to recommend you for that great opening at their new company. So yes, important people do care about your code.
It may differ from team to team, but several I've worked on even the programmers did not much care about the code. We were invested heavily in process, like unit testing and use driven development. A primary motivator was showing that the features were actually working. The actual code was kind of secondary, so long as it was working we were okay with it. It's actually kind of liberating for programmers knowing that nobody really needs to care about your code -- I don't want somebody micromanaging details and nitpicking small choices.
I'm going to put a big "however" on this, and it's something I mention in the article as well, I'm assuming a certain base-line of competant coding and workmanship. Crap code is unnaceptable everywhere; it's also very unlikely to actually implement the desired feature. The article is a counter to over-engineered results and needless perfectionism. It's about finding a good balance and focusing on the priorities of the project as a whole.
I totally agree. I have been working on stored procedures that were written by people who were just trying to get things working. A code and fix situation if you will. There was no planning or proper testing.
Anyway, now I have someone helping me and they can easily modify my code, but if they have to look at the old version they're baffled as to where to start looking for how it was done before.
Writing careless code is a cancer in a project, and sometimes the only solution is to kill the code and start fresh
and sometimes the only solution is to kill the code and start fresh
I try to get this point across at my work, we can get things done quick and dirty now and have to completely rewrite it later. Or I can spend a little extra time planning and writing maintainable code and we can use that time in the future to add a new feature.
I don't think students coming out of school understand how much code is just such utter garbage that it's easier to just start over and throw out the old code.
I hate stupid titles like this. "It's not the code that matters, it's the product. However, there are a million reasons why writing readable and elegant code is important, so you may as well keep doing what you're doing."
Nobody? What about yourself? If I write something I want to be proud of it, if nobody else appreciates that then whatever. However if you can't even be proud of what you just wrote, then why bother writing it in the first place?
11 comments
12 u/NassTee 15 Jun 2015 06:34
This is nonsense. Sure, the company you work for might not care about your code, but the other programmers you work with absolutely do. They have to deal with what you write, good or bad. And someday, they're going to be the people who decide whether they want to recommend you for that great opening at their new company. So yes, important people do care about your code.
0 u/mortoray [OP] 15 Jun 2015 09:23
It may differ from team to team, but several I've worked on even the programmers did not much care about the code. We were invested heavily in process, like unit testing and use driven development. A primary motivator was showing that the features were actually working. The actual code was kind of secondary, so long as it was working we were okay with it. It's actually kind of liberating for programmers knowing that nobody really needs to care about your code -- I don't want somebody micromanaging details and nitpicking small choices.
I'm going to put a big "however" on this, and it's something I mention in the article as well, I'm assuming a certain base-line of competant coding and workmanship. Crap code is unnaceptable everywhere; it's also very unlikely to actually implement the desired feature. The article is a counter to over-engineered results and needless perfectionism. It's about finding a good balance and focusing on the priorities of the project as a whole.
4 u/el_cordoba 15 Jun 2015 13:05
I totally agree. I have been working on stored procedures that were written by people who were just trying to get things working. A code and fix situation if you will. There was no planning or proper testing.
Anyway, now I have someone helping me and they can easily modify my code, but if they have to look at the old version they're baffled as to where to start looking for how it was done before.
Writing careless code is a cancer in a project, and sometimes the only solution is to kill the code and start fresh
1 u/a_of_s_t 15 Jun 2015 19:35
I try to get this point across at my work, we can get things done quick and dirty now and have to completely rewrite it later. Or I can spend a little extra time planning and writing maintainable code and we can use that time in the future to add a new feature.
I don't think students coming out of school understand how much code is just such utter garbage that it's easier to just start over and throw out the old code.
3 u/FiftyShadesOfBlack 15 Jun 2015 08:09
In conclusion:
1 u/acratus 15 Jun 2015 13:46
I hate stupid titles like this. "It's not the code that matters, it's the product. However, there are a million reasons why writing readable and elegant code is important, so you may as well keep doing what you're doing."
0 u/hipsterpottamus 15 Jun 2015 11:51
Nobody? What about yourself? If I write something I want to be proud of it, if nobody else appreciates that then whatever. However if you can't even be proud of what you just wrote, then why bother writing it in the first place?
0 u/skeeto 15 Jun 2015 20:52
Hey, Mortoray came to Voat! It's nice to have familiar faces appearing around here.