|
It was possible that this developer would be sent to us to keep working on those projects. He declined, but if that had happened I would have preferred to help him. It would not have been easy, but then we could have used the situation to neverybody's benefit. But it's very hard to teach an old dog new tricks.
At least artificial intelligence already is superior to natural stupidity
modified 4-May-12 8:44am.
|
|
|
|
|
Good point. I'm tainted by my current position where some one up the food chain is the absolute worst programmer I've met in my 12 years developing software. And because she's up the food chain, I have no ability to influence any changes in her coding style, and she reports to some one non-technical so nothing is ever going to change. If I could tar, feather, and fire her...
CDP1802 wrote: we could have used the situation to neverybody's benefit
Freudian slip?
|
|
|
|
|
Jeremy Hutchinson wrote: If I could tar, feather, and fire her...
... and terminate her employment afterwards?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Jeremy Hutchinson wrote: Freudian slip?
Must be. It could not even be explained with fat fingers 
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
It looks like German, I think you've already figured that out.
I've had the pleasure in the past of maintaining code with variables and function names written in Russian, Polish and Hebrew.
Good Times.
|
|
|
|
|
Ummm. 350 lines?
I once worked for a customer that had a rolled their antenna control state machine into a single 12,000 line method. It was coded as a single loop with a switch statement, and used various means of state caching to achieve nesting.
The part of the code I had to modify was down around line 17,000 of the file, which caused the Visual Studio editor of the era to get confused about where to insert characters. I did most of the modifications in WordPad.
|
|
|
|
|
A bunch of try/catch, poorly written serial code, isn't spaggetti code (irritating and difficult to understand/debug, yes)
A real "S" epic has about 4-5k lines in one routine, conditionals on most of the branches, a bit of dead code thrown in, and logic similar to:
goto 123
3000 continue
goto 3214
10 continue
goto 143
5130 continue
exit
1634 continue
goto 3214
123 continue
goto 10
3214 continue
goto 5130
143 continue
goto 3000
|
|
|
|
|
I start a project in 2nd april, i finished it 8th april, the tester tested the project and pass 9th april and client get happy on that,
suddenly in 13 april my project stop sending data, which is one of its main functionality.
i was wonder why why my code works only 5 days, what happens, there is nothing changed why data was not sending now. suddenly i discovered what was the fault, because from 1st may it again start to work and i am confident it will work until 12th may, and then it will again stop  .
i think u already get the hint, problem was date time format in server and client side.
mm-dd-yy and dd-mm-yy , for that it will only work 1st 12 days of a month, not bad 
|
|
|
|
|
kdgupta87 wrote: suddenly in 13 april my project stop sending data, which is one of its main
functionality
Here you accidentally already wrote the solution. It's not a bug, stopping to send stuff is a feature.
And welcome to the ever growing club of people who have learned the value of date datatypes/classes over some casual string manipulations
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
why all over the world, everyone not following the same date time format, they should think about poor programmers like me 
|
|
|
|
|
That's another lesson to be learned the hard way. Users never waste any thought about helping us. For them you are a wizard and they don't want to know what sinister things you have to do for your magic. But they still want the miracles yesterday, for free and without any inconveniences 
At least artificial intelligence already is superior to natural stupidity
modified 2-May-12 5:06am.
|
|
|
|
|
We do; it's called ISO 8601.
|
|
|
|
|
No - see - it's actually done to give us a boost in morale by allowing us to feel superior!!
|
|
|
|
|
There's a lesson to learn here about using an unambiguous date format. If you have to use string date transfer at all, that is, but for passing data between applications that is often the case (e.g. if you're using web services or similar protocols). I use either 2012-05-02 or 2-May-2012, usually the former, if I'm saving or passing dates and need to be able to understand them at the other end.
Your tester should have tested this, though. That's the point of having a tester.
|
|
|
|
|
Sure, but now we also have a tester and a developer who will probably not forget this in the future. The sum of such experiences is what counts. People always learn more by their mistakes than by success.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Oh, that's definitely true. And it sounds like it was a relatively low tariff place to make the mistake (easy to notice, easy to find the cause and fix, not a critical system), so all's good in the end. But it is more a tester mistake than a dev mistake, in my opinion.
|
|
|
|
|
Doesn't sound like it's anything the tester could have tested if it's a system date related issue. If the date was data the tester entered I agree, but that's not how I read it.
|
|
|
|
|
I agree. Testers cannot test -everything- ... That is like expecting a coder to produce bug free code.
In my experience, testers test functions against spec, and then test data/input (boundary conditions, extremes, absence, ridiculous) and call it a day. Unfortunately, this low hanging fruit approach leaves sneaky, subtle bugs like this undetected.
|
|
|
|
|
IMO it's a beginner programmer's mistake - anybody who has ever done a web app has learnt this lesson the same way. It isn't often that testers find this type of error - usually programmers, or whatever library or framework they use take care of this.
|
|
|
|
|
the most logic date time format for me is dd-mm-YYYY.
|
|
|
|
|
When you want to say 10001 you say "ten thousand and one" and not "one ten thousand".
I think it is a mark and as such it should start with the biggest aproach and then go refine to the day as you do with hour minute second...
Paulo Gomes
Over and Out
|
|
|
|
|
In dutch it is different.
62 you say " sixty two"
but in dutch you say "twee en zestig" = "two and sixty"
we also use the metric system
|
|
|
|
|
Oh, you're gonna discuss date preferences now?! Then what ... coding style? How about favorite colour?
|
|
|
|
|
Watch out everybody the discussion police is here..
|
|
|
|
|
I was merely, sarcastically, suggesting that such things will never be agreed upon. Heck, I live in a country [US] that uses pounds and inches to measure things. We also use a format for our dates that, as far as I can tell, is not used outside the US.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
