ed weissman

“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” 

For what it’s worth, I have written over 1 million lines of BASIC for over 100 customers, most of it still it production, and all of it doing important work producing goods, services, and jobs in so many uncool industries we couldn’t live without. 

Maybe I’m an outlier, but I have gone on to learn algorithms, dynamic programming, database theory, client/server, and web development. I believe the elegant simplicity of BASIC and database theory, although limited in application, has provided an excellent base upon which to build. 

I know that ewd is a giant to be respected, but I think it’s a red flag when a teacher mutters “practically impossible to teach”, even in jest. IMHO, that says more about the teacher than the student. 

Thoughts like this are great for a laugh, but when you stop to think about it, all they really do is further amplify the perception of a huge gulf between theory and practice. Academics whine while those of us in the trenches are too busy to notice because our sleeves are rolled up while we build that which must be built. 

“Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process.” 

I had to read this statement 3 times before it hit me: What’s true in chess is also often true in business. A little background… 

I recently wrote a forecasting system for a company that processes 7 million orders per year. Worse, this company was the merger of two other companies, each of which did forecasting differently. One had a very expensive Oracle based “strong comptuer” that calculated almost everything and told the planners exactly what to do. The other just dumped data into Excel files and teams of “strong humans” manipulated them until they intuitively worked out the best plan. Neither team could believe the way the other team worked. 

The system I wrote using guidance from both teams turned out to be “weak human + machine + better process” which leveraged the strengths and minimized the weaknesses of the two extremes. 

Just a few off the top of my head: 

1. As part of the research for requirements for a new inventory package, I noticed that every pallet was counted by 3 different people and the lowest count was recorded. I worked with plant supervisors to fix the procedures. Management then realized that there was now no need for new million dollar software. They rewarded my effort and concern for the company with lots of great project work and money. Lesson: Look for the obvious first. 

2. A user asked me to help solve her forecasting problem. The two of us sat down and designed the software to do it. I realized there was a parallel effort to do the same thing in another division (with an expensive purchased package), so I made my software work for both divisions. It took 3 weeks to write and people were very grateful. I was employee of the month and got a nice bonus. Lesson: Sometimes little things can solve big problems. 

3. I noticed that warehouse pickers were bending and climbing ladders a lot, so I suggested modifying our inventory system to place the most popular items in bins between the knees and shoulders. The change took one week and made us 10% more efficient (a lot of money after a few months). I would have never thought of it if I hadn’t been walking around, trying to understand how my software was being used. Lesson: Give yourself the chance to find opportunities.

“Did you build anything that you later spun off into a better job or a side business?” 

Yes. Everything I learned using these methods went into 2 businesses: a small business software package and a consulting practice. If I hadn’t stretched myself, who knows what cubicle I’d be sitting in today. 

“A minimalist lifestyle does not make you a better person” 

But a minimalist coding style “does” make you a better programmer. 

I really don’t mind a few extra Philips screwdrivers, kitchen knives, or pairs of shoes in my house, but I every superfluous bit of code in my repository drives me nuts. 

Others say I go overboard and they’re probably right, but I can’t help myself. 

If a 6 character variable name can be shortened to 5 characters without losing meaning, then I do it. Same thing with labels and function names. If I find the same line of code twice, I write a function (but only after whipping myself). Complex If Statements are replaced by Case. Complex Case Statements are replaced by arrays and pointers. Two programs look alike? Replace them with one parameter-driven program. Two forms look alike? Replace them with a flexible form app. Reports? Same thing. 

Old data? Archived! Old programs? Archived! Old notes? Archived! And not one trip to Goodwill, just to my e: drive. I’m so proud of myself when I can fit the software needed to run a $100 million company on a 256K thumb drive.

There must be a 12 step program for people like me. But then, by the time I was done with it, it would be a 7 step program. 

The advice from this post is exactly what you’d expect in theory and exactly “what not to do” in practice. For one simple reason: the source code is (hopefully) the only thing pretty much guaranteed to survive. 

I have seen countless shops where valuable history was lost because it was stored on someone’s c: drive, a network drive, or some repository that failed to survive some kind of migration. And even if these other files (digital or paper) did survive, chances are that the programmer that needed to see them never did anyway. 

Good shops practice keeping audit trails “in the source code”. This means good commenting. Which means good code review and quality control. 

I recently came across a single piece of code that had been changed back and forth 6 times in the previous 2 years. The comments looked something like:

* jeo 02/11/09 Use Ship Date, not Book Date per Sarah in Sales 

* jrm 04/15/09 Use Book Date to make military contracts balance 

* msl 08/24/09 Use Ship Date per Joe in Ops (military no longer active) 

* jrm 12/13/09 Use Book Date per Rick Smith to prepare for new contracts 

* jrm 02/14/10 Use Ship Date per Rick Smith after Ops meeting 

* jrm 05/25/10 Use Book Date per Rick Smith until Q3 migration 

I know that this is an extreme example, but this stuff happens all the time in commercial environments. How easy do you think it would be for the programmer/analyst to provide background if these comments were not in the source code, but somewhere else? 

Sure it’s a pain it the ass to maintain this, but it immediately provides the needed background to the person who needs it, when he needs, where he’s already working. For critical projects with confused users (what isn’t), the alternative is usually much more work. 

“I’ve never seen anyone able to design something away from keyboard that doesn’t change significantly once it’s written” 

It “does” change once it’s written.

The idea is to get a clear work plan on a “close enough” design. I estimate that my first cut of anything is maybe 50% or so. 

The idea is also to avoid sitting at the computer all day and then being disappointed with how little I accomplished. Activity != accomplishment. 

A little more background… 

First term freshman year, 90% of science students took Chemistry I. On Mondays and Wednesdays, only 50% of the seats in the dining room were taken for dinner. Chem Lab started at 1:00 p.m. and dinner was at 6:00 p.m. So, most freshman chemistry students took more than 5 hours to complete their lab work. 

This never made sense to me. I took Chemistry I second term freshman year. My lab partner and I made a pact to “never” miss dinner. We did everything we possibility could to expedite lab time. We did all the reading, planning, and reviewing other people’s results “before” we entered the lab. We even wrote our reports in advance, filling in the results as we went. Our longest lab took 2 1/2 hours. Our shortest took 1 1/4 hour. (We also both got A+.) 

I still practice that methodology today. My computer is my lab and my bed or sofa is my lab prep. Preparation takes as long as it needs. Labs go fast. If they don’t it’s because I wasn’t prepared enough when I started. 

I’ve always thought there were 2 types of things that could be optimized: 

1. Things that need to be “cleaned up”.

2. Things that never should have been written in the first place.

Simple example of Type 1: You rush to get something up and running, and in your first code review, you find the exact same code multiple times. So you write a function, parameterize a few variables, tighten it up, and reference it all over the place. Cool. 

Simple example of Type 2: You have an SQL SELECT inside an iteration. At 500 iterations it runs smoothly. At 50,000 iterations, it becomes non-functional. Your only hope to scale this thing is to rethink the whole process to run with one SQL SELECT (and maybe a database redesign) outside the iteration. You basically have to start over. What were you thinking? 

You need to trust your “process” that Type 1 things will rise to the surface in due time, thus avoiding premature optimization. 

For Type 2 things, there is no such thing as “premature optimization”. They need to be designed and written properly in the first place.