Tags: personal practices
Inspiration: Graham King
Personal practices:
1. Do the simplest thing that could possibly work.
The is another way of saying 'Conquer Complexity' which is what software engineering is all about. So it's not _really_ a practice, but I keep it in mind at all times.
2. Clean code
This is good layout, spacing, nice variable names, etc.
This to me is the most basic way of conquering complexity. If reading a simple method is hard to do we have little chance understanding the whole system.
3. Low coupling - high cohesion:
Also called putting things that belong together together and separating things that don't. The practical programmers call it DRY and Orthogonality. Divide and Conquer.
This principle applies at all levels of structure, from the code through methods, classes, packages, apps/components, systems up to an organisational level (well, if they let me !)
4. Refactoring.
I noted that it often feels like remodelling a building with a small chisel.
5. Good tools:
The unix command line, a good IDE, version control, a language 'with batteries included'. I am sure the trend towards meaningfull variable names (compared to the one or two characters of C days) is at least partly because in modern IDEs you don't have to type them every time.
6. Small iterations / easy releases. As modern living takes its toll on my attention span I'm counting on this practice to save me. Doing things a bit at a time is just some much simpler.
7. Time management.
'Take a break' was mentioned, this is similar. Staying late or leaving early. Deciding when to leap in and do the big concept juggling and when to stick to the safe waters. Deciding when to 'sprint'. Waiting till familiar enough with a new legacy before attempting big refactorings. Realising that it's best not to be 'courageous' mid afternoon when you had a big bowl of sleep inducing pasta for lunch. That type of thing. Oh, and not coming back to the office after someones leaving drinks to make that small change :-)
8. 'Heuristics of experience'
Grab bag of all those little things you learn. For example how a need for different behaviour depending on the type of a class means you need to push the behaviour down into the subclasses and have an abstract method on the current level. Or that a method with lots of comments is probably too complex. Or that a big switch or if/else statement can be turned into data driven code. Etc. This is intuition / smells.
Maybe I should of called it 'Learning to smell'
9. Unit testing:
The main advantage is knowing that the ten lines I have just written are correct.
10. A programming accomplice: This is a weak version of pair programming. Another person if very usefull to discuss / review / sanity check things with. They care about the code, control rot whilst you are away, buffer interuptions whilst you are juggling concepts, spread practices, have ideas, spread enthusiasm to others, and so on. Fighting the good fight on your own can be wearing.
Last published: Wednesday 19th May 2010
<<Previous Next>>