Why basement Programmer?

Partly ‘tongue in cheek’ partly serious. The name Basement Programmer is inspired by terms from the 80’s like ‘Shade Tree Mechanic’ and ‘Back Yard Engineer’ the idea of people having their own space to do the things they enjoy that are not necessarily a professional office.

That said my “Professional Office” for the most part is in my basement. It’s where I work most days doing my ‘Day Job.’ This was my primary place of work prior to the world changing with COVID in 2020 and continues to be my primary place of work today. As the world evolves into a post-COVID new normal, the basement office will continue to get a lot of use and continue to be my primary “office” as there really is very little reason for me to take the 1+ hour trip into Boston on a regular basis. I have everything that I need readily available to do my job. (Laptop, Internet Access, Multiple Monitors and ready access to coffee as needed.)

Who is Basement Programmer?

Tom

My name is Tom Moore. My Day job is as a Solutions Architect working in Cloud Technologies. My background is a mix of different positions and countries that took me around the world and landed me (currently) a couple hundred miles away from where I grew up… I can still drive to my hometown to get pizza from Village Pizza, which is still owned and run by the same family that served me pizza when I was 10…

Like many people who embark on technology careers, I started my early years in technical support. I was employee number six when Sophos Anti-Virus opened its doors in a tiny little office in, Woburn MA, USA. When I say “Technical Support,” I was Tech Support, IT, Network Administration, internal help desk, and learning to be in the public light at Trade Shows. Back then, I traveled at least once every 2 months to some trade show or another showcasing the product and meeting with customers from all over the US.

After working for Sophos for a while, I relocated to Sophos’ headquarters in Abingdon, England, and worked at the home office for another two years. In those two years Sophos grew and changed a lot, they were shifting from the small(ish) company with aspirations of really operating with an international scope to the large-scale company that they are now. Living and working in Europe gave me a very different perspective on the world than I ever imagined growing up in a small town in Connecticut.

Two years later, I relocated again to Perth, Western Australia, the furthest point on Earth from my starting point… I spent sixteen years there developing my technology skills, getting married, and raising a family. I worked as a pure developer for a while, cutting code and writing features for mobile applications for several small companies in Perth.

Eventually, I found my way into the world of IT Consultancy. Consultancy was an interesting skill set to try and learn. You can’t be an effective consultant without expanding your horizons beyond cutting code. You need to understand the business that you operate in. You need to understand how the things that you are doing either contribute or detract from the business’s goals. If what you are doing doesn’t align with the business's goals, then why are you doing it?

It was my time as a consultant I also learned the principles of TOGAF-9. This was an interesting skill to learn as it reiterated that technology projects should be based on business outcomes. Start at the Business Architecture and work your way around to the technology. Allow the technology decisions to be driven by the outcomes that the business needs.

For many years, IT would develop “stuff” in a vacuum, creating technology projects based what seemed cool or interesting. We built tools in search of a problem. There would be some form of overarching business idea, but the development would be bottom-up, and decisions would be made based on the technology. You would end up with products that were difficult to use, and only intuitive if you were the developer who wrote the product. Users had to learn how to adapt to what the developers wrote, rather than developers adapting software to how people worked. MVS I’m looking at you with your menu shortcuts…. “3.2.4.1 [Enter]” … anyone old enough to remember working with green dumb terminals will understand what I meant there.

Or VSE/ESA with a text editor that thought it was a good idea to automatically shift everything into all capitals unless you issued the command “CASE M” when you opened a file… try doing type setting with things getting shifted to all caps in the middle of your copy at the point of saving the file…. not fun.

Anyway, TOGAF teaches that you need to start from the desired outcomes and work back to the technology that enables that outcome. This enables us to make decisions that are fit for purpose, instead of trying to make the business work based on technology choices that are not always optimal.

Key example: For many years, organizations have chosen a particular database technology. IBM DB2, Oracle, SQL Server, or maybe MySQL or PostgreSQL. Those decisions would be set as the company standard, and every bit of software would be designed to work with those standards. Companies would choose the software they would use based on their chosen database engine. “Nope, can’t use that, it doesn’t work with X Database.” Software developers would develop software based on the database and the structure that was designed. I’ve lost count of the number of times that I have written code to manage the basic concept of a header and line items, possibly with address details attached, because the database standard was relational and the data was stored as a document.

TOGAF teaches you to start at the business and work from there. Why are we storing an order header and line items separately? Because the database wants Rows with Columns and Relations…. that’s why. But, in reality, the order and lines are a single “thing” and should be addressed in their entirety. Why not use a document database?

Years later I got a call from a recruiter from Amazon for a position in Boston. It turns out that TOGAF aligns well with what Amazon refers to as “Working backward,” starting with the desired end state and working back from there to the technology. Of course, it helps when you have an every growing catalog of services to fit every imaginable technology need.

I should note here: Opinions expressed here on BasementProgrammer.com are my own. They are not necessarily the opinions of my current or former employers, or any other groups I may be or have been associated with.

Let’s build something together!