a companion discussion area for blog.codinghorror.com

Doing Terrible Things To Your Code


#26

All I can say is that I’m terribly lucky to have a single good tester where I work. She’s vicious.

Despite the fact that we barely have automated builds, no automated deployment procedure, no integration testing framework, heck we don’t even have a modern version control system (we’re still using CVS on a Win2k box), we still manage to produce usable code, because our tester whips through common and edge cases like you wouldn’t believe.


#27

“politically correct” is a synonym for “not an ignorant neandertal”.

“If this causes you to hyperventilate and have your poor feels hurt, too bad.”

Project much.

“born with certain parts”

Biology fail.


#28

It obviously matters a whole lot to reactionary trolls.


#29

Living in Australia (southern hemisphere, GMT+10) I’ve lost track of the number of US software packages over the years that have crashed or failed because I had the temerity to enter a negative latitude or a timezone that the “everywhere is Seattle” software authors couldn’t handle. It’s generally getting better, but there’s still so much room for improvement! Oh yeah, and that entire ridiculous business of “everyone has exactly one first name, one last name and one middle initial” … let me tell you about a friend who had to go through four years of university with the middle initial X on her student card!


#31

UniSA still uses the character Y to fill in gaps in usernames for students without a middle initial or short family names.


#33

Citing religious confabulist C. S. Lewis while railing against “those who see the world as constructed by belief” is quite ironic, and more projection. But hey, we’re off topic, and have been since some misogynist reactionary ideologue took us there. Ta ta.


#34

You’ve summed up the troll well.


#35

I recently talked to a tester at Google who referred to this as a high “paranoia factor”, and bemoaned the fact that so many developers are so trusting. One should suspect bugs lurking in every nook and cranny, especially in error handling.


#36

“Paranoia factor” is exactly right. I’ve learned a lot from our tester, mostly about taking responsibility for verification of code vs. spec and spec vs. stakeholders’ ideas. She declared herself “Executive in Charge of Circling Back About That” a while ago, and that’s what she spends most of her time doing. It doesn’t help that our stakeholders change their minds more than coke-addled howler monkeys.


#37

Strongly related! The giant list of “naughty strings” for testing!


#38

I wonder if the LTR strings handling there already takes care of things like the ones which crashed iOS back a couple years:

Or if that list includes such known bugs. :stuck_out_tongue:


#39

I may be reading too much into this, but there seems to be a tacit assumption here that these issues can only be dealt with through testing, but programmers always have the option of thinking about every one of the issues listed here, at the time they first write the code or while thinking about design. Of course, that is not an alternative to testing; in fact, I quickly learned (before the Agile Manifesto) to test early, often and with automation, but all too often, I see people assuming that writing what is essentially a guess at a solution and then fixing it is the only way to write software.

I think it is important to strive to be right from the beginning, if only because there are certain areas (e.g. concurrency, security) where it is well-nigh impossible to test-and-fix your way out of a bad design.


#40

Reading it made me think of something I tried to explain to someone else once: all applications have pretty much infinite paths through them. You will never remember them all - heck you will never even find them all. That is why we need automated tests, because they can remember this stuff way, way better than we can.


#41

Hey Jeff, just wanted to know if you have any go-to debugging tools, or do you just use the debugging options used in your chosen IDE? I have heard a lot about GDB, but was wondering if there is anything else out there worth exploring?


#42

It would be interesting (and presumably computationally really hard) to have “smooth” timezones - that is, the farther you go east or west, the more your current time changes. In a smooth manner directly corresponding to when, at this point of the surface of the earth, the sun would be closest to directly above you in the sky.
Presumably that would add a lot of complexity to synchronizing your time of arrival at a given point from various starting points though.


#43

Actually…that’s how it used to be! Every town set its own local time based on when local solar noon was.

That worked great when the fastest way to travel was by horse, and nobody really expected someone from out of town to arrive at a specific time, or to take an action where they were at a coordinated time. But you can’t run a railroad, that way! As soon as rail and telegraph became a thing, coordinated time became more important. Our entire modern time zone system is the direct result of agitation by the railroads companies, to make the job of creating and publishing schedules easier!


#44

Wasn’t it more like it used to be that towns roughly set times according to local noon (rather than exactly)?
That wouldn’t work today at all. Like, even less so than setting such fluid time gradients “accurately” (within sub-second accuracy)
If you were able to do that, a railroad could be run still, since every single point on earth would have a well-defined local time and that time changes gradually. You could have computers figure it out nowadays.
Still, the amount of necessary work would not be worth it. Although it would get rid of timezone ridiculousness. For the most part. (Synching day and year is still a problem then. But doing “leap-smears” would be much more natural in that context than adding seconds or days at a time, I think)

Either way, not gonna happen.


#45

Lately I’ve been thinking that the primary difference between good programmers and bad programmers is:

  • Good programmer try to think of everything that can go wrong, every case
  • Bad programmers just try to get it working for now

If a programmer is trying to think of everything that can go wrong, eventually he/she will realize that readability is important. That structure is important. Everything follows from that principle.

If anyone has thoughts on this idea, I would like to hear them.


#47

A mega list of programming falsehoods!


#48

A great one about text edge cases, mostly unicode related: