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.
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)
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."
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
Yeah, I have begun to regularly take a nap during the afternoon. (Preferably after eating.) About an hour or so is quite fine. I can then stay up quite a lot longer and still be functional the next day. (This isn't a "I have to cram before the exam." technique, I use it regularly.)
If you can half an hour after lunch at work is often a good way to stay productive during the afternoon as well.
The best advice I can give is to work with somebody else, and talk everythring through. When you're sleep deprived, the msot important thing is to retain focus. As soon as you lose it, you'll drift off. You can knock off specific tasks from a to-do list with only half your brain working, but creative thinking, problem solving, and the like will derail really fast under sleep-dep. To alleviate this, talk things through until you have a concrete to-do list. This forces you to focus, and your partner will bring you back in line if you start to drift. Once you have a to-do list, work on it alone until you get stuck. Ask for help. Talk it through. Repeat. Just remember, if your mind starts to wander, you lose.
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.