Viewing a single comment thread. View all comments

Unable-Fox-312 t1_iycdti9 wrote

Reply to comment by OldHellaGnarGnar2 in ELI5: why is using "goto" considered to be a bad practice in programming? by Dacadey

If you can get paid for it, definitely.

You should read the basic docs for your language first, though. Find out what people consider the book and study it, then take on that project in bitesize chunks with tangible goals. See if you can refactor 5% of the functionality and still have a working robot. Then 10%. If you plan to flip a switch and go from 0 to 100 on the job you're setting yourself up for a forever project and ultimately failure

5

OldHellaGnarGnar2 t1_iycf6rr wrote

>If you can get paid for it, definitely.

>If you plan to flip a switch and go from 0 to 100 on the job you're setting yourself up for a forever project and ultimately failure

If I were to refactor the code, I'm not sure it would ever actually be implemented. The robots have been working correctly for a few years, so I doubt management would want to "fix" what isn't broken, and potentially mess what has already been working.

If I did this, I think it would purely be an exercise for me to get better at coding. After a couple years at this job, it turns out I like writing code more than almost anything else, but that's a really small part of my current job - so my goal would be more of "get better at programming and/or learn a new language, so I can be more employable in positions that are more programming-focused"

7

Kriemhilt t1_iycsjrt wrote

The normal term for "the burden of working with rubbish code that is hard to understand or change" is technical debt.

One of the advantages of calling it that is that it sounds sort-of like financial debt, so you're putting it in language management might find easier to understand. You ideally want some concrete motivation though, like

>"technical debt will make it slower (and therefore more expensive) to add these features you want, but if we invest in reducing our technical debt first, those features will arrive sooner and have fewer bugs."

If they don't have any bugs to fix or features to add, this obviously doesn't help you much!

4

OldHellaGnarGnar2 t1_iycyqk2 wrote

Good advice!

>If they don't have any bugs to fix or features to add, this obviously doesn't help you much!

But that's the issue I think I'll have if I try to push it. Our robots generally just work as-is, and most of what we have to add is parameterized, so we're mostly filling in variables and not actually writing code. Actually writing new code for bug fixes or new functionality is pretty rare (I think I'm the only one that's learned how to do it since our division implemented robots).

About a year ago (first time I actually wrote new functionality for them), my boss and I had to convince management I was capable of adding in a new safety feature that got brought up as something we should do.

2