Think like a Programmer, write like Rowling

Writing code is easy, the average person who can type, can also type code. The hard part is the thinking, still, I find myself learning new methods of thinking and changing how I approach a task.

A key thing I’ve learnt is not assuming, that’s terrible. If you’re going to assume, assume the code is against you, because it likely is. Assuming a value, type or something will often result in issues as it actually wasn’t being running properly and is trickling down to your function and causing chaos.

Another note is not being too broad, or too specific. Jumping to the first SQL query you see might not actually be the correct one, so taking a couple of minutes to be confident the code you’re debugging is actually the code you NEED to be debugging. It might well be poor naming leading you to assume that’s the correct code. If it doubt, rip it out and see what happens. Then narrow down if you need to. Or, use a debugging tool! (Shout-out to xDebug!)

Think simple, think clean. I’ve been my own worst enemy in making an issue hard than it needs to be to solve. Creating unnecessary functions, bad variable naming and so on. Usually there’s a method already written for you, so use it rather than writing your own, adding app complexity.

Naming is a big thing, i’m still learning that one. One method I like is using nouns and verbs correctly. If a function is returning information, name it getAllParties() for example, or isCompleted() and so on. Or in loops foreach(partyEvents as partyEvent) and keep it descriptive, but simple. Sometimes, if you really need to, a slightly longer variable/function name makes a huge difference later in debugging/extending code. I’d rather have a few more characters than spend 10 minutes figuring out what a acronym means, if it makes sense at all.

Show your support

Clapping shows how much you appreciated Billy Purvis’s story.