What can you do with 36 years of software engineering experience ?

The easy answer is…

Anything you want !

The up-side of having 36+ years of software engineering experience is…

Knowing how to write optimal code that will work from the get-go without having to think about it much.

This is something those who have less experience just cannot grasp.  They want to write code that runs fast all the while ignoring the obvious reasons bugs appear in their code.  Spend just enough time writing software on various platforms with various languages and after a while you learn why bugs appear in the first place.

Inexperience causes bugs.

Inexperience thinks performance means having to throw-out making their code robust and flexible.

Experience knows performance should be balanced against flexibility and that robust code will execute just as quickly as less robust code even when it seems there is more code that must be executed.

After more than 36 years of software development experience I can…

Learn any language in 3 days or less – believe me when I say I have done this and doubly faster when the language is ALGOL-like, those of you who are reading this but don’t know what ALGOL is might want to do some research.

Think algorithmically – I see the algorithm in my head and then I write the code – it’s just that simple.  Actually I see the code assemble in my head and then I write the code – the actual code that appears to me is more like pseudo code than anything else but this just makes good sense.

Able to handle code of any complexity – doesn’t matter to me how complex the problem gets, finite state machines are just as easy for me to code as the simplest loop or simplest Boolean logic statement.

Able to make sense of whatever code I may be exposed to – doesn’t matter to me who wrote the code, I am just as able to make sense of it as-if I coded it myself.  Case in point, pyPDF is a common Python toolkit that knows how to read and export text from PDF files – pyPDF does not know how to export the text from a PDF in the same order that text appears in the PDF (left to right, top to bottom); seems like what I am saying doesn’t make sense – just use pyPDF with enough PDF files and you will see what I am talking about.  I spent several hours with pyPDF and played some hunches and now my version of pyPDF knows how to export data from my Bank Statement PDFs which is helping me gather electronic records for my tax purposes to augment my normal accounting process.

Able to code shrink-wrap software projects with ease.   What’s the difference between normal software and shrink-wrap software ?   Hey, when you put it in shrink-wrap you expect it to work and so my production code does work because I know how to write robust flexible code.

Ability to see what can cause software bugs just by looking at the code.  This allows me to write code that has fewer bugs, when given the opportunity to do so.

And more…

Why don’t more hiring managers value what I can do ?

If you were marooned on a desert island with only local natively available foods to eat your whole life you would never know what a fine steak tastes like nor would you want to eat one if given the chance.

Or, if you spent your whole life eating at a fast food joint and that is the only food you ever knew existed you would not want anything better just because someone offered to something they knew was better for you.

I know the value of what I do best even when others do not but then I am rarely given the ability to explain to anyone why my approaches may be better and so I do my best work for myself most of the time.  If more people had open minds about their abilities to write software and they wanted to learn I might get more opportunities to demonstrate why I like to write software the way I do.

I do have an open mind and I do like to learn from others and I take the time to give ample though to why I am being told to write software the way others, who have less experience than myself, want me to present my work upon their inspection.

Software bugs are based-on assumptions that fail.

This is a fact although not every software developer seem to understand this.

Whenever you made an assumption that proves to be false your code will have bugs and the original intent of your code will fail to be realized.

BTW – I began writing software in 1974…

I have been self-taught ever since and I have managed to teach myself a whole lot with a whole lot left to learn.

%d bloggers like this: