Confessions of an Intermediate Programmer

When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive.

Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves.

In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well.

This being said, I have a few very minor disagreements with you ;-). These may be split hairs though.

First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft.

What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less.

Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess.

But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.

1. An english language description of what the function (or code block) does as a black box (forget the internals as they are subject to change). What you put in and what you get out, or section headings to structure how you read the code.

2. Comments in the code block to tell you why a given decision was made.

What this gives you is the framework you are describing but it further cements it into three layers:

1. Function and block documentation describe contract and what the code is expected to do from outside. If the code does not implement the contract the code is wrong.

2. When reading through the code as contract-implementation you can understand why certain decisions were made.

As bonus points, you get good API documentation.

They will save you a lot of headache one day.

Really the only way to get better is to write stuff and ship it to someone who uses it, and you have to experience the pain of supporting it. That's when all the important lessons are learned.

Is that really true?

There are many examples of people who came to mathematics late in life and did good things:

http://mathoverflow.net/questions/3591/mathematicians-who-we...

I think you only get better with time if you keep yourself sharp. What has changed for me is that I can't sit still and pound back Redbulls for six-hour coding sessions and then hit the gym. My process is also more methodical.

But mathematics is certainly one area I've only improved in with time.

"File under ego"