|
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.
|
|
|
|
|
I plan to pursue a certificate in Microsoft Azure fundamentals, and then one in Azure development.
However, all of the jobs require actual years of professional experience in these technologies. My current experience is in desktop LOB development.
Does anyone have any recommendations for the approach I should use when applying for such jobs?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Always tell the truth, you may be able to convince prospective employers that all you other experience counts.
|
|
|
|
|
Thank you, that's good advice. I plan to be honest.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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.
cheers
Chris Maunder
|
|
|
|
|
Thanks Chris, I appreciate you weighing in. I'm thinking about what arguments I can make along those lines now.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I hope you're refering to the impostor syndrome.
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
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!
|
|
|
|
|
Thank you for your perspective. I hadn't considered that.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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.
Real programmers use butterflies
|
|
|
|
|
Thank you for those encouraging words.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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
modified 20-Jul-20 15:09pm.
|
|
|
|
|
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.
|
|
|
|
|
PeoplePerHour, huh? I never heard of them, but will explore...
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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.
So: what did I miss?
cheers
Chris Maunder
|
|
|
|
|
We've reinstated the soapbox in your absence.
Real programmers use butterflies
|
|
|
|
|
It does not solve my Problem, but it answers my question
Chemists have exactly one rule: there are only exceptions
modified 19-Jan-21 21:04pm.
|
|
|
|
|
that's it, I'm packing my bags again.
cheers
Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
