When can code review be a problem?

A customer recently asked me to look into a program that used to run in 5 minutes but now took 1 to 4 hours. It’s used by thousands of people all over the world all day long. 

It iterated through an array doing 3 SQL SELECTs against non-indexed files for each element. There used to be about 50 elements in the array; now there were more than 5000. I rewrote the whole thing in one day to do a total of 4 SELECTs and run in 12 seconds. 

But it took 6 days to get through QA (while the users continued to suffer). QA’s biggest complaint? I indented 4 spaces instead of the (unpublished) standard of 5 spaces. 

Of all the things I have to deal with, nothing pisses me off more. Software QA is becoming more and more like TSA security at the airport: illogical, and obviously so. Last year, flagrantly unacceptable code was promoted without question while its replacement was held up on a meaningless detail. 

We programmers are a funny lot. Make us struggle for business or technical reasons and we adapt beautifully. Make us struggle for something stupid and we just get pissed off and do something else. What a pity. 

Have I wasted 3 years working for someone else?

Wow! You have had what seems like an ideal first three years after college and all you see are negatives.
 
Have you learned anything in that time? From what you’ve described, I would think plenty.

The last 3 years was a process you had to go through to get to where you eventually want to be. A very efficient process that not too many others ever get a chance for.

Every time I had a tough gig, instead of focusing of the jerk I worked for, all I thought about was what I was learning and how I could leverage that into my own future. That kind of thinking has always worked well for me.

You now have the background, experience, and skill of an accomplished 35 year old in a 25 year old body.

Congratulations!

Now stop worrying about the past, take a short break, and put those hard earned assets between your ears to work for what you really want. This time next year, I hope to hear from you, “How I turned 3 years of sweat into a lifetime of fulfillment.”


Why didn’t you pursue mathematics?

I left math for a totally different reason and I’m almost embarrassed to talk about it. A little background…

I worked full time through college and graduated with less than $100 in the bank. I had opportunities to go on to graduate school for either math or business.

Every professor in our math department drove an older subcompact except the department head who drove a Chevy Impala. Imagine, work your whole life, get to the top of your field, and drive an Impala!

I had struggled too long to set myself up for more struggle. So I went on to get my MBA, learned how to program, and have never had a lack of good quality, high paying work. I’m a little embarrassed that I was so shallow back then, but maybe my subconscious was trying to tell me something. I love math, but I’m sure glad I made the choice I did.

At a recent math reunion, I felt right at home once again. I met a buddy who graduated with me and continued on to become a tenured math professor at a major university. I asked him how he felt about his choice. He told me, “I’ll never be rich, but I teach calculus for 8 hours per week 9 months per year, I don’t have to publish, and my wife and I have visited over 100 countries. Not a bad life at all.”


Every Task is Complete or Not Complete

This reminds me of my hero of project management, Tom DeMarco.

Tom DeMarco (born August 20, 1940) is an American software engineer, author, and consultant on software engineering topics. He was an early developer of structured analysis in the 1970s.


His approach was that every task is either 100% complete or 0% complete.

No task is ever “80%” complete. If you really think that it is, then break it down into smaller tasks, 80% of which are 100% complete and 20% of which are 0% complete. This way it becomes much clearer what is complete and what remains to be done.

I have never allowed anyone to report anything as n% complete for values other than 0 or 100. As soon as someone does, that’s a pretty good sign that they may be confusing motion with action.

Remember an old discussion with Jim…

Me: Jim, how are we doing with getting Ansys ported?
Jim: Great, I have a bunch of calls into them.
Me: How are we doing on the Nastran port?
Jim: Wonderful, they said they'll get back to me next month.
Me: How about Dyna 3D?
Jim: It's going great, we're on their list.

Now imagine how much different that conversation would be if each question started with, “Which tasks are complete and which tasks are incomplete?”


How does it feel to be a single founder?

Thank you for the great post on a subject near and dear to many of us. 

I am a single founder who constantly wonders if I should be. I have founded 2 startups before and both imploded solely because of founder issues. One had 4 of us and I spent more than half my time playing referee. I will never go through that again. As far as I’m concerned, nothing is more important than being in business with the right people (except having plenty of customers, maybe.) 

I am working hard and steady on my new venture, but I do not actively recruit potential co-founders. I freely share what I’m working on (hinting at opportunities for co-founders) and sit back to see what happens. Since I believe the single most important trait of a good co-founder is sheer determination, I hope someone will come to me insisting, “We should do this…,” “I could do that…,” “Let’s try this…”, etc. Sorry to say, this strategy hasn’t worked too well, but I’d still rather be alone than be with someone who doesn’t push as hard as I do. 

I know about half a dozen excellent people who I’d love as co-founders, but all have mortgages, families, and other commitments. Our startup would always be a child to me, but only a step-child to them. So I don’t push.

I understand the concern about single founder startups; they’re a lot of work! There are many times I wish I had someone to share with or help me out. But under the circumstances, I’d rather plow along, always positioning myself to have a co-founder, but just as ready to launch alone if need be. I’m not afraid to do that and I don’t think other single co-founders should be either.

Why would we want to go faster?

I remember a project I worked on in a large enterprise years ago. All of their systems, believe it or not, were batch. Inventory, accounting, order processing - all data was entered into hold files, or worse, filled out with pencil and paper and turned into keypunch. All databases were updated in a large batch overnight. (Today, it’s hard to believe anyone ever did that.) 

Our project was to migrate all apps to a new real time package. They spent millions of dollars and when it was all done, the controller complained, “Who decided that we needed real time Accounts Payable? Why would we ever want to pay our bills “faster”?” 

No one had ever asked that question before. No one even thought about it. We had spent $1 million on a module nobody wanted because IT decided it. Eventually he added procedures to continue to fill out all accounts payable transactions with pencil and paper and enter them into the on-line system at the end of the day. What a waste. 

Same argument here. Some things you want faster. And you’re willing to pay for them, one way or the other. But other things should just stay the way the are. 

Some things never change: you actually have to “think” about your apps before you implement them. 


How can I do better on interview tests?

“My biggest pet peeve with these types of tests is this: there are a lot of companies out there, and I’m sending out resumes to each one that I can find.” 

That’s your first mistake. 

Why should a company take you seriously if you don’t take them seriously? Every resume you send out should be custom written and carefully crafted to address their requirements, not yours. Do you do any research into the companies you’re applying to? You should. 

Rather than sending out 50 stock resumes, you’d probably be better off picking the top half dozen or so opportunities and do everything you can to stand out. This includes a custom cover letter, follow up emails, thank you notes, etc., whatever it takes to make the connection. 

“I simply do not have the time to write fifteen code samples a day, just because you want to evaluate me against your coding test. Period.” 

There’s your second mistake. Misdirected attitude. Again, you should be focused on their needs, not yours. If you don’t have time to do 15 poorly, then just do one or two very, very well. No employer or recruiter cares that you’ve chosen a shotgun approach. 

Give of yourself without expectations of something in return. You may be surprised at the “unexpected” dividends you’ll reap later. 

For what it’s worth: I have conducted over 2500 technical interviews and every single one of them has had to code, regardless of experience or background. What good is a programmer who doesn’t want to code at the one point when it would provide the most benefit to everyone involved? In my experience, the best programmers were the most eager to give it a shot.

What tools do you use for analysis?

Pen and paper.

This is a hard and fast rule that I have always followed and is absolutely critical to my success. Just a few of the reasons:

1. I firmly believe that analysis, design, and planning is much more effective if it is done “away” from the computer. These are totally different activities from programming and they take a different mindset and environment. That’s pretty tough to do if you use computerized tools to organize.

2. I like to spread out my notes, plans, diagrams, lists, etc. on a table to work on them. I also tack them up on the wall above my work space, both at the computer and in the other room. I want to give my mind every opportunity to see the “big picture” when it’s appropriate. Again, tough to do with a computer unless you have
5 monitors.

3. I carry my notes with me whereever I go. You never know when inspriration will hit, and I don’t want to carry a laptop everywhere and wait for it to boot up.

4. Bedtime is critical thinking time (both at night and in the morning). I always have my notes and multiple colored pens with me in bed. Some of my best ideas have come at this time. I can’t imagine the same thing happening with a laptop.


What do you best remember from your MBA?

I understand OP’s sentiment. I place very high value on my MBA from the University of Pittsburgh, but for reasons one wouldn’t expect.

I remember almost nothing from the course material itself. You can get that from almost any book. The time value of money, how to read financial statements, the 4 P’s of marketing (or was it the 4 B’s?), different management theories, etc., etc., etc.

What I remember vividly are the interactions with other people, professors and other students, some of whom already had many years of experience. I’m not sure how else I could have had this experience. Some of my most vivid memories:

“A degree in business is a degree in nothing.” - management professor

“What is the correct answer to the question ‘How much money did you make?’ It’s always, ‘Who wants to know’?” - managerial accounting professor

A professor of Organizational Behavior told us that a survey of Yale MBA’s 25 years after graduation said that Organizational Behavior was their most important course. I couldn’t believe it. Years later, I believe it.

A case study had our team pick the next CEO from 4 managers. We were wrong. The actual result: They went outside, for reasons well explained.

Our group made a recommendation to a local business to restructure, letting a key person go. We got an “F” on the project, with the opportunity to go back and redo it without letting anyone go. We got the message.

A marketing professor was picking on stupid products, like Heinz gravy, when a student in the back offered, “I was the product manager for gravy at Heinz. It made us $60 million last quarter. If you’d like to use it for a case study some day, I’d be glad to help you with it.”

I don’t remember many specifics from class, but I know that I “think differently” because of that experience. Along with a technical background, this has been a great combination.


Technical Debt

Typical way that competent developers end up with technical debt: 

1. Customer/user/consumer has a vague idea of what they need but doesn’t know how to express it. 

2. Developer works with customer to learn their business and understand their requirements. 

3. Developer throws together a prototype to confirm that he understands the problem.

4. Customer sees that developer is on the right track. If these 9 enhancements are done, then we’ll really have something. 

5. Developer quickly adds 9 enhancements to prototype. 

6. Customer loves it! Move it to production so we can play with it for a while. 

7. While customer plays with it, developer maps out a plan to architect, refactor, and scale the prototype to be “production worthy”. 

8. Developer is pulled away to 5 other urgent projects. 

9. Customer continues to use prototype as production software. 

10. Two years later: “Who wrote this crap?”