Or not. My boss is planning to ship this coming Tuesday. By Friday night, we fixed all the bugs. The installer is doing what we want, within limits, and we're ready to ship. My boss is testing the installer on several systems and randomly tries to print. Failure. Printing works only on XP. Not on ME or 98. Back to the drawing board. Six hours later (not including Allan's time spent working on the problem ) I figure out that I must be missing an initialization of printing. I create a test to see if this is the case. After taking an hour to code the test, I run it... and it works slightly better - it now prints to one printer. I just need to get it working for the new printer now. Since the test was as simple as I could make it, I need to go back through and go line by line and add in code very carefully. I'm guessing that the coding will proceed at a line ever 2 minutes, which would be an average of one letter every ten seconds. I think the average for software programmers is 20 lines of code per hour.
Does this mean I'm an incredibly fast programmer, to be doing 30 lines of code an hour? No, I've spent (in previous months) two, maybe three weeks, working with this exact same code. My average with the previous time included? 3 lines an hour, maybe 4. A letter every minute. Whew, the rush!!
All the code isn't that slow. Two weeks ago, I used a whole week to create a system manager program in a mere 3300 lines. All but 300 lines of the code was carefully analyzed, changed, moved around, and debugged. Several times, I took a whole hour just sitting back and studying the flow of the program. Understanding the why is 10 times... 100 times more important than knowing the what of the program. I could tell you the "what" of the program 8 months ago. I couldn't have told you the "why". Eight months ago, I couldn't have figure out the program myself if I took two months. Today, that same program took a week.
Oh, one last detail to bring to mind how excruciatingly slow, boring, and frustrating programming can be. My co-worker Dan, spent over a month working to get the installer right. Wednesday, we tossed away that work and started afresh. Could we salvage ANY of the code? No. But by Friday, we had an installer working. That is because Dan didn't give me all the details of HOW the installer works, but WHY the installer does things certain ways.
College taught me how to program, learning the why behind a program is far harder. When I worked at Emerson Process Management as an intern, my boss told me something surprising: They don't expect a new hire to be useful for 6 months. Why? Because it takes them six months to figure out what is going on and to start producing more than than they get paid.
Following the reasoning out, specialists should get paid a lot more.. why? Not because they are better at programming or know the syntax of C++ better than anyone else, but because they figure out the why. At EPM, as part of my project, a guy was hired for 2 1/2 months from Sweden. He could barely speak or read English, yet in those 2 1/2 months, he had a fully integrated Windows application produced. He knew the why behind MFC.
And I'm starting to ramble. I didn't go to Sea World yesterday or today. I'm going to plan for Wednesday... barring more programming problems.
1 comment:
Right on! While working at SyTech, my first month was spent with no actual production. Second month - some production. Third month - insane amount of production because I finally figured out how the stupid thing was supposed to work instead of just knowing what it did.
Post a Comment