The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
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
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."
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
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.
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.
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.
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.
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).
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.
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
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.”
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.
Last Visit: 13-Aug-20 20:04 Last Update: 13-Aug-20 20:04