After reading Antifragile by Nicholas Taleb my mind immediately began to think of ways this can be applied to programming. Admittedly the book was a hard read, mainly because I didn’t want to go through the trouble of researching the bigger words however that did not stop me from getting the larger concepts behind everything that was being said.
Doing too much
One of my favorite parts of the book or at least the one I will focus on now is the concept of naïve intervention. I’m not really old but within my short, amateur life I have eventually learnt to realize that often the actions we take to avoid a result is sometimes what creates the same thing we feared. Life is really weird like that sometimes unfortunately. The same principle can be applied to coding, coding reviews, customer reviews and suggestions. It can also be applied to you the programmer directly.
The story that was used as an example within the book is about a book editor. A writer will submit a piece to an editor and that editor will request changes. If the writer was to send the same piece to another editor they will also request changes, sometimes the requested changes conflict with the previous editor requested changes. However one of the editors didn’t request many changes. In fact only one change was requested where a historical date was wrong and need to be changed to reflect the correct date. The point being the while each editor was so busy added changes they glossed over a major issue and what might be argued to be the only real change necessary.
Over intervention in Programming
During programming reviews for your junior programmers do you feel the need to critique everything. Do you complain about spelling errors and structure formatting. Maybe you say this is how I will do it (because its the only way). Or do you focus on what is really important. Does it work. Is it stable. Can you easily make changes to it in the future. Is it antifragile. I think I will write an entire post on antifragile code and what this may represent for now I’m getting ahead of myself.
If you left it up to engineers the car will never come out of the lot
The point I’m going for is often we intervene in situations we don’t need to just to prove a point that we can. There might be a delusion that one programmer and three reviewers will bring about a better end quality than just the one. This is just and example to prove a point.
I’ve heard it said that if you left it up to engineers the car will never come out of the lot. They will always find something to fix. This is one of the results of over intervention. The naïve believe that you could get something perfect in your first try if you only think hard enough about it. So what should you do then.
Testing is your friend
I would argue to roll it out if not to users then to testers. Have them give you directions. Programmers tend to not like to test. But until you learn to realize that your coding often blinds you from the user side of things you will never really approach the need for testing or user feed back as you really should.
But how often should you use their feedback
This is the million dollar question. I have often seen that most things work in business that will not work if you were dealing directly with customers.. Which is to say most solutions can work while not perfectly they can work.
Building programs directly to customers is harder because you are creating a form of entertainment. Customers don’t have to use most software if they don’t want to so you have to entertain them. Unless you are large enough to be needed, an example of this being Google but even Google fails. Remember Google Plus.
Reasons vary but the principle remains. This is often why a “really amazing” feature as suggested by the business consultant or developer in a business environment will flop because the assumption is made that people just like certain things. Ignoring the fact that successful business to customer companies go through great pains to keep their customers invested and coming back for more. I digress.
Maybe your indexed array and procedural code works just fine
The point I’m making is you should hesitate to intervene. You should ask yourself if you have to do something. This applies to code reviews, fixing non breaking bugs, rolling out your applications and dealing with user feedback. Really it applies to life but we just taking about code here.
What is the required intervention then?
Usually we as humans tend to pendulum swing. If I say don’t unnecessarily intervene you will some how hear do nothing. Which will work for a while. But eventually your inaction will/might cause all the problems to bubble to the surface creating a volcano of issues that will cripple you. A situation that could have been avoided by dealing with just the one or two issues as they occurred. This was also examined in the book.
Programming has books but no user manuals. You can know how to create a for loop but no books tells you if to implement them. Maybe your indexed array and procedural code works just fine. At least I have not found such a manual. Which means experience will have to be your only guide.
9,999 Hours to go
So you’re new. Don’t worry you have a lot more hours to go. Life might be random but the randomness becomes quite predictable. You might not know exactly when the rain will fall. But you know it will unless there is a drought. The first time you got wet but the next time you walked with an umbrella hopefully. Or you got wet again but you knew rain was falling so it wasn’t a weird experience for you even if you weren’t prepared.
So it is with programming. In fact the same problems occurred so much that they create frameworks, plugins, classes, modules so that you didn’t have to worry about them as many times over. Soon the computer will be doing most of the coding for you and you’re just need to guide it accordingly. Until then you brain is the best pattern recognition algorithm. With enough experience you will know exactly what to do, if to do it and how to do it. Even with this you will still fail though.