Programming lamentations to learn from
I was reflecting on some of the things I’ve experienced while in the software engineering field. There are some big mistakes I’ve witnessed and made. I’m going to share what they were and I hope you gain insights of how to approach some situations… especially if you are new to the industry.
Clever code
During my first job, I was helping to write a generic report builder application. We needed a method to parse a Date out of an oddly formatted string. Being fresh out of college, I was excited to show that I could write something that would parse immensely fast — and I did. There was one major problem, no one else understood it. When it came time to refactor, a senior engineer said this to me and I’ll never forget it:
Programming languages are designed to be understood by humans.
If your code is good enough to stick around it will have to be maintained and probably by someone else. There are exceptional cases of course, but remember that compilers often make the same optimizations (or better) than the ones you cleverly devised. Learn from my mistake, don’t be clever.
Neglect your users
You are neglecting to involve your users if you: only gather and change requirements before coding, show no prototypes (or even storyboards) to your clients, or only have a few people “see what they think”. Requirements tend to change as soon as a user uses. Plan for this and make something that your user actually needs instead of what they thought they needed.
In this instance, it was my company at fault here. We often got new tasks because the user wanted something different than what we gave them. I desperately wanted to call a customer directly and ask what they wanted. In fact, this is one of the reasons (of many) that I left and moved on to Sun. Your career and project depend on your users. If red tape prevents you from involving them, leave.
Stick to what you know
So often, a programmer may know of a technology that will that exists that fits the problem domain, but often they are unwilling to make the leap and just learn it. This doesn’t always have to be another language, but sometimes different frameworks or even just classes that hasn’t been used before.
Programmers that don’t really know what they’re doing will simply copy someone else’s code through trial and error until it “works”. Reading someone else’s code is a good way to learn, but there must be effort put in to understand it. Only when it is understood should it be copied, then of course you really ought to stay DRY. Take that time to make yourself a polyglot. Soon enough, your career will depend on it.
Conclusion
Choose to be better. You have a good start reading blogs, but I encourage you to apply all that you can for the benefit of learning.
These are just a few things I’ve seen so far. I’m sure you can come up with more examples of your own. Please share.
In response to your first point, I have the following quote posted over my desk:
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian Kernighan
I think it tailors nicely to your point about people needing to maintain the code. I know that I’ve looked at code I wrote over a year ago and gone “What was I thinking?”. Don’t only write code simply and cleanly for the person who comes after you, but for yourself.
Yes I totally agree. I’ve seen some of my old code that took me way too long to figure out. No more of that!
I think perl by default is considered “clever code”. I never know what is going on looking back at it. :P
No kidding. Perl is powerful but totally unreadable. You could probably rip a hole in the universe with the right line of Perl code.
everytime you exceed 80 chars on a line god kills a kitten.
Eric, I like your post and your well designed blog. The dragon graphic is really cool.
However, I disagree with “Stick to what you know”. I being a computer scientist or software engineer means that you must be prepared to learn what is necessary to get the job done. Being able to pick up and become proficient with new tools quickly is one of the marks of an excellent developer.
You’re misunderstanding the post. I’m listing things to avoid here, not things you should do.
Please read the text under the headings to see what I mean.
I tend to like TDD.In the agile environment, write only what will pass for the task. Granted, the next task might take you in a different direction thus negating the code just written. TDD tends to get the job done with only the code you need.