Ten Commandments of Software Engineering
I graduated in computer science from a school of engineering. Much to the laughs of my girlfriend, I consider myself both an engineer and a scientist. To the highest degree possible, we try to reflect those labels in Bitovi’s work.
But, doing the “Right Thing” is hard to balance with timelines. I don’t typically care about strict formatting conventions (tabs v. spaces, semi-colons, etc). But I probably care too much about maintainability, separating concerns, and ‘future proofing’.
These rules help guide us to successful project completion.
1. Think First
I spend a lot of time thinking about the code I am going to write. Thought experiments are a good technique to explore the limits of your architecture/algorithm/design without wasting time writing code.
Writing down an explanation for how to use something often highlights incongruous API choices. Even inside a difficult function, I will outline how it will work in comments before I start writing code.
Testing is super important. I don’t always think you can do Test Driven Development (especially in the browser), but at least provide a working demo that isn’t part of the main application.
4. Finish it
This is probably the biggest problem I have. Instead of seeing a single idea through, I jump around. It’s important to polish off your code with proper testing, documentation, etc. Otherwise, when you come back to it, the context switching wastes time.
5. Do it the Right Way
- progressive enhancement
- avoiding namespace pollution
- feature detection
- bottom loading JS
- cleaning up event handlers
- avoiding eval and with
help guide you to a more robust solution. Do not ignore them.
6. Fix It
Someone else’s code doesn’t work the way it should - fix it. Something doesn’t make sense -> fix it!
7. Speak Up
If there are problems, deadlines that you probably won’t make, let people know about it. Nothing pisses off a project manager more than not knowing something is going to be far behind. Speaking up early and often will help a project (and probably your work) move forward.
8. Don’t Repeat Code
- Getting and compressing scripts
- Responding to events
- Aajax requests
- Updating the dom
9. Future Proof
Think about how your code might be used in the future. People might want to extend or enhance it. Is this possible? A former gripe I had with jQuery is that much of its core functionality wasn’t exposed and able to be overwritten and extended.
10. Logically Separate Code
The smaller and more specific you can have your code, the better. Are you building a keyboard navigable toolbar and tabs? Maybe it’s possible to pull out and reuse the keyboard navigation.