|
The scenario:
I found the problem and wrote a try-catch around it. If you want me to dig deeper into the actual issue, let me know.
Sigh. YES I WANT YOU TO DIG DEEPER!!! It's not that the person in question is stupid - far from that. Not even lazy. Just a "trigger-solution" mentality - oh, I found the problem, here's the first idea that pops into my head on how to fix it, done.
How do you train a person like that, to be more thorough, more detail oriented, more meticulous, and not just reach for the "try-catch" nuclear radiation shielding when a simple "if statement" pot holder works much better, explains the issue to the next developer, and doesn't hide true nuclear meltdown issues?
The above is a specific example of a frequent general problem. 
|
|
|
|
|
If said person can (and will) read, there is a very good book, Code Complete: A Practical Handbook of Software Construction, Second Edition, by Steve McConnell. It teaches by example, showing many such coding horrors and why they should be avoided.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
To me, an exception is a bug that needs to be found and fixed. Catching it and surviving is just papering over the problem, because it's very unlikely that the code did what it was actually supposed to do.
The only time this kind of thing is acceptable is when a customer is having a serious problem, in which case any kludgy solution will do. Even after that, the goal is always to find and fix the root cause of a problem. A function received a bad argument? OK, who supplied it and why? Fix that. And so on.
|
|
|
|
|
I would like to add my voice to this question.
It is possible that the smart newbie is simply being conscious of the fact that digging deeper would cost the company more money. He/she may think that the company wants the fastest solution.
When you speak with him/her, make clear that this is a case where he won't be scolded for taking extra time.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
And ... the quickest solution isn't the fastest or cheapest in the long run: it costs a load more to fix the "fallout damage" from a kludge that it does to fix it properly in the long run. A simple example is to think how much human effort is required to fix a DB containing dates are stored in text exactly as the user entered them once you get round to using the column for an urgent management report ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: the quickest solution isn't the fastest or cheapest in the long run
Right. This is the thing that management needs to be made to understand. I have had to remind my boss of this on several occasions.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Early in my career I was very conscious of the fact that my boss wanted the code to be written as quickly as possible for financial reasons and never stressing or even mentioning quality. As a result my code was a piece of zhit resulting in many bugs wasted time and of course money. I eventually made a conscious decision to ignore his wants. My code improved considerably. Cheerios
|
|
|
|
|
Richard Andrew x64 wrote: It is possible that the smart newbie is simply being conscious of the fact that digging deeper would cost the company more money.
Newbie's don't even consider that.
Richard Andrew x64 wrote: make clear that this is a case where he won't be scolded for taking extra time.
We have an excellent work environment that promotes deep understanding and if there's a critical emergency, it's stated clearly as "do whatever is needed to fix the problem right now then go back to it later and figure out the right way to fix it."
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
|
|
|
|
|
Marc Clifton wrote: Newbie's don't even consider that.
Speak for yourself. 
Marc Clifton wrote: "do whatever is needed to fix the problem right now then go back to it later and figure out the right way to fix it."
He fixed it, and then offered to go back and dig deeper if that was required. Where's the problem?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
"Shame" them:
An ounce of prevention is worth a pound of cure.
Be proactive instead of reactive.
Curiosity is a sign of intelligence.
Garbage in, garbage out.
Do you want to lead or follow.
Can you see the bigger picture.
etc.
Or they're not particularly detail-oriented; destined to be coding someone else's spec, smart or not. Always thought people are motivated or they're not; you can't motivate them.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
First thing I do is tell someone if you ever feel even a tiny bit like the code you're writing isn't up to snuff make a // TODO: statement for it. If they're using visual studio you can get those to show up in your tasks list.
Tell them the idea behind getting it to work well is use more TODOs. Learn to rely on them
Then:
Tell them the idea behind a release is to reduce or eliminate the todos in their code.
It's not perfect, but I actually got someone to shore up their mess a little using this technique.
Real programmers use butterflies
|
|
|
|
|
Well F Me! I did not know about the task list! (But I had been using TODOs!) 
|
|
|
|
|
You can modify it under Tools | Options | Task List
and you can access it under View | Task List
Real programmers use butterflies
|
|
|
|
|
Thanks for that!
It is in the menu (View | Task List) in VS2015, but doesn't seem to be there in VS2017. But the shortcut Ctrl+\, T to get it still works.
|
|
|
|
|
Weird that it's not visible. I've never used that version, but it was always in the menu of the versions i used. it has been a feature since forever
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: if you ever feel even a tiny bit like the code you're writing isn't up to snuff make a // TODO: statement for it.
Great idea!
|
|
|
|
|
Ugh, I feel your pain.
Obviously, the code could break in the catch, so he should add a try-catch around his try-catch and also implement a catch-all fallback on the application level just in case.
Noobies, right? 
But seriously, adding a try-catch does NOT solve the problem, so next time they tell you it's fixed, or whatever, tell them it's not and they should do their elephanting job.
Their job isn't to write software that doesn't break, it's writing software that works, and there's a big difference between the two.
|
|
|
|
|
Sander Rossel wrote: adding a try-catch does NOT solve the problem, so next time they tell you it's fixed, or whatever, tell them it's not and they should do their elephanting job.
Make it a policy so any exception handler needs to send the details of said exception to a log file. No IFs or BUTs about this one.
Then be ready to justify the presence of any exception in the log file. If the log isn't clean, someone needs to try harder to prevent the exception from happening in the first place.
It's a simple rule, but when enforced consistently, errors tend to be looked at more closely.
|
|
|
|
|
I disagree - sometimes exceptions are expected, and there is an appropriate course of action that doesn't involve writing to a log. I do think it is reasonable to insist that exceptions are dealt with, even if only writing to a log, rather than silently absorbed. Some groups I've worked in have that policy. For my own code, not so much, mainly because I don't have a log, never finding them that useful.
|
|
|
|
|
hpcoder2 wrote: I disagree - sometimes exceptions are expected, and there is an appropriate course of action that doesn't involve writing to a log
Those situations exist, but they have to be few and far in-between. An empty exception handler is frowned upon by my peers where I work, and while such instances do exist in our code base, they generally have to be commented and agreed upon. Typically it's because we use a (third-party) component that we know will fail under some known circumstances, is expected to fail, and there's nothing we can do about it. However, we do know how to handle the failure as gracefully as we can and carry on...and logging it would just clobber the log with stuff we know about and are anticipating. But these really are about the only acceptable situations.
Sometimes customers have situations you never would have anticipated in a million years, and you don't have access to their systems, so the handler is there to let you know that the unexpected happened. If the handler's silent about it, there's no way you'll never know, and a problem can be unnoticed literally for years, and this is when people chalk it up to a "glitch" (the use of that word is a serious pet peeve of mine).
|
|
|
|
|
I wasn't talking about empty exception handlers. I already noted that it may be reasonable to impose writing to a log if there's nothing else to be done.
|
|
|
|
|
pair programming for the fix - one writes the code, one writes the tests ?
really strict reviews
floggings
|
|
|
|
|
Garth J Lancaster wrote: floggings
Floggings needs to be the first action.
|
|
|
|
|
"It's always easier to do it the hard way." -- Blackhart
|
|
|
|
|
Back in 1975 D.W. Barron was saying: "... once a person becomes a programmer he should become a good programmer, part of becoming a good programmer is a continuing desire to become a better programmer...".
Point what is wrong and see if there is a desire to improve. If there is no desire, there is nothing anyone can do. It's just the sad case of a bright mind with a lack of spark.
Mircea
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
