The Perception of Programming Complexity

Back when dinosaurs roamed the earth, and we wrote code with rocks and spears…  Ah, those were the good ole days.  Everything was simple back then.  There were only a few languages to know, and top down, procedural programming was good enough for almost every requirement, and nothing was agile.  It’s funny how our memory of the bad things is diminished, and we only remember the good.

Things Weren’t Really So Simple

If I think back to what my friends were working on, we each had our own seemingly simple view of the programming world.  Some used only one or two languages by the mid 90′s.  Some of us were up to eight or more, and those languages rarely had to interact directly with each other.  That’s not the case anymore.

With the limited flow of information, things just seemed simpler.  Generally speaking, it wasn’t as complex as it is now, but it was still pretty heavy stuff.  Now there are tons of languages to learn, many interact with each other, or at least can be used with each other.  Similar languages didn’t just start recently though.  Clipper, Foxpro, and Clarion all did basically the same thing with different syntax.  Clipper was even extensible with C.  I’m sure it started earlier than those, but those are the ones I remember well.

There were many flavors of BASIC too; TRS-80 Color Basic, Commodore BASIC, Apple, TI, Atari, etc.  My first contract gig was for an insurance company using GW-BASIC.  The person who wrote the program was teaching himself on the fly, and it showed.  I won’t get into that right now though.

Things Aren’t Really That Complex

If you understand what the computer is doing on the inside, then those basic concepts will transfer from language to language.  You’ll just need to learn some different syntax to do the same thing.  The trick to learning them fast is relating the new way to the underlying concept.  As new technology and concepts are introduced, you’ll need to learn them regardless of which language is your primary one.

Most people I know use a limited number of languages at a time.  They don’t need to remember everything they’ve ever done.  I use Java, Objective C, XSLT, HTML, and PHP all the time.  Visual Basic and C# still come up once in a while too, but I haven’t touched COBOL, Clipper, PowerBuilder, or Pascal in years.  I’d be a little rusty, but I’m pretty sure I could pick them back up pretty quickly.

The Difference Between Now And Then

The work my code is doing is more complex by necessity.  20+ years ago, I had to worry about a single user.  Authentication and security was a password screen.  Encryption wasn’t necessary for much of what I did.  Transaction rates were limited to what the user could generate.  Even if there were 10 users, it was still very low.  Transaction sizes were also tiny.

Times change.  Now, there are potentially millions of users.  Authentication and security requires certificates, SAML, and a few levels of encryption.  I’ve got to consider many billions of transactions per month, and transaction sizes can get very large.

The concepts used then and now are pretty much the same.  The big thing that has changed is the size of the system and how many things it touches.  It still just moves bits around on the inside though.

Resistance Is Futile

We resist change, and we forget about the difficult times when we reminisce.  We’re always going to do that.  Once in a while, think about the hard stuff that you’ve done, and you might just find that it was only when there were new concepts to learn.

Don’t think that you need to know every language and technology in existence.  That’s just not true.  It’s great to know about them, but your head will explode if you try to shove everything in at once.  Figure out what you must know, and nail it.  After that, you can start looking at

The critical thing is to make sure you have a deep understanding of what happens when your line of code is executed.  From there you can use that knowledge as a base for every other language you will use.

Disclaimer

I intentionally left out the non-coding stuff like source control, Maven, Ant, Ivy, SDLC Methodologies, etc.  You will definitely need to know some of that stuff, but you only need to be an expert at them if you are responsible for them in your job.  You should be able to carry on an intelligent conversation about the ones that apply to your field.

Conclusion

It’s fun to reminisce once in a while, but don’t keep your head in the past.  The young programmers coming up today will feel the same way in 20 years.  I think, more than anything else, our perspective changes, so take a step back once in a while to change your perspective.  If you’ve been at this for a while, remember what Billy Joel said; The good old days weren’t always good, and tomorrow ain’t as bad as it seems.

Leave a Reply