If you look up the definition of shift you’ll find a pretty long list of definitions. I could easily write a few pages on how each of them relate to the title of this here blog, but the past few days I’ve been thinking primarily of the mental shift (and mental shifting of gears) from my previous life to now. More specifically: how I used to solve problems and how I’m learning, and want to learn, to solve problems now.

I would say that from the age of about 14 on I defaulted to always using brute force to solve a problem- pretty much any problem. And by brute force I mean that if I had a goal, I’d choose a strategy, and I’d work that strategy until I met my goal. Sometimes I could just tweak the strategy a little bit, and sometimes I’d have to start over. If I tried solving a problem enough ways then I’d eventually get to the solution. Then I had an answer if I was faced with that same challenge again (or a similar one). If I was faced with that same problem repeatedly I would tweak and adjust the solution to always make it a little better. (This pattern relates quite a bit to my last post too).

Brute force was definitely always my tactic with math and puzzle problems; in my papers in college I’d argue that a lot of my writing used brute force too; and in my early-20’s when I started managing the ABD club, a large volunteer organization with 20+ events a year, I used brute force to figure out what the heck I was doing (but fortunately I had a lot of help too).

Sure, brute force always got the job done (and getting the job done is what I was paid for), but there definitely could have been better solutions: ones that were cleaner, more efficient and that left me better prepared for the future. Now that I’m faced with more complex problems in code (that can involve many other people working on the same code base and will be handed off to others down the line), I’m slowly learning to take a step back before I barrell forward with the first feasible solution that pops in to my head.

Fortunately there are many signposts to help: established design patterns, the SOLID principles, and many smells to warn me if I’m headed down the wrong path. I’m still not versed in that many of them, and oftentimes I still just end up needing brute force to meet my goal, but I’m enjoying the shift as I learn the value of a well-considered solution.