|
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
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
