Beyond The Code – Lessons Learned

Learn From My Mistakes. Or don’t.

After one has developed a few large applications, lessons tend to be learned. The kind of things seasoned pros shake their heads at and retort “welcome to the club.” Things a lot of us learn the hard way, even though we’ve been warned.

I thought I would share some nuggets of developer wisdom. In part, to make seasoned developers laugh. In part, to warn those who don’t have calluses on their fingers yet. Or arthritis. Or repetitive stress injuries.

The List.

1. Yes, comments matter.

I am grateful I had a professor in college who cared about comments in code. And not just any comments—good comments. The assignment rubric required them. Functions had to begin with comments describing what they did, and what the arguments were. Why? Because it really, truly matters.

There is no such thing as self-commenting code. I don’t care what language is used. I once interviewed a person for a data warehouse engineer position. I asked a simple question: “How much code do you think should be commented?” I received a sad response: “Well, I write my code in a way that it is self commenting. If you can’t read the code and understand what it’s doing, it’s bad code.” Sorry. Wrong answer.

I find it intriguing how people will argue against comments until they are blue in the face. Comments are included as a feature of the language for the developers! If it wasn’t necessary, it wouldn’t be included. This was figured out a long time ago, folks.

2. Everyone makes a BIG mistake.

Obviously you can’t learn from this one to avoid it. It just happens. Sorry.

I know people who have deleted production databases. I’ve taken a production database to it’s knees by making a change to a scheduled task without first testing it somewhere else because it was “a simple change” (okay, so this is one nugget you can remember). If you haven’t made your BIG mistake, don’t beat yourself up too badly when it happens.

This kinda leads into another one: backups save jobs. And companies.

3. Backups Save Jobs. And Companies.

So, when you make the BIG mistake, you’ll breathe a lot easier when you realize you can roll back the stupid thing you did. Make sure you (or someone you work with) has a working, tested, proven backup and recovery strategy. This is not something that can wait for later. If you don’t have it now, make it a priority. Go the extra mile: create a disaster on a test environment and roll it back a couple times. Believe me, you will be thankful you did.

A former chiropractor I saw didn’t think backups were so important. I went it in one day to make a payment on my account. The receptionist said “You don’t have to pay anything. Our computer crashed and we have no backup of the financial records.” That’s a pretty big oops. I don’t believe they recovered from that one. Don’t be this person.

4. Over-communicate.

No, don’t have a bunch of meetings. Those are horrendously counterproductive in great quantity. But do over-communicate. Send all kinds of e-mails and messages to keep your teammates up to date. And just when you think you’ve sent enough messages, send more. This is especially true if you are not on target for a deadline (which seems to happen about 259% of the time).

If you start getting blocked by spam filters, you have communicated well.

5. There Is No Magic Language.

Every language has its strengths and weaknesses. Well, some are just plain weak (I’m looking at you VB). But for the most part, every language has its strengths and weaknesses. Religious wars over programming languages are really, really fruitless.

On the other hand, healthy discussions on the best language for a particular task can be very productive. Figure out the task, and then find the right tool for the job. Are you working on a distributed, high-concurrency ecosystem? Don’t use Python. Could you? Sure. But you want something suited for your end game. In this example, Go or Erlang would play nicely.

Don’t want to learn something new? Find another job. No, really. Someone needs your skillset. Why do you think COBOL still exists (no, this is not open for discussion)?

 I’m out of creative energy for the time being. I’ll share more gems at another time.