Real Programming
http://www.cs.utah.edu/~elb/folklore/mel.html
Someone linked to this somewhere on reddit today, and it bothers me. I don't think Mel in the story is someone, really, to be admired.
As I've gained more experience programming, my attention has turned more towards maintainability.
My mother used to run a dry cleaning drop shop, and when she had to travel for family matters or whatnot, I'd watch the store for her sometimes. It wasn't computerized. You'd write out a ticket, describing the items dropped off, and you'd tag the clothes, using tags that had a piece count and item number, like 6-123 for your 123rd customer who dropped off 6 pieces.
The tickets had their own ID numbers, and you'd write down the piece tag numbers on the ticket so you could find the clothes later after the cleaners brought the clothes back. This was as far as my mother's system went.
The open tickets were in quasi-random slots in a holder, and the clothing was physically arranged at random. She'd see the customer come in to pick up their clothes, and she'd just find it from memory, knowing their wardrobes, without having to reference the piece tags most of the time. She also knew which customers liked their clothing delivered, and which didn't, and their starch preferences for their shirts. Who liked bags and who liked them boxed. My mother was very good at this, and had a good repoire with most of her customers. She was so good that a lot of the customers would just drop off sacks of clothes without a word, knowing she'd know exactly what to do.
The problem was that the lack of systems and organization made her irreplaceable.
Every time I went in, I went through every piece of clothing in the shop awaiting pickup, and I'd index them by piece count, and then the piece tag ID. Physically rearranging them on the racks, with the low piece counts on one side, and high piece counts on the other, with big gaps between piece count transitions. Then I'd go through all the tickets and sort them by customer name, then pickup date. Retrieving the items when customers came in was quick and trivially easy. I had kept a note in Evernote with customer preferences, and I'd update it every time I had to call her to ask what the hell I was supposed to do with the things people just left there with no explanation.
What developed over time was a set of systems that did what my mom did by intuition. Systems that externalized what she'd internalized. Systems anyone could pick up with a little instruction to do her job without her years of experience. Systems that were simple, well defined, and could be modified simply to accomodate changes. This was real programming.
My first internship, I'd seen special snowflake programmers. There was a guy whose title was Chief Scientist, and he wrote insane Perl code that did some crazy hacky thing to sneak in a feature under deadline. No one could understand it, and the functions would be 8 pages long. Kids, ask your parents about Perl, and then ask them how absurd it is to have an 8 page long function in it.
My supervisor told me stories about times the Chief Scientist was on vacation, and he had to print the pages out, lay them out on a table and draw arrows all over it, just to try to start understanding it for a simple modification that could take a week.
It's easy to look at these guys and their crazy hacks that save the day, and admire them for it, but look at the fallout when they leave and you inevitably have to change their code, making you miss your next several deadlines. Then ask yourself if they really did anyone any favors.
Real programmers make irreplaceable things replaceable. Even themselves.