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?
My name is Tom Moore. My Day job is a Developer Advocate with Amazon Web Services. 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, still owned and run by the same family that served me pizza when I was 10…
Like many people who set out 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 as well as learning to be in the public face at Trade Shows. Back then I was traveling 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 a while working for Sophos, I relocated to Sophos’ headquarters in Abindon 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 small town 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 skills in technology, as well as getting married and raising a family. For a while I worked as a pure developer, cutting code and writing features for mobile applications for a couple of small companies located in Perth.
After a while 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 goals of the business, 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 re-iterated the idea 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 word develop “stuff” in a vacuum, creating technology projects based on principles of what seemed cool or interesting. Obviously, there would be some form of overarching business idea, but the development would be bottom up and decisions based around 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…. “220.127.116.11 [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 many years, organizations would choose a particular database technology. IBM DB2, Oracle, SQL Server or maybe MySQL or PostgrSQL. 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 what database engine they had chosen. “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 standard was a relational database and the data being stored was similar in nature to an order structure.
TOGAF teaches that you should start at the business and work back 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.
Years later I got a call from a recruiter from Amazon for a position in Boston. Turns out that TOGAF aligns well with what we refer to at Amazon as “Working backwards” starting with the desired end state and working back from there to the technology. Of course, it helps when you have a catalog of over 200 services to fit every imaginable technology need there is.
I now have six years under my belt at Amazon, helping customers to work backwards from their goals and get the best out of AWS. The new challenge, helping a broader audience of developers to learn and make use of Amazon Web Services in their projects.
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!