Slashdot Mirror
Programming Marathons?
Mattygfunk asks: "Coming to the submission date of a major university project the other day, myself and another group member coded in XHTML/CSS and ASP (yuk!) for 27 hours straight to complete it. What is the longest Slashdot readers have coded in a single session? Apart from being more organized and having plenty of coffee, do you have any tips on getting through ultra-long coding sessions?"
Don't.
At university, a few friends and I spent most of a week in a particular terminal room with no windows or natural light, without any sleep. We had left a six-month group project until the week before.
As I remember it (it's pretty hazy!) we washed Pro-Plus tablets down with a lot of coffee, Coke, Red Bull, etc. I think we were awake for over four days continuously. One of my friends finally went to sleep in an armchair in the common room opposite, just before the deadline. We failed to wake him, even by slapping him. Sometime during the last day, I started shouting rather than speaking, though I wasn't aware of it.
Believe it or not, we got a passing grade. I have absolutely no recollection of the quality of the code.
There's one strange phenomenon I experience after a lot of coding: it feels like my hands are connected directly to my shoulders, and my eyes seem to zoom in so the screen fills my vision. I code faster and better, but it's really weird. Does anyone else get this?
Keep a separate piece of paper (sticky note, open text file, whatever) for jotting down reminders on how to do things better/correctly for when the code you're currently slamming out fails, and you need to go back and do it over again.
Not if it fails, when.
The human brain requires sleep. Deprive it and your work suffers. Trying to convince yourself (or your boss) of anything else is fucking moronic and a recipe for failure. Maybe you think that's acceptable in the short term, in which case I'm glad I don't work with you on any projects.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
What is the longest Slashdot readers have coded in a single session?
10-15 minutes tops. phew..
cpeterso
Given sufficient quantities of caffeine, humans working in shifts need only about three hours of sleep a day for 4-5 days.
Of course you were able to stay up for 27 hours. But if you had had 3 hours of sleep after the first 18, your next six would have been far more productive than the 9 hours you actually got to code.
Also, you'd be amazed how SMART taking a 3-hour break, with code swimming around your head, will make you.
I think if there's a team up continuously, hard at work on an exciting project, then 5-7 days of 3 hours a night ought to be doable.
Personally, I have done this (but without a team) on a few weekends, when I had very exciting code I was working on.
A semi-recent experience: came home friday (not this past one) and coded till 4 in the morning, fell asleep at the keyboard until the sun woke me seven-ish, saw my project on the screen (well, under the screensaver), so I got up, drank a bit of coffee, and sat down and coded continuously until the afternoon, ate something, coded more. I didn't have incentive to finish by monday and be really tired during the beginning of the week, so i went to bed around 9 and slept till 9 in the morning (thus friday and saturday averaged to 7.5 hours of sleep), but I know that I could have again gotten only a few hours of sleep and coded all of sunday as well.
I think that 48 minus 6 (for sleep) hours of continuous coding is about the extent someone can do without really really pushing herself or himself.
So, take-home lesson:
When people say that it really makes a difference to take a break from coding once in awhile, to get your head together and get a big picture of the project, maybe realize some of your mistakes while you still have time to change them, they mean it.
TAKE BREAKS, PEOPLE!!!!
At the very least, sleep 3 hours out of every twenty four.
(On the other hand, I believe that six-hour nights are sustainable indefinitely.)
While I haven't gone quite 27 hours, I have gone 18+ hours in Perl and PHP. These are the only pieces of advice I can offer:
-Windows open: Fresh Air + Sunlight = GOOD!
-Music up: Radio or playlist, either way try to get a variety of songs/music you know.
-Multitask: Well, this might make it not an exclusive coding session, but having AOL IM/ICQ open to talk to people makes it more bareable than it would be otherwise. Also, having an internet window open just at a random site makes it easy to take short 30 second 'breaks'.
-Swivel Chair/Titlty Chair: So you can move around some and 'stretch' out.
-Coffee/Mountain Dew/Jolt/Bawls/Etc: 'nough said
-Food: Good snacks that don't really drain you. For me, these include things like Cashews, Chex Party Mix, and Kettle Chips (if you haven't had these potato chips, SHAME ON YOU!). Avoid anything that is really sugar-rich though, as it'll give you that little boost, then kill ya and make you want to sleep. Wanting to sleep=bad code.
Don't let the cleaning company set the alarm on you.
I got an adrenaline boost once when a cop pulled his gun and started screaming at me. I had been running around in my socks, checking on a couple of systems. This guy was seriously amped and very pissed when he found out that I didn't deserve a beating. Luckily his partner was calm, and chuckling a little. The cop that was pissed kept asking me what my boss would do if he knew I was working all night. All I could do was laugh and tell him my boss better damn well be pleased. That didn't help the situation...
I once worked 54 hours straight building sets for a play at my old high school. I went home, got 4 hours of sleep, cooked "breakfast" for all the people sleeping on the floor of my apartment, and went back for another 30+ hours to finish it (things got a little hazy towards the end there).
;-)
I didn't do caffeine at the time, either (I was one of those wacky straight-edge punks). Regular physical activity keeps the blood flowing and the limbs from cramping up or going to sleep. We also had a hot chick that brought us pizza every 6-12 hours, which is key
Under capitalism man exploits man. Under communism it's the other way around.
do you have any tips on getting through ultra-long coding sessions?
... ponders ... ponders ...
Yeah, remember the pain and agony of those 27 hours, realize that it's impossible to write quality programs with that strategy, and never do it again!
It's even more fun when clueless mangement tries to get you to do that in the Real World. Feh...
Oh well, Back to my job search!
"Can of worms? The can is open... the worms are everywhere."
Yeah. Grey ones.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"STDOUT> 2500 lines undocumented PERL.
By a stroke of luck it actually worked and did what I wanted it to do.
I do however count not having to ever make any changes to it as the luckiest thing after simply making it. After too much work and wayyyy too much coffee you start writing things that are completely impossible to work out once you're in a sane state of mind again. Basically the type of thing Frost would have written had he known PERL...
The best way to approach a project like this is with a thirst for discovery and new experience and [let me emphasise this] no intention whatsoever of deploying the results in a production environment.... ever
It's not that I'm Anti-American - I'm Pro-Freedom
The most I've ever actually coded in a single session would be around 35 hours or so. However, I've had the lucky experience of having 100+ hour work weeks of coding, mainly due to the fact that I was recently employed (and so very eager to do a good job), and my boss was of the type to think that everything had to be done yesterday, and that any price was worth paying to get it done.
;) I sure can't do it, but I really have to hand it to the people who can.
Needless to say, I burned out like a match. The best thing I can suggest for anyone stuck doing this is to use it as an education lesson. No matter how much caffeine you want to put through your body, your mind simply can't take that much. In the end, I was writing code that all ended up being rewritten and reworked several months later when I realized I hadn't seen the big picture.
Even more important than learning the lesson yourself, use it to teach your boss(es) the same lesson. We all know a lot of managers don't understand the process, and think that pushing their programmers to work insane hours is somehow more productive. Make sure you document any setbacks or roadblocks you encounter because of programming under such conditions, and make sure you explain each and every one of them. It might take a bit, but they do get the point, and soon you'll be on your way to a good programming schedule, and doing things the productive way.
Of course, if you're one of those guys who *can* program for 100 hours a week and put in all this extra time without making mistakes, you're probably doomed.
You want to know the number-one tip for surviving a coding death-march? Don't start. Number two? Make sure you have competent coworkers who won't get you into a mess requiring a marathon session.
Story times, boys and girls, posted anonymously to protect the guilty. I work for a smallish company that, until March of 2000, employed the most self-conceited programmer I have ever met. He bragged about his skills to anyone and everyone--worse yet, he had a way of convincing other non-programmers that he was the god of code. Unfortunately, among the people he snowed was the boss, which would play itself out in a rather dramatic way. There were five others in the department, including myself, and while we couldn't stand him, we put up with him because he managed to produce reasonably good work on time. So when he bragged to the boss how good he was, we sighed and said nothing.
Our little company hit the jackpot when we got a juicy contract from another company in the aerospace business. They wanted what basically amounted to a sophisticated tracking system--in other words, given in-bound object X, calculate speed and trajectory, and extrapolate from a stinkin' huge database its probable identity and (from an even huger database) its probable targets. In other words, it was important to be able to distinguish say, between a passanger jet and a SCUD missle. The boss immediately assigns the code god to what he considers the toughest part: the extrapolation of identity and targets.
A couple of months go by, and we start noticing a disturbing trend. The god of code has submitted less and less code to the versioning system, until it drops to zero. He insists that he is hard at work, and just doesn't want to commit anything because, in his words, "It's too delicate at this point--I need to toughen it up before I'll feel comfortable commiting it." This is code, and not some greenhouse flower we are talking about. Nevertheless, he convinces the boss everything is fine. Time passes. We only have three days before our first demo date, and even the boss is beginning to have doubts. Finally, he approaches the code god and demands that he commit the code that he has written so that we can all start debugging the system for the demo. Nothin' doing. The boss calls him into his office. We hear their voices gradually rise, until suddenly things get very quiet.
I get called to the boss's office. Mr. code god is staring at the floor and doesn't look up. The boss tells me to take his computer out of the cubicle, along with any notes, papers, and files, and put it in the spare cubicle, where I am to review his code.
In five month, the guy had managed to produce a beautiful GUI for NT, something that wasn't even speced for, a complete API for querying the system (which was the last thing he submitted) and managed to write not one line of code for identification and extrapolation. Turns out that he couldn't figure out how to do it, and was too embarrassed to ask for help. Three days left to go before the first product demo, and the very heart of the project had not even been started.
We quickly decided that we would have to fake the demo. The sales guy, who was a really cool guy, explained how he thought we could salvage the demo. Basically, it was nothing more than a script. The system would correctly identify each object and spit out a list of possible targets because it was told, along with the telemetry data, what to say. To prevent the guys from snooping around too much, we took the GUI that Code God has made and "configured" it so that whenever anything was done outside of the scripted parameters, it would freeze up NT, requiring a reboot. I'm ashamed to say it, but it worked. The reviewers were very impressed with the GUI, and with how well the system responded to random data, but were disappointed to hear that there were still bugs in the frontend that needed resolving.
Then came the death march--one month filled with 120 hour weeks. During the final week, I got three hours of sleep. None of the other guys fared much better. But we delivered a working system that had a fantastic frontend.
As for Mr. Code God, we never heard from him again. But if you happen to suspect that you are using our program, you can easily find a little Easter Egg we put in at the last minute: create a new object, entitled "Code God" (Caps necessary) and with a range factor of 666. Leave all the other fields blank, and submit it. You'll see his image (I wish we could have photoshopped it) and some choice words. Don't worry about deleting the entry--it will delete itself once you click on the "Kill me now" button...
I know everyone likes to brag about how many dozens of hours they worked in a row to finish some critical project. I know that most programmers think they can live on coffee and pizza and Mountian Dew (and no sleep) for days and days and still stay razor sharp...but unfortunatly reality disagrees with you. My experience has shown that almost all programmers start to lose effiency after the 10 hour mark, and by the time you hit 18 hours or so, you're better off just getting some sleep and picking it back up in the morning.
Now I'm sure I'm going to get barraged with anecdotes of projects saved from disaster by marathon coding sessions, but ask yourself this important question...Why was it necessary to do this in the first place? When it comes to software development, it's not like it sneaks up on you. Yeah, sure, deadlines get pushed up and requirements gets changed, but the software industry is not the only one that has to deal with the slings and arrows of trying to get shit done in the real world. Which begs the question, why does it happen?
The reason it happens is because we let it happen. Some of us almost WANT it to happen so we can get our marathon coding merit badge and show it off as some trophy of programming prowess. Whenever a manager makes some comment like "Well, I don't think we can make the schedule, but hopefully we'll pull it together at the end" my resume starts shooting out of the office printer. Don't tolerate it. It's simply not professional. If shit happens...adjust the schedule or trim functionality. As demonstrated by Brooks in "The Mythical Man Month", those are pretty much your only two reasonable options. Turning your development staff into a bunch of zombies is just Bad Form. DON'T put up with it.
My advice: this is not something you want to do.
However, there are times when you know you aren't going to get your work done in the time allotted, no matter how hard you work. So, you have to work smarter, with better tools. Problem is, you don't have the tools. So, you get the insane idea to build them.
Let me rephrase this another way: You can't do what you have to in, say eight weeks, much less the two that you have, so, you figure out what you need to be able to do it in one week, and spend the other week building that. As crazy as this sounds sometimes it is a viable plan.
Sometimes the meta problem is easier to visualize, specify, and code than the problem itself.
Of course this requires a clear mind, focused on the task at hand, and more than a little courage: after all instead of 25% productivity for the time available, you expect to be at 0% real productivity for half of it and 200% for the other half. There ain't no guarantee that you're gonna be right. These kind of risks are best not mentioned to management weenies and those without the stomach for technical roller-coasters.
Others have mentioned that such hurculean efforts result in shitty code. Sure, you throw all the software engineering processes away, because they are just too heavyweight for that sort of thing. This is extreme programming at it's finest -- pipelined design, development, and test. Still, it will lack a certain, er, polish, and possibly robustness. But, you have an ace up your sleave.
See, you don't have to solve the meta problem of providing the tools to solve any real problem of a particular class on time -- you just have to solve it so it provides the tools for the particular problem you've got. Just make sure that whatever bugs there are don't manifest themselves on the particular data you have to deal with now.
Of course, anything that improves productivity is a good thing, right? Why not always take this approach?
Because solving meta problems instead of "getting one's job done" is not "getting one's job done" except in the kind of impossible deadline situations I mentioned. It's a pity, but that's probably not the business you're in -- while a particular C++ preprocessor to instrument memory allocation/deallocation and pointer dereferences might be a great product in it's own right, you just need to find the memory leaks in the code for which you have a customer.
Of course, with good project management, you won't find yourself in such situations, but such ideal circumstances rarely arise.
You could've hired me.
A few years back at Purdue, I was in EE365, the microprocessor design course for EE and CmpE undergrads. Through a terrible mishap involving rm and a misplaced whitespace character, our project directory (finished, and working with a few minor bugs) got wiped while trying to clean out some Mentor Graphics temp files. All the schematics, all the VHDL, all the whatever. *poof* One week to go.
Now, there were plenty of workstations available-- many more than there were teams working in the class. Unfortunately, most of them were old 50MHz machines. Not quite enough to do the simulations in a timely fashion. As in, not quite enough to get *any* of them done in a week.
There were, however, 6 or 8 HP VISE workstations that just screamed. Obviously, in high demand. So, my partner and I waited until one opened at 3 in the morning, and proceeded to camp it out for an entire week. We took shifts, brought eachother food, and covered eachothers' classes. The last two days we were there straight through.
I have never been more tired in my life, but we got it done.
My advice? Don't do it. Make backups. If, like us, making a backup would be bigger than your disk quota and took too long to send home via a modem-- MAKE THEM RAISE YOUR QUOTA.
I started my procrastinating career and thus all nighter practice way back in high school. But it wasn't until I saw coverage of the 1986 Race Across America that I saw what is truely required for a multi day push. The RAAM is a bike race starting on the West Coast of America and finishing on the East Coast. Unlike most other races this one isn't broken into stages. It's simply a matter of who can get there first. In 1986 a man named Pete Penseyres set the average speed record which appears to stand today. His secret was sleep management. He had someone observe him while he slept for some time before the race to determine when he would typically experience REM sleep. Then during the race, his support team would pull him off his bike, lay him down in the support van, and let him sleep until his eyes stopped moving. Then they put him on his bike and sent him off for another day of riding. The net result was obviously favorable. He had competition that was actually faster but nobody was as consistent. Those who would have beat him almost always crashed while hallucinating from lack of REM sleep. So those here who are preaching the "3 hour break", I think are on to something.
Here are some tips that I find especially useful for a session like this -
-There more concentrated the caffine solution, the longer you can remain awake without having to pee.
-Prepare all food and string in a mushy liquid-like substance, it will save on precious coding time.
-Remember all of the corner-cutters that you were told never to take? They are now your best friends.
-Do not bring any firearms into the room.
-If you wish, bring music, but be sure it doesn't have words to it or give you an urge to dance.
-If nature calls, wait until it's SCREAMING!
-If another person(s) will come within 100m of you during the coding time (and are not on the team), be sure to have restraining orders in effect.
-And most of all - have fun (well, maybe not).