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.
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.
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.
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.
I'll back that up by saying I'd employ a smart, pragmatic problem solver who is open and honest and shows they can learn over someone who 5 years of experience but who won't expand their skills or is an arrogant SOB any day of the week.
Knowing a tech is super handy and a headstart for sure, but an employee is always going to have to learn a bunch of other stuff anyway so a solid, well-documented franework or service is the least of the worries.
Oh, and Fake it till you Make it seems to work too.
That's actually a tough one. It's not like desktop development is directly transferable to Azure development, even if you are "one smart cookie." The company will incur a cost for your learning curve.
So I guess I'd say that - something along the lines of "I'm in the process of getting a certificate...and I realize that there will be additional learning that only actual experience can provide and I'm confident that I can minimize the cost of that to you."
Ideally, the fact that you're conscious of the issue should count for something!
It has been years since I've worked in the field, so YMMV, but my experience has been that HR people are the ones setting experience requirements, at best with input from overworked PMs or leads who really can't be bothered putting what they're looking for in those terms.
Meaning if you have a solid professional background, especially with certifications everything hinges on the interview, not whether you have ticked off all the "prerequisites"
I was a homeless teen, so I never went to college. Pretty much every job I've ever had "required" a 4 year degree or higher. And no, I didn't lie.
Suck it up and go to one of the freelance job sites and bid on as many "Azure jobs" as you can.
I "reinvented" myself (after the 2007+ downturn) as a .NET / WPF programmer by knocking off a bunch of little .NET projects (and some not so little) that allowed me to compete (and win) more substantial stuff on my own later based on the experience I gained.
All the jobs were remote, but the fact that they were all over the world (U.S., U.K., Australia, Netherlands, Germany, etc.) made my CV more interesting (perhaps).
Couldn't have gained the experience any other way, unless you want to "volunteer". Even then, there is competition (e.g. the "community" web site master).
(The trick also was to ask for any "hourly" contract, do daily status, and say the client can cancel anytime they're not satisfied ... Their biggest fear is getting screwed on a fixed bid with or without an upfront payment. So if you can keep the fear out, you've got it made. Fixed bids are OK if they're "small", but NEVER ask for more if you blew the estimate; suck it up instead if you want to maintain a reputation)
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
A combination of this and all the good advice above it too. Working small projects on PeoplePerHour and similar is actually a really good way of getting real-world experience. You'll find a lot of the projects are actually fixing other people's c**k-ups, but that exposes you to a wide range of errors to avoid. Assuming you're successful at fixing the problem, you're immediately "the best contractor I've ever hired on xxxxx", even if you've ONLY learnt how to fix that specific issue. But you can get some great review comments that you can reference on your CV, and most importantly, it demonstrates that you have actually been exposed to doing genuine "work" in whatever technology it is. The hard bit is winning your first contracts; you'll need to bid around the average price (which will be low) but wow the client with your assessment of the issue and your promise to keep them fully informed at every stage - then keep those promises. Treat the customer as an intelligent superior being (no matter how dumb they are) - at least until you've got some good reviews on your profile.
Best bit is, it's challenging, varied, opens your eyes to things you never expected - and if you're really lucky, you can earn so much you never need to be an employee again.
I've just spent 2 weeks driving all over Ontario in a massive wind-sail (or RV, as some prefer to call it).
We stayed on the shores of 3 of the Great Lakes, mountain biked as much as possible and donated litres of blood to the roughly 1 quintillion mosquitoes that had seemingly never tasted anything as delicious as Australian blood before.
Oh, and Rogers cell coverage maps are a sham and a lie. The interwebz was a long forgotten memory during the trip.