The Agnostic Coder

Unit testing should always be on your mind while you’re coding. Some people prefer to write the unit tests before the code that’s being tested. However I prefer to write mine afterwards. It’s a personal preference and each to their own. But which ever way you feel, unit tests are good. Unit tests are your sanity check, and a direct link to the reason you’re writing the code. If you have no unit test for a particular piece of code, ask yourself if that piece of code is necessary. If not, discard it. If it is necessary, then why haven’t you written a unit test for it? Hmmm? Go write one now then, before you forget about it…

…is highly encouraged. Split code into external modules, but not too many otherwise you will reduce your own thought flow as you flick back and to between them. And reducing thought flow leads to reduced code flow. Be logical, be consistent in what you put external to the main core. The core should be as small as possible, but not at the sake of clarity. If a particular piece of code doesn’t get used very often then make it external to the core. If it get’s used a lot, but it’s function is highly abstract or hard to visualise then make it external to the core. Only keep code in the code when it’s necessary, and when it enhances flow by making the core into 1 easy to read and understand module.

There is a time and a place for obfuscation. But unless you’re writing hardware drivers, or embedded systems, and therefore have a need to write your code in the smallest amount of bytes possible, there’s really no need for it. Obfuscation reduces flow. The reader can not adequately grasp the obfuscated code as quickly as clear and concise code. Sure if it’s a quick throw away script, obfuscate to your hearts content if you want to. But if the code is ever going to be maintained by anyone, including yourself then never obfuscate. Flow comes from knowing what the code is doing and being able to see where the code as going. Without flow there is no understanding. And without understanding there is no knowledge. And knowledge will help a lot more in the long run than slightly less bytes being used.

As a side note compilers are extremely good at optimising code these days, significantly better than they were just a few years ago. As optimisation is often given as a reason for writing obfuscated code it’s clearer no longer needed in the majority of cases.

Good flow is a product of good coding. A program should flow like a river, taking functions from external sources and bringing them together to form the final sea of code. But isn’t the sea too big to view all at once. Yes but even the sea follows a flow that can be easily followed.
Without a consistent flow the coder gets lost, and thereafter the flow loses its way. The flow must be followed constantly. Any deviation leads to chaos and confusion. Think about all the times you’ve looked through someones code and thought, “wow, that’s ugly code, what was the developer smoking when they wrote that”. That is the sign of loss of flow.

Flow doesn’t simply mean other people being able to follow your code. It’s more about the way the code is written. From proper flow comes proper understanding and maintainability of the code. So what is good flow. Unfortunately it’s hard to describe, which will no doubt make you think “Aha, another misguided coder, think’s he knows all but knows nothing”. But good flow really is hard to desribe, it’s like trying to describe a painting by van gogh to a blind person. How do yopu desribe the winderful use of colour, the subtle shades, the shadows, the over all effect of the aubject itself. Coding is an art form, it’s not disciplined like engineering, it’s not as rigirous as a science, it’s controlled by the will of the coder, his understanding of the language and the problem to be solved, and yet the beauty in the code comes from the heart of the gifted coder, transcending thelanguage, the tools, and becoming one with the code. That’s good, pure flow.

.. as important as a programming language. So why bother? The agnostic coder doesn’t need to choose. He is at one with all languages, algorithms, and paradigms. Why? Because very few of these things actually matter. The language used is irrelevant. The paradigms shift and change like the seasons. The algorithms can always be improved, even if the mathematicians would have you believe otherwise.

So what is left?

What’s left is knowing what tool to use and when to use it. Knowing the right algorithm to use and why you’re using it. These two things are what matter most. They transcend the paradigms. They exist in each new language that is created, because they are ingrained into all languages. And yet no language encompasses all that you need to know about these two things.

Why do they matter?

The right algorithm to use is always going to be one of personal choice. “What?”, i hear you cry, “Surely the best algorithm is the one that works quickest”. Not so my impatient friend, not so. The right algorithm is the one that fits into the program neatly. It fits like a jigsaw piece. It makes the code around it feel complete, not forced due to speed or efficiency. Flow matters. And the right algorithm does not impede the flow, but gently helps the flow continue, never hurrying, never waivering, never stopping it.

“The right tool for the right job” is a truism is all professions, from the humblest of plumbers to the loftiest scientists. But what is the right tool for coding. That depends on the code to be written. But do not fall into the trap of the inexperienced coder. Examine the task first, then choose the tool. A carpenter who wants to carve a table leg has to know what chisel and mallet to use, but he needs to know what the finished table leg will look like first, lest the table leg become a matchstick.

Choose your environment well. Ask others what they would choose. But don’t be afraid of making the wrong choice. Good choices come from experience. Just like the experienced carpenter will better know which saw to choose, the inexperienced carpenter has to learn.

Only after you know what you’re going to build can you choose your language. However, the choice of language is not as important as how expressive the language will let you be. An artist could easily paint a blue sky on his picture with a painters roller, but he’ll be more expressive with a much smaller brush. Some languages are restrictive, other not. However you can only be expressive in a language you are comfortable with. If you’re comfortable with a restrictive language then use it, if not choose a less restrictive one, a scripting language, or whatever you feel happy with. Whatever you choose do not fall into the two most common traps. 1) Languages wars. 2) Using the same language for everything. Each language has it’s own merits. It’s own set of good and bad. It’s own idiosyncrasies. Some are well known, others not. Use each language for what it’s good at.

Do not fall for hype about a new language. The success of a hyped language is always outweighed by it’s inability to deliver on hyped promises in a few years time.

Each language is good in it’s own problem domain. Make sure you know your problem domain before choosing a language, and play to that language’s strengths. But embrace the weaknesses as well. Get to know the weaknesses of every language you can. This will help you decide which language to use much more successfully than believing you know what a language is good at.

In essence, be patient, know your problem, and choose your tools carefully. But remember that a rusty chisel is sometimes better that no chisel at all, but if you’d thought about it beforehand you’d have gone and bought a new chisel wouldn’t you?