I became a solution developer because that when I recognized problems, I wanted to solve them. When I was young, my problem was boredom. Before computers came along in my life, I would build other contraptions using things around the house.  These were usually toys seeing I was less than 10 at the time.  Using little Hot Wheels race tracks that would crash into something, or dominoes that fell over in a certain way to cause other effects.  These ultimately were to satisfy what I considered a problem; myself being bored.  So there I had it, a problem that I wanted to solve, and I used toys to solve this problem.

Once I solved one thing, I had to tackle another problem, and on, and on…  These tools (toys) started as a distraction for me, but I then needed an idea, a vision of something grand and impressive.  To a little boy this tended to end up in something getting destroyed in some way.  But this gave me a new thing to think about, using my imagination to think of something that hadn’t been done before.  I could then use my knowledge of my toys, to fulfill the idea floating around in my head.

It wasn’t long before I started to realize my Legos^© and Hot Wheels^™ didn’t quite have the power to do what I wanted.  This is when I realized I needed more toys (I still do need more toys, but I need to get approval for the expensive ones).  With new toys, I could fulfill more of my ideas, and I was able to imagine new things because of what these new toys could provide.

Along Came a Different Kind of Toy

Then came the day my older brother received his first Atari 400.  I remember he spent months doing paper routes to get enough money to buy it.  This was my first introduction to an almost unlimited toy, the building.  I could dream up almost anything and figure out how to make it do something on the computer screen.  Since I was still a kid, my first inclination was that I wanted to make a game.  Back in the 1980s, magazines were the place you received most of your information about programming.  These were always packed full of full program listings for games.

At the time, I had no idea what these words being typed into the computer meant.  I just knew that when it was done, I had a game I could play.  My brother would often go into the code, change something, and all of a sudden, the game would change.  I wanted to do that. That looked fun.

What I really enjoyed wasn’t necessarily the game that I ended up creating, but the processes that I had to go through to make the game. The failing, the learning, the frustration, and the joy when it all seemed to come together.

Final Thoughts

Over the past few decades, I have started, partially finished, and sometimes finished many projects. I think this is the case for many people with a passion for learning. For my own projects, I often abandon them when they lose the luster they once had, but also when I was done learning as much as I could from that endeavor.

Over the past few decades, I have learned quite a few lessons that I will outline in later posts (assuming you keep reading them, although they will probably be written anyways).

1. It is fine to not know something, it is not fine to not TRY to know something
2. Identifying what problem you are trying to solve is much harder than you think
3. Software is relatively easy, people are hard
4. You always know more at the end of journey, than you do at the beginning
5. Life is more important than work, make your work as enjoyable as you can, but live your life

This hopefully gives you a little insight into who I am, and what makes me tick a little bit, and maybe why I am starting this little site.