I’ve always had a very critical view of politics – always figured its easy to wear those rear-view glasses that gives you a perfect 20-20 hindsight and running a country is easy.
Now I’m a developer (and therefore wholly unsuited to ever run a country) and as we all know, developers are really smart – well…at least everybody else seems to think that what we do is sooooo incredibly difficult to do, so alas, we must be absolute geniuses.
One way in which we are very good at amplifying that image is when we start to throw “Teh Jargon” around. Everything we say, every sentence, is stockpiling TLA’s and FLA’s, making everything we say sound phenomenally complex.
One other way is also in our code – ah yes, the brains of the universe – what makes the work go ‘round. tick-tock…Here’s where our egos gets a serious dose of “I AM TEH BRAINZ”.
We love complex solutions. We love nudging a colleague and go “suck this up, buddy!” and watch his eyes go blank because he has no clue as to what he’s looking at. There’s something fundamentally satisfying in creating something complex and see it work.
However, we often forget some of the things we learnt when we first booted up that PC in class..
I remember my very first programming construction teacher (this guy designed the manufacturing system for Lego in the old days when punch cards were hitting it off) – it took us three months to even start to write code – and man, were we impatient – we wanted to crunch that code NAOW!!!
But at first all we were doing were describing the steps involved with creating a cup of coffee. That took us two weeks to do….????…That’s just crazy, but our teacher wanted to prove a point before moving on with something that we should all have thought about – for real, remember we are the smart ones..we’re taking this course after all.
It’s this principle that we forget all about, the minute we enter into the professional world because we have to make sure that our colleagues at least think we know what we’re doing.
It’s perfectly natural for us (especially males) to strut our stuff when we’ve achieved something and we tend to let our code speak for itself. We just forget that the simple solution is the smarter solution.
If questioned about our solution we’ll also shift the burden of proof to defend our solution – again possibly by throwing “Teh Jargon” around. It’s this exact complexity “need” that makes us completely unsuitable to run a country.
I remember one of the fundamental ways to actually map out a process, be it for a multithreaded complex solution or a simple procedural solution – pen and paper out (what? i’m into computers g’damn!) – and then we map out those processes we “think” we need (knowing them would be ideal of course, but we’re developers damn’it and don’t listen anyways). This process was called Pseudocode/prototyping and made the way for flowcharts and UML diagrams/charts. But how often do you think a developer would count Visio in among his most often used tools?
Right, cause we are “TEH BRAINZ” we don’t need any of that smuck – newbies and juniors need that, right?
Developers has evolved, of course, that goes without saying but look into the 1,000s of online communities out there today and look for threads titled “I want to learn programming, where do i start?” and 99% of the responses are “Check our these tutorials” or “Buy this book, excellent way for newbies to start” – and not knocking those answers because those tutorials and that book are generally some of the best sources of information on the language/platform.
We also tend to argue that writing code is a science – we can quantify and qualify everything mathematically – hence it must be a science.
But the part that’s seriously missing is the analytical part – what describes how our mind works when we’re interpreting a solution to a business problem? Well, it’s definitely not “Framework X is da bomb!!” or “You must follow our company’s code convention”. These facets are important for the business, but how processes are mapped down is the ART form. The form that cannot be explained by running extra performance tests on which iteration type works best for a specific solution.
I’ve always stated that developers are NOT business process analysts – simply because we don’t think similarly. We need analysts for that.
So, not only don’t we create the most simple solution but we seem to forget the most important aspects when writing code as we “mature”….