OK, so if the program works, it is good, and if it does not work, it is bad.
So therefore it is also true that no program that works is bad, right?
[QUOTE=Wyzard;17473575]I wouldn't [i]want[/i] a job maintaining 14-year-old badly-written code.[/QUOTE]
My uncle has a good level of pay because he works on old basic code which nobody else wants to / is able to work on (I looked at it and it's harder to understand than assembly) and other old stuff.
[QUOTE=garry;17469756]Or maybe you do. Job security![/QUOTE]
That is stupid as hell. If they do fire/layoff you every time someone asks about you there they are gonna say, "This person sucks, we had to redesign the program from scratch cause they were so bad." Badly coding a program is not gonna stop a company from dropping you too.
Also that kinda makes you a bad programmer, if you have to sabotage the program just so they will keep you...
So working = good, nonworking = bad? Really? Cause your "good" program is probably going to be buggy as hell and no one is gonna want to work on it if it looks like shit.
I think of good as working, nicely coded, easy to understand, documented, etc.
[QUOTE=Jallen;17477258]My uncle has a good level of pay because he works on old basic code which nobody else wants to / is able to work on (I looked at it and it's harder to understand than assembly) and other old stuff.[/QUOTE]
compile to assembly, problem solved :)
[QUOTE=TomyLobo;17477680]compile to assembly, problem solved :)[/QUOTE]
Depends which basic it is though. Like for example, vb6 when compiled has a shit ton of helper dlls which make it very confusing when in assembly.
Sorry, you need to Log In to post a reply to this thread.
