11 Important Software Engineering Rules To Follow

Software engineering as a subject is obviously incredibly complex and almost impossible to boil down into a set of rules. Not to be put off by a challenge, however, we decided to give it a go.

So we asked our team of developers to offer up a few rules each — things they wish they’d been told early on in their careers. Here’s what they came up with…   

1. Use version control, and learn as much as you can about the version control tool you use.
 

2. Step through code — be it by debug dumping or using a breakpoint style debug tool — so you learn how to run code in your brain like a computer. Empathise with your computer!

3. Understand what you’re trying to do before you do it. If you can’t do that, experiment until you do. Then start again.

4. Document what you intend the code to do, not what it does do. Anyone can read the code to understand what it does, but at least then they can compare it against what it’s meant to do and pity you for your mistakes.

5. Document before you code. Don’t kid yourself you’ll do it later — you won’t, nobody ever does.

6. Don’t believe the hype. Great coders are neither lazy nor dumb. Great coders know how to get the computer to do the work for them, but that’s smart not lazy, and it’s hard work. Asking dumb questions is even smarter. Lazy coders do a poor job and dumb coders do a dumb job. If you think you’re a great coder because you’re lazy, then you’re probably just dumb.

7. Tabs not spaces. Apart from using tabs for indentation and spaces for alignment which is just sublime in its intelligence.

8. Just because you learnt patterns doesn’t make them the answer to all problems. Choose the right solution for the right problem; don’t shoe-horn the problem into a particular solution — especially not if it’s just because it’s your favourite one.

9. Help keep dependencies to a minimum by exchanging only the minimum amount of information required between sections. Any more and you have redundancies or dependencies. Any less and it’s not enough.

10. When you’re designing a solution to a problem don’t think implementation —  it’ll constrain your creativity. If you’re implementing without having done any designing you’ve missed the most important step.

11. When designing, use two whiteboards. Redesign several times attacking the logic of each iteration by copying between boards and justifying every line and box during each iteration.

Let us know what you think. And if you have any rules you’d add to the list, let us know those too.