Fog Creek Software
Discussion Board




Drinking fine red wines whilst writing code.

I've found this to be particularily effective, what have you found? What euphorics have worked for you? Also loud music is good, particularily whilst influenced by other things.
In fact, I've only needed to be sober once for 5 minutes once  when I was writing a compiler, so banal are the most common programming tasks/technologies. Usually I am doing ten other things at once while I am working on IT stuff. What "real" things do you do when you are "working" writing software?

Mr Successful
Saturday, November 24, 2001

I find that my LOC productivity increases when I type with one hand.

Mr. Happy
Saturday, November 24, 2001

I find this whole thread to be really funny, but I still hope it gets deleted 'cause it is sort of inane.  And I can go elsewhere for humor.

Still, criticism noted, if we are getting too full of ourselves.  Though if anyone wants to talk about how we're in a computing dark age, let's keep this discussion up because it probably is true.  We really do have to put up with tools which resist mechanizing all sorts of mindless tasks.

forgotten gentleman
Saturday, November 24, 2001

I admit my experiance w/ CUI (coding under the influence) is minimal, I suspect that very little can increase true productivity. For one thing, what if you finish without a clear understanding of what you wrote? If you are not thinking clearly, that could lead to bugs, even if a stimulant or some drug increases 'productivity'. Besides, the really tough problems I find I benefit more from a break than intense, unceasing, study. OTOH, the easy ones should be solved naturally through experiance.



Productivity == writing GOOD code. Do not judge your productivity by LOC, but by maybe a features to bugs ratio or something. I'm thinking getting really hopped up on caffeine like my friends do sometimes is more likely to increase typos (some of which, we all know, can be really bitchy if they are not syntax issues), and probably lines of code too, if only because of greater wetware uptime ;) But that doesn't mean that you are writing GOOD code there, either.

Mike Swieton
Sunday, November 25, 2001

Yes I agree with Mike, my bug ratio is approaching zero after a decent Shiraz, and if I wash that down with a decent Cabernet Sauvignon it becomes zero. Added to that, if I pass out and my head lands on the keyboard, I can write a zillion LOC.

Mr Successful
Monday, November 26, 2001

Just my 0.02 euros worth:

I think Joel and Larry do agree.

One problem we had was with the handling in dates in SQL server.  Theres a bug with SQL that when the server gets restarted the date format is set to the american standard month/day/year.  Here in the UK we use day/month/year.

After a powedown the server that runs SQL Server for use was restarted.  This was half way through the month.  The server restarted no problem.  None of us realised that the date format was changed.

Our sql statement contained dates like 15/1/2001.  SQL server was liberal in interpreting this for us.  When it realised that this wasn't a valid US format, it interpreted it as a UK format and all was well.

Two weeks later we start getting crazy results from our queries.  It was difficult to realise why.  None of use considered a power down two weeks ago.

The problem was that now we were using dates like 1/2/200.  Second of January, a good old American date.

It would have been better if the Server had been less liberal, and insted gave us a useful error message when we restarted and tested the server.

I think the problem is with hidden complexity.  If a problem is complicated, you shouldn't try to ignore it or hide it.  In this example, microsoft had oversimplified the handling of date formats.

You can oversimplify this within the API.  You could say that dates must always be in the format yyyy/mm/dd.  The problem is, as Larry Wall says, you are 'sweeping the universe's complexity under the carpet of the programmer.'  Programmers are forced to write their own code to deal with the multitude of date problems.

You can hide the complexity by having the computer make unknown assumptions, such as SQL servers handling of an illegal american date.

What you need to do is recognise complexity.  If an issue is complex, then recognise that and make it known.  Provide the necessary tools needed to cope with complexity.

Joel recognises this in his article about computer science's mistakes.  (http://www.joelonsoftware.com/articles/fog0000000041.html)  You can't treat network resources like local resources because accessing them is more complicated.  Therefore if you try to make it simple so they behave just like local files then it won't work.  You need to have a complex toolkit to deal with the complex issues.

I think this is what Larry Wall is saying.  A programming language, like Perl, needs to be complicated to deal with complicated problems.

Ged Byrne
Tuesday, November 27, 2001

Dates in SQL Server is enough to make you CUI! I think most of the world (outside the states) has issues with dates, day lightsavings etc.
I have seen SQL actually fail returning an incorrect date when servers in Australia's state of Queenslands day light savings kick in.

Paul Berger
Saturday, December 01, 2001

I spose SQL Server was outside that compatable set of date/time functions within Microsoft that Joel assured Bill Gates on then.  :-)

Simon Lucy
Tuesday, December 04, 2001

*  Recent Topics

*  Fog Creek Home