This is a continuation of my first blog post, Innovation, learning and biting off more than you can chew, which was written as an example of what can happen when you attempt to embrace too many unknowns into a production workflow.
At this moment in time I consider the act of programming to mainly be a creative medium but definitely on it’s journey towards being an engineering discipline. I’ll admit I’m making this up as I go along but here’s my thinking:
Programming as an Engineering Discipline
I would describe an engineering discipline as a very mature method of construction. It could be making a vehicle, performing a controlled chemical reaction or building a skyscraper. Although methods and techniques are always evolving, there are some baseline best practices which have been formed over a long period of time. Be that either a hundred years or a significant number of decades.
Programming doesn’t have the benefit of time. Although we talk of best practice in software development, if we’re being honest with ourselves, we mean we are trying to use the best method we know of at this point in time. The act of coding is in a constant state of flux. Programming languages are changing and evolving. Even the hardware we are coding against is a moving target.
But, in everyday programming, there are some problems we consider to be already solved. We don’t usually concern ourselves with how graphics are rasterized to a display monitor. We’ll write code at a higher abstraction level which is more concerned with what we want to show on screen but leave the low level specifics to drivers and APIs. So maybe plotting coloured pixels is an example of software engineering. Although people are finding better ways of doing it, generally it’s something that all computers do and have long abstracted away into operating systems to take care of.
Programming as a Creative Medium
Being creative I would describe as the use of original thoughts and concepts. This includes solving problems with lateral thinking. Coding is definitely and primarily a creative medium at this point in time. If for no other reason than the fact that we don’t really know a foolproof, effective way of creating software yet. It’s common practice to release the initial version of a product or a service as a beta. It isn’t because the creators have knowingly left in bugs (we hope!) but because we expect software to require a few iterations of development to become stable.
We’re just trying out new ways of developing software until we discover the most optimal ways to do it. Until then, we’ll keep creating new languages, techniques, processes and methodologies which attempt to solve the flaws of those which came before. I think it’s a very exciting time!
So, for argument’s sake, let’s call programming a creative practice. Practice I think being the apt term. If you look at other activities which are deemed to be creative, it is readily accepted that you are required to practice them to become proficient.
An example: Let’s say you decide to want to learn how to play the guitar. You can learn music theory and you can even learn the specifics of how to use a guitar. But do you really expect to be able to actually play a guitar without spending weeks, months or maybe years practicing? I’d say not. So let’s assume you spend a couple of years becoming proficient on the guitar. If you swap over to a keyboard or piano, you’ll probably need more months of practice to become good with another instrument despite the fact you know more about music at this stage.
(Slight disclaimer here: I don’t know much about making music or playing a musical instrument so I’m going along with my, possibly ignorant, beliefs here for the purposes of a reasonable analogy. Please feel free to correct me (and I’ll correct this) if I’m completely barking up the wrong tree!)
So practice is important but we don’t seem to apply the same logic (pardon the pun!) to programming. We’ll go on a course, read a book, watch a video and then expect to be able to program effectively with the knowledge we’ve just acquired. I’ve seen developers sent on courses to learn a technology come back afterwards and be expected to hit the ground running and use it in a production system. Where is the time to practice?
How times have you started working on a project and thrown the source code away completely three or four times because you keep re-writing it? I’ve done this a few times. Some people consider this to be a waste of time or a form of failure. I just think of this as my practice. I’m making mistakes, learning from them and figuring out from experience how to do something.
My personal belief is that you don’t need to be clever to be a reasonable programmer. You just need to be prepared to learn and put in a lot of practice.
If the need to practice programming is a real thing, how do you achieve this in a working environment? I do think if you want to be really good you have to be prepared to do a significant amount of learning and coding in your spare time. But I believe practicing programming also needs to be recognised in the office.
The best way I’ve discovered of doing this so far is by making prototypes.
You are trying to create something or solve a new problem at work using existing or new technology but you aren’t sure where to start.. Or if your idea will even work. Depending on the size of the problem I normally give myself a specific timebox within which I would have expected to make a reasonable amount of progress towards a viable solution. Usually either a morning or an afternoon.
At the end of the timebox I will have “something” which can help me consider what the next stage of development will be and an idea of how long it’ll take. Alternatively, I’ll have nothing of use which means I either need to look at the problem in a completely different way or it’s just a bad idea.
Within the timebox, I’ll hack on code with an aim to getting something working as soon as possible. I don’t care about TDD, unit tests, classes or even if I’m coding a massive method. I just want something working. If I get something working early on in the timebox, I may take the time to tidy it up and consider how I would design the code for production.
The point is, I’m making a prototype and practising solving a problem or creating a solution. I’m expecting to throw this away and be able to accurately estimate how long it will take to do the job properly. The time certainly hasn’t gone to waste. I’ve got the benefit of experience with a hint of hindsight before I get down to work for real.