Bryce Canyon, photo by Tom Donders

A bit about me: my background and context

Sep 25, 2021

Since my opening post explained the importance of context when interpreting information, it seems appropriate to provide some context to help interpret what I write.

I love technology.  I wrote my first program in Apple Basic when I was in elementary school, and have always enjoyed the thrill of creation that you can achieve with a computer. I have gotten to the “not a complete expert, but proficient enough to get done anything I need to” level with Python, C#, and Javascript across different areas (web development, data analysis, LOB GUIs, REST, etc.).

When I choose a new language or technology, I generally optimize for things like speed of development, being able to hire developers quickly on a given technology, and the ability to find good answers to questions on stack overflow. I have enjoyed learning about and experimenting with functional languages for example, but haven’t ever found a scenario in my own experience where they are the best choice for a job with all things considered.

To give some extra detail there – I love a lot of things about Python, but the fact that it has “good enough” solutions for shell scripting, data analysis, web development, and almost any other type of problem domain out there means that what I know can transfer easily to other problems I need to solve.  The fact that virtually every API out there has a python wrapper or python-based reference implementation makes it that much more compelling to somebody like me just looking to quickly get things done.

I enjoy learning new things and am a generalist rather than a specialist.  I usually have enough general knowledge that I can dig in deeper when needed on the specifics of a particular technology, but I am very much a jack-of-all-trades and a master of none. I believe that general-purpose tools are usually better for most projects, especially in their early stages – but sometimes using the right tool for the job means something more specialized.  When I need a database, for example, Postgres is almost always my default starting choice.  Still, I have built systems around MongoDB, Redis, RethinkDB, and various other RDBMS’s including MySQL and SQL Server.

I have spent my fair share of time in the enterprise software world as well, having built things across the entire Microsoft stack including WinForms, ADO, SQL Server, WPF, even long-deprecated tech like COM and Silverlight. I respect Microsoft’s understanding of the enterprise market, and its ability to execute on that understanding.  I even think that many of their products are good enough to compete head-to-head with some of the products and solutions that startups and the “move fast and break things” crowd use.

Visual Design

I love visual design as much as I love technology.  I learned Aldus Freehand in middle school and was instantly hooked.  I could use a computer to create things for others to enjoy in a different way, and the impact of making something visually appealing was complementary to the technical construction I was most familiar with.

It was a natural jump to Quark, Photoshop, and web design – and I even spent several years learning 3d modeling and animation. My web experience started back when the <blink> tag and the <marquee> tag were battling it out in internet explorer and Netscape – which probably starts to give you an idea of my age (if the reference to Aldus Freehand didn’t).

After my early elementary school days writing simple computer programs, I didn’t pursue software development further until much later, after I had graduated high school.  Because of my visual design skills, I found I had a knack for building good user interfaces.  Developer friends and colleagues would reach out for help crafting these interfaces in a way that would be useful to their users, and I found myself in the UI and UX design business before those were a recognized discipline like they are today.

With some development experience already under my belt, it became easy to start working backward from the front-end UI towards the internals of the applications was helping with.  Depending on the timeframe you look at, you could consider me either a designer-turned-developer or a developer-turned-designer.

I enjoy other things that live at the intersection of tech and design as well.  This includes photography, with the “right-brained” artistic element coexisting with the “left-brained” analytical element.  Knowing that the colors and lighting and composition are going to make a photo interesting is fun, but understanding the relationship between aperture, shutter speed, focal length, ISO, etc. and using that knowledge to perfect the shot exercises both sides of the brain in a way that is uniquely challenging and rewarding.


The world of business is much less cut-and-dried than either technology or visual design.  The “squishiness” of human nature impacts how you accomplish what needs to be done and adds additional challenges to the ability to get things done.

I’ve worn many different business hats over the years, rarely in a purely technical position. I’ve always been able to leverage technology to effect change and improvements no matter what the role was, but always a secondary part of the role.  Some of the positions I’ve held include:

  • Direct responsibility for the operations of an inbound, 24/7 phone-based service center that had more than 200 customer service representatives.  Hiring and firing, scheduling, compliance with customer needs, quality control, and budget adherence were all part of what I was concerned with on a daily basis. I understand operational efficiency and the challenges of managing a large and somewhat transient workforce because of that experience.
  • Managing the relationship with several large customers who collectively represented more than $100M of revenue per year. These customers were pseudo-governmental organizations that were strictly bound by an astounding number of rules and regulations that were often nonsensical, and always laborious to comply with. A companies ability to comply with those regulations can make (or break) its ability to operate in the sector. The sales cycle was long, and maintaining relationships and proactively demonstrating our value was important in maintaining the contract.
  • Representing the needs of different stakeholders as software is built.  This has included informal “this feature would sure make us efficient” types of requests as well as leading a product management team over a development budget of more than 5 million dollars a year. This has included directly managing internal and contracted development teams, and indirectly managing them via a backlog of product work items.

Some of my philosophies

I believe in simple, pragmatic solutions to problems.  Businesses must deliver value, and the most direct path to the delivery of that value should be continually sought after.

When it comes to software, I think that every organization should constantly ask “what is the simplest, most direct way to deliver the new feature that is needed in our software?  How do we avoid over-engineering, not-invented-here syndrome, the temptation of endless refactoring and optimization, and just get things built?”

Technology choices should generally be boring. Leave the excitement for your vacation, rather than wondering what’s going to happen next time you are on pager duty.  Buy rather than build whenever possible, and always make sure that there is a deep bench of people out there who can help build and support your tech choices when it is time to find and hire team members.

In my view, successful companies continually and sincerely ask “how can we do this better, cheaper, and more efficiently?”.  This applies to every part of an organization, not just tech. Too many companies pay lip service to these values but don’t actually have the culture to reward innovation and efficiency since the inertia of the status quo can be so powerful.

When it comes to optimizing for innovation and efficiency, some of the lowest-hanging fruit for a technology-oriented company is often to improve the user experience of their software. A solid understanding of UX and UI design and the willingness to invest in it can make people actually enjoy using the software – and in turn, get better and faster at it. The return on these improvements can sometimes be hard to measure, but over time the investment virtually always pays off.

To wrap it all up, the more overlap there is between technologists, salespeople, finance departments, and operations specialists, the better an organization will be.  Understanding how to deliver value is job #1, and actually delivering it is job #2.  Everybody in an organization must work together to achieve this to maximize the chance of success.

My experiences across all these different areas have influenced how I think about these things.  Many will see business and technology differently than I do, which I welcome and encourage, but the more my context can be understood the better my thoughts and opinions can be viewed through the right lens.

And with any luck, as I continue to learn and improve my own context will improve and become more valuable and applicable to others. I hope you will join me on this journey!