This article really hits the nail on the head. Microsoft Access developers are a rare breed, and I completely agree with the unicorn analogy. It is not just about knowing VBA or how to build a query. You have to be part coder, part database architect, part problem solver, and part therapist because let's be honest, half the job is figuring out what the client actually needs versus what they think they want.
The business acumen part especially resonated with me. You are not just writing code. You are streamlining processes, automating workflows, and making people's lives easier, all while dealing with the occasional "Can't you just add a button that does everything for me" request.
In fact, one of my challenges when I first started doing consulting work was that I had a lot of computer knowledge because I started using computers when I was 8 years old. However, I didn't have very much business knowledge as far as understanding how businesses worked - their processes and so on. So, I spent a lot more time learning business in my early consulting career than I did working on the computer code.
Also, the mention of bridging legacy systems with modern solutions is spot on. Access has been around forever, but it still serves a critical role in a world where businesses rely on a mix of old and new tech. Those of us who can navigate that world are in high demand. How many Gen Z'ers have worked on DOS systems?
And if you think Access is dead, I have got news for you. It is still running businesses all over the world. We might not be as visible as web developers, but we are out here keeping the gears turning.
As for the unicorn part, maybe a Ferengi would be a better analogy... always finding ways to make things more efficient, profitable, and just a little bit smoother. Rule of Acquisition 214: "Never begin a business negotiation on an empty stomach." Maybe for Access developers, that should be, "never start coding before you fully understand the client's problem."
I have always (in the past) been involved in applications that are specific to a certain market. That usually puts constraints on the design. What works for selling cars doesn't necessarily work for selling batteries. Although many a developer has sold their product as the Swiss-army-knife solution; they've gotten well paid for tweaking the application after the sale to align with the promise.
There are a lot of applications still running in COBOL and similar languages developed by the older OEMs. Many of them have forty or more years success in what they were designed to do. Most don't fit into the Web concept very well.
As I've said before, I chose to work, after years in legacy systems, with Access. Mostly for economic considerations of my clients and for the fact that analysis users, with a little training, can "play" all day with queries and reports to tweak the data. All without a "unicorn" getting involved.
Joe Holland
@Reply 20 months ago
I am a process control person. Everything has a process and you can optimize each to you and your customer's benefit. Since I love business, math, programming, people, and process control, Access was the perfect tool to manage all of these. It allows you to do whatever your people and processes need whenever you want it to. Without all these interests and skills, it would have been much more difficult to make progress over time.
Sorry, only students may add comments.
Click here for more
information on how you can set up an account.
If you are a Visitor, go ahead and post your reply as a
new comment, and we'll move it here for you
once it's approved. Be sure to use the same name and email address.
This thread is now CLOSED. If you wish to comment, start a NEW discussion in
Captain's Log.
