As outlined in my first post, I have a BS in Computer Science, and many years of experience solving large, enterprise problems by building solutions using numerous professional programming languages. From IBM mainframes (Pl/1, JCL, APL, Clists/REXX) to AWS solutions using Python and the Boto3 library.

So why the heck do I proudly say that I spent many rewarding years of my career building business solutions with Microsoft Access, VBA, Microsoft Office and Visual Basic (primarily VB6)? Aren’t those tools some of worst tools to use? Aren’t they the bane of a pro devs existence? Yes, but….let me explain…

Part of my career was tightly woven into the implementation of OS/2 within my company. Specifically, I was asked to understand what business areas needed from PCs, and how we could demonstrate that tools running under OS/2 could help meet those needs. That, my friends, was tough. Not just because tool selection within OS/2 sucked, but also because it took me into a new world…a reality where business areas weren’t content with waiting for the IT area to provide them with solutions, but one where business partners tried doing their own thing.

For large organizations, like the one I worked for, there is far more demand for technical solutions than there are pro devs to create them. As a result, many areas (smaller departments, ones that didn’t generate revenue, etc) ended up not getting access to IT resources very often. So solutions they did have went years between bug fixes and enhancements. Added to that is the old school waterfall approach to project management used back then which dictated *months* of requirements gathering, followed by *months* of IT going of and building a solution. All this happens while the world continues to change for the business areas, resulting in solutions that addressed requirements but missed the new, current mark.

So, once the OS/2 universe imploded, I was a bit burned out. I loved solving problems for people, and the frustrating time I had just spent seemed to have been of no value to anyone. Or so I thought.

One thing that came from that work was my new appreciation of end user computing. I still fully understood all the pitfalls of end users *trying* to create their own solutions, but now better understood why they needed to do it, and I had ideas how they could avoid some of the worst issues it. Another benefit from that work is that I met some leadership people with business areas who would love to test out my ideas for how best to do that work IF I was willing to take a leap and leave the IT Mothership.

It meant:

• I would no longer be an IT employee – this triggered some very unexpected reactions from IT areas that I had previously worked with when I too was in IT
• My role and pay would be affected – no technical title, and raises/bonuses
• I would need to do much more of what is today called “full stack” development as well as work closely with others in the business department to create solutions
• I would need to use what I viewed as less-than-professional dev tools, as many of the true dev tools were only available to IT pro devs
• I would need to ensure others in the department understood the solutions I wrote and could *support* them

With all this on the table I chose to make the leap. My primary reason…some personal introspection taught me that my greatest career joy was providing solutions. And there were groups in the organization who I could definitely help.

In the next part of this post, I will chat about what I used, and how I worked. The last part will be what I learned.