|
A code review should have caught the duplication.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Matt Bond wrote: A code review should have caught the duplication.
Yes, but this was a long while ago now -- around 2000 -- and this particular place allowed developers to work autonomously. Each dev managed his/her own services.
That's good and bad, I know.
That was a great thing if you were apt to do it all and "own" your stuff.
This guy was not up for that though and it became obvious in production some time after midnight. 
|
|
|
|
|
I'm with you on that. One of the things that I find frustrating with some so-called devs, is not that the lack the fundamentals, but they seem not to have any idea what to do if things go wrong. If their code does not run or throws an error they are incapable of doing some basic diagnosis. There have also been three questions posted here in the last few days from people who are trying to use third-party products. They don't know the product, or some part does not do what they want, so rather than going back where they got it from and asking people who would know, they post a question here. Similarly with homework questions under "what have I done", we see things like, "nothing because I don't know how to start". I just hope that all the developers who never post a question here are of a much higher calibre.
|
|
|
|
|
Yes, a sea change from the days when I used to debug in hex, over the phone.
Eliminating possible causes of a bug until, to steal a phrase, what remains must be the truth, requires the ability to think deductively, which is rooted in logic. In an age where emotions are treated like facts, the ability to debug this way is severely compromised.
|
|
|
|
|
I got a job after debugging by phone.
I was working in Germany using software from a company in the US. There was an intermittent bug that was driving us crazy and the company could not fix it. The president of the company had me describe the bug in detail to one of his developers so they "could better fix it". I ended up describing to him the steps it must have gone through and the kind of code it must be running at the point the bug came up - he found the appropriate code and I said something like:
"...and then it will have a pointer to a block that it constructs the message string in before adding the terminating null at the end of the string";
"Yes, there is a pointer for the message";
"Has it allocated enough memory for the block? Perhaps it didn't allow for the terminator.";
"Allocated memory?";
...at which point the problem was solved! The president had been listening in on the call and immediately offered me a job.
Ah, the good old days!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
Richard MacCutchan wrote: what have I done", we see things like, "nothing because I don't know how to start".
You are correct about many devs not being able to debug. It is probably why the ability to debug, or just get something going again when it is stuck, is probably the number one ability to look for in a dev.
- Brian W. Kernighan "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
|
|
|
|
|
|
DerekT-P wrote: we learned how to dismantle things!
I did much the same at home. Like you I did not always understand how the things worked but I did learn how to try and find out.
|
|
|
|
|
Funny. My uncle and some of his other retired buddies took over the science department at a private school. Labs include multi week disassembly of small 4 cycle engines, using long cables like jump ropes to detect Earth's magnetic field, etc. Sounds like a similar mindset.
|
|
|
|
|
My elder brother loved to dismantle things to see how they worked. 
I had to figure out how they worked so I could out them back together again - a skill my brother never quite got the hang of.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
My elder brother was too busy chasing skirt to care about the internal workings of any machine.
|
|
|
|
|
I dismantled a lot of things before I learned how to put them back together. 
|
|
|
|
|
I certainly don't want to go back to finding the appropriate MSDN documentation CD out of the folder of 12 that will have the documentation for Substring as I don't know if it is SubString or Substring as IntelliSense hasn't been invented either.
The internet has certainly made it easier to plagiarise though and has defo made it easier to find examples of larger sections of code, as well as (obviously) places people can just post their homework expecting someone else to do it for them. I'd hate to be a lecturer these days, half the job must be trying to work out if people have got others to do their work.
|
|
|
|
|
the CDs were horrible, ended up getting a second hard drive just to load up the MSDN library, but the information did tend to be more technically accurate with actual examples (for the most part)
I can't tell you how many times working with a new API lately and I look up the docs and it only has the name and the signature like:
void ThisIsSomeSortOfAPI(int count)
param int count - count to pass to API
defination: This is Some Sort Of API
I'm like thanks that is so helpful
|
|
|
|
|
F-ES Sitecore wrote: I'd hate to be a lecturer these days, half the job must be trying to work out if people have got others to do their work.
True, but you could probably weed most of them out just by asking a specific question about "their" code. They'll end up convicting themselves.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
My daughter is a TA/grader for one of those classes. First thing each week, find answers to home work online. Then she can tell if someone just copied and pasted them for their own answer.
|
|
|
|
|
Quote: I'd hate to be a lecturer these days
For three years, way back in the dusty past, I was a professor of Computer Science at a Polytechnic. The syllabus hardly changed from one year to the next. Forty percent of it was "History of Computing", in the third year that was reduced to twenty-five percent but a lot of it was the same. Computers were nearly all mainframes with mini-computers becoming popular (not micros - minis, PCs had not been invented yet). I left to get a proper job. 
Back then I thought I knew most of what there was to know; these days, well...! 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I only miss the pre-internet days and early internet days for nostalgic reasons. I am 1000% more effective and productive now as a software engineer/developer than I was back then, and that is not just experience over time.
Also, knowing how to debug is key to being a successful developer, just as Richard mentioned in earlier post reply.
"...but they seem not to have any idea what to do if things go wrong."
|
|
|
|
|
Feel like I was smarter way back then because everything was just C code, you started at main() and worked from there.
Today with the friggin' frameworks, build scripts, endpoints and so on, there's WAY to much VooDoo code floating around what I'm trying to do.
VooDoo code : Crap you're told to use but no one really understands what it does or how it does it. (Looking at you Gradle, Maven, Ant and Groovy. Oh yeah SpringBoot too.).
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
gotta love the names they give this stuff now
|
|
|
|
|
Matt McGuire wrote:
any other gray beards out there seeing the same thing?
Yep. Pre-internet, we had to know how to research. Back in grades K-10, when the teacher would give us spelling words to memorize, I would write them down dozens of times, whether it was required or not. As a result, I won spelling trophies in school, and am still the go-to person today when someone wants to know how to spell words (not the ones used in spelling bees). Most kids these days can't do that if their life depended on it, probably because it takes too much time and does not produce instant results. Smartphones and video games do not help in this endeavor.
It's the difference between living in a crock-pot society vs. living in a microwave society. What's being taught in school/college these days is how to use a programming language, not how to solve problems. If they have to solve a problem and their favorite programming language is not available, they're lost.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
modified 7-Oct-20 22:29pm.
|
|
|
|
|
Having made it to retirement I :laugh: :laugh: :laugh: I dodged the whole web programming debacle.
However I do not regret the coming of the internet, productivity for an experienced developer went through the roof, having the resources at your fingertip made life much simpler.
What did horrify me was when the young whippersnappers moved to python and spent their entire time grabbing bits and pieces from the internet to build an application.
Ah sunny Cairns I love it, I'll just wander off and take the dogs for a swim.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I wasn't around back in the day, but I can't believe people were more productive back then, having to go through magazines and books and scan pages and pages to find the solution...
Also, things go fast now, but I'm always amazed at how many languages there were back in the day.
Not to mention types of hardware.
And those went fast too.
Things probably moved just as fast, it's just that you didn't hear about it.
I mean, COBOL, released in 1960, had multiple versions and compilers by 1963.
From Wikipedia: "The COBOL specification was revised three times in the five years after its publication. COBOL-60 was replaced in 1961 by COBOL-61. This was then replaced by the COBOL-61 Extended specifications in 1963, which introduced the sort and report writer facilities."
Another popular language from that time, ALGOL, got three additional implementations in 1960 and four in 1961, and that continues until 1967.
The 70's and 80's saw at least eight new popular languages (for a total of 16) and the 90's (which I consider pre-internet even though it was around) saw at least ten new popular languages.
I think we're as stable as we've ever been
|
|
|
|
|
I'd agree that the pace of change was faster back then than we tend to assume. Those of us who lived through it are getting on a bit now and everything seems fast to us now.
However I do think we were pretty productive back then. Writing out COBOL on coding sheets in pencil was horrendously slow, but before you picked up a coding pad you knew exactly what you needed to do and had done "dry runs" on paper, and probably discussed every line of code with a colleague. Once the punch girls had done their stuff, which they were generally very accurate with, there was a very good chance that the code would run exactly as per spec. We did only a little re-working of code. Also, because everything was long-winded, the code didn't get extraneous "bells and whistles" that today's idle fingers end up stuffing every application with. (Yes, I'm guilty of that too).
Later on I was supporting overnight batch jobs. A suite might involve 15 - 20 separate programs, each (when printed) being a pile of COBOL about 3" - 4" thick. When the bleeper went, it was out with the 600-baud modem and teletype, to get the memory + register dump of the failure (90% of the time it was a S0C7 exception). Then you had to pinpoint the line(s) of code, print out as little as possible of that bit to work out a fix (no time for testing, the overnight schedule was tight enough as it was), compile it and restart pronto. No need for manuals, your only tool / language was COBOL and you knew every verb and operator of that inside out.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
