Past is Prologue

Dear 2007 Mike,

Congratulations on starting your new career in software development. It's been nearly five years since you graduated college with your computer science degree.  After spending that time away from writing code, you're probably apprehensive about getting back into it.  Has the software world already passed you by?  After all, it's not like Ada was all the rage even when you were using it in your CS classes in the early 2000's.

I want to reassure you that you will be fine.  As it turns out, there's a lot more to creating great software than knowing how to write code.  Do you remember everything from that algorithms course that gave you fits, or the mind-bending weirdness of purely functional languages (SML in particular)? No?  That's OK.  Don't worry about it.  You're not going to be writing a compiler any time soon, so it's no big deal if you don't remember much from that one, either.  Don't get me wrong, that background knowledge will come in handy from time to time.  But you can completely forget the details of just about every computer science course you took.

Except one.  Remember that elective course on databases?  Remember how easy that one was compared to most of the others?  Remember how skeptical you were when your professor told you that--of all your classes--this one, the easy one, was the one that would lead to the most lucrative jobs out in the real world.  Well, it turns out he was right.  Oh, and if you don't remember that one too well, either, that's fine.  You can learn the basics of relational database design in a couple of days.  And don't worry, you'll learn the advanced stuff as you need it.

So, am I saying that you won't actually need most of what you learned in your computer science classes?  Why, yes.  Yes, I am.  There are a few reasons for this.

Line of business applications

You will spend the next 10+ years of your life writing "line-of-business" (LOB) applications.  These are mostly boring CRUD (Create-Read-Update-Delete) apps.  All they do is save business users lots and lots of time.  And what is time?  Time is money, that's what.  So, those boring CRUD apps?  It turns out they are really valuable to companies.

Guess how much theoretical computer science knowledge it takes to build a valuable CRUD app?  Almost none.  That doesn't mean it's easy to build an effective CRUD app.  That's because the key to building amazing LOB software is not computer science knowledge...it's domain knowledge.  The key is understanding why your clients want the solution that they want.  You need to feel your customers' pains.  Otherwise, how else will you solve them?  

The most accomplished computer scientist in the world can build a textbook-perfect application.  One that makes the best use of available resources.  No memory leaks.  Efficient data structures, written by hand in low-level programming languages like C++ for maximum speed.  Loosely coupled.  Highly cohesive. ... And completely unusable.

You see, understanding the users' pain points is the key to writing effective software.  The good news for you is that those five years you spent as an Army officer, away from writing code, will benefit you greatly.  As an officer in the Army, you had to constantly change jobs and change units.  The skills you gained--integrating quickly with a new team, immediately identifying what it would take to succeed in your new role, mastering the job, and then preparing to hand over the reins to the next person--those are the exact skills that will lead to success in the custom software business.

Microsoft Access

Hey, remember that last job you had in the Army?  Assistant protocol officer for the 1st Infantry Division?  The most time consuming part of that role was managing the VIP mailing list.  When you first got there, they had all those Microsoft Word documents based on the 30-per-sheet mailing label stickers.  Hundreds of addresses.  Copied and pasted.  Deleted.  Added.  They started out in alphabetical order (sort of), but after a few years it was all just a big mess.

Every time there was a new event, you spent two days just updating that list.  You knew there had to be a better way, so you fired up Microsoft Excel and copied all those addresses into a new workbook.  Then, whenever you had an event that required mailing labels, you would just add a new column, mark the required addresses, and send them over to Word via mail merge.

Instead of two days, the process took under an hour.  Everyone in the office thought you were a wizard.  And yet your new and improved process was still using the wrong tool.  You didn't know it then, but that process was just begging for a proper Microsoft Access database.  

Within a few weeks, you will have the skills and knowledge to build the perfect solution for that old job.  You'll brush up on that old relational database class material.  Then you'll realize that instead of duplicating all that data you saved in the Excel workbook, that you could normalize it.  You could break it into a series of single purpose tables with matching key fields.  These would be easier to maintain than that Excel file, but they could still be joined together to do everything you were doing in Excel and then some.

All of this could be done in Access with very little code.  After all, Access is a rapid application development (RAD) environment.  Don't expect the code in your first few projects to be pretty.  If you're doing any learning at all, you will constantly be cringing at your old code.  

But here's the thing.  Your customers don't care what your code looks like.  If you can transform their two-day agonizing process into thirty blissful minutes, you will be their hero.  And they won't think of you as a coder, a programmer, an impostor, or even a software developer.  No, to them, you will be one thing and one thing only: a magician.

Rapid growth

Now, I just told you that the code in your first few projects might not be pretty.  And that's true.  I mean, it's true for everybody.  Nobody rises from the cradle writing perfect code (well, almost nobody).  But as long as you stay curious, your programming skills will grow.

The key is not to get too bogged down with impostor syndrome.  Try to remember when you're reading someone who's writing about their area of expertise...it's their area of expertise!  Yes, they probably do know more about that one thing than you do.  I guarantee there are other areas where you know more than they do.  

And over time you, too, will develop areas of expertise.  One such area might be Microsoft Access software development.  Maybe one day you'll even start a blog and start writing about it.  But chances are you'll look around, realize how many other people are still way smarter than you in that area, and secretly hope that no one actually reads what you're writing and exposes you as a fraud.

Yep, impostor syndrome sucks.  Get over it.

You(rs) truly,

2020 Mike

P.S.  Feel free to post this online somewhere.  Who knows, maybe other people will be able to relate to it.

Image by Free-Photos from Pixabay