|
"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
|
|
|
|
|
I never had much shame - if I see such attitude (and the age of the sinner irrelevant) I do speak - and aloud...
But seriously - speaking about such things is mostly helpful with intelligent, grwon-up people...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: speaking about such things is mostly helpful with intelligent, grwon-up people...
Exactly. And fortunately this person does listen.
As an aside, I find that speaking is overrated - most people don't have the skill to listen. And a corollary, the more a person talks, the less skill they have at listening.
|
|
|
|
|
I think applying quick kludge type fixes is okay with perhaps a ToDo tag with a note of some sort that is added to that code.
While software developers are in the business of writing beautiful elegant code, they are also in business and depend on providing the customer with a working solution so that their wages can be paid.
That beautiful elegant code is itself impermanent, so concentrating too much on the most elegant solution can be an exercise in imitating Ozymandias.
On the other extreme, apparently Oracle is something of a mess(English understatement) from a development point of view but they certainly bring in the money.
But adding try catch as a solution is not great unless that exception is logged somewhere within the catch.
Swallowing exceptions is generally a bad idea and perhaps that's what needs to be explained to them.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
There is no short-cut to knowledge. The best way for this person to learn is for someone more experienced to pass their experience down and explain why their solution was not the best one. If they really are smart they will understand. No-one writes perfect code from the off, the only ways we learn is a) by our mistakes (expensive) b) having someone who knows better teach us (cheap). This issue has let you swap "a" for "b"
|
|
|
|
|
Without more detail, it's hard to give specific advice. I'm presuming from your question that you've done a code review or studied this problem, so you have a valid reason for wanting to go further.
Seems as if a review is in order. Ask them to defend their implementation, and come prepared with your ideas to provide guidance and education on why a more thorough change is necessary. Try to guide them into thinking deeper..."what about situation X?"...so they understand the way you see the problem and can apply that to other problems, not just "I'll just go implement Marc's suggestions."
Who knows, maybe after a discussion, it might even be you that comes around. Maybe it's not necessary to refactor as much as you see.
Also remember that's it's o.k. to do a temporary fix with the intention of going deeper later for reasons of budget/time/etc. Document the full-featured change in change control, make it a story with some priority, and make sure that documentation includes the quick fix to keep things running along.
|
|
|
|
|
Create a check in trigger that rejects any delta that contains both "try" and "catch".
Or is that just another "first solution" answer.
|
|
|
|
|
englebart wrote: Create a check in trigger that rejects any delta that contains both "try" and "catch".
That is an excellent idea! 
|
|
|
|
|
I work with a guy like that. The solution to any problem always lies along the straightest possible line between the problem and the desired solution state. He's very good at this sort of thing, and it works in the short term, but we've learned to follow up on anything he does to make sure his corrections make senses in the broader scheme of things.
I'm not being critical of the guy either - he has an amazing talent for going from a vague problem description to the region of code where the core of the problem lies, even when he didn't write the code himself.
Software Zen: delete this;
|
|
|
|
|
This sounds a lot like "how do you teach someone to think?". I'm not sure if you can, but in the past I've given instructions like "Come back and tell me five different ways of solving this". They find the first answer but then have to chew the pencil a while.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
