What technical judgment did you only develop after years of experience? What's a mistake you see younger developers repeat because they haven't lived through the consequences yet?
Let's help out those fresh out of school so they don't have to repeat our mistakes.
Jump to Post— Reverend Jim 6,6651) If it ain't broke, don't fix it.
The code base we got from Westinghouse back in 1983 was:
- Horribly written (never refactored)
- Horribly formatted (no whitespace, incorrect or missing indentation)
- Poorly named variables and constants
I had to make a minor change to the code in a …
Jump to Post— rproffitt 3,266Best solutions cost too much.
If the problem is solved, move on to other problems.
Anyone that asks for the best solution without sharing how to measure or rank is still learning.
1) If it ain't broke, don't fix it.
The code base we got from Westinghouse back in 1983 was:
I had to make a minor change to the code in a rarely executed module. I took the time to add a little whitespace to make it more readable (something my boss actually encouraged, at least up to that point). The line I screwed up was a call to an assembler routine which spanned two lines. The first line ended in ",,,," and my change pushed the rightmost "," into column 73.
For those of you who never programmed using punch cards, columns 73-80 were reserved for sequence numbers. In those days some companies had card sorters in case a card deck was dropped. I have never come across anyone who ever sequenced their card decks.
Anyway, compilers were written to ignore columns 73-80 so whenever that routine was called any parameters starting on the second (continued) line were off my one position. Because the code was rarely called it took weeks to track doen the error.
The original change was something minor like changing a constant to allof for an added substation, or something like that. It was such a minor change that no one thought it was worth testing. In any case, testing it would have required spending a great deal of time setting up the rare situation in testing mode (a tedious process).
The above scenario leads into:
2) Test everything, no matter how minor
Best solutions cost too much.
If the problem is solved, move on to other problems.
Anyone that asks for the best solution without sharing how to measure or rank is still learning.
What do you mean by sharing how to measure or rank?
The short answer is "what metric(s) do you use to measure "best"?
As DaniWeb is my primary business, the only metric that really matters at the end of the day is how much money ends up in my bank account at the end of every given month.
All that being said, what do you mean by:
Anyone that asks for the best solution without sharing how to measure or rank is still learning.
So you just mean that if someone asks for the best of something, they should define what they mean by "best"?
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.