Surviving the Marathon of Innovation & Learning

As a child my father never would give me an easy option. For some reason or another he always believed I could find a way. Perhaps that is why I have made this career in technology. I found since the beginning of my journey into technology no problem is unsolvable. Perhaps just not abstracted enough or I just did not have the skill yet to overcome it; That never prevented me from believing I could accomplish the task set out before me given enough time. As my professional software career has progressed I've gotten faster at solving problems and learned new ways to approach them.

Just Start

Often no matter if it is a side project, an innovation effort, or your main job; Commonly I find developers spinning in whiteboards and dry erase marker ink. They want the perfect architecture or some perfect design to scale to handle an arbitrarily high number of users. When I started in technology writing my first professional programs I didn't have the luxury of management who understands the product discovery process. Instead they watched me Google random things, read, and draw diagrams and asked constantly if "I could just do it in excel like I used to?". I knew there were better ways, and I had to find them. Before I learned what Agile was, I was delivering MVP's and iterating to deliver Return-On-Investment as fast as possible so I could keep building cool programs to do my job for me. I learned an important instinct to be able to call out "well enough" and begin coding towards my first success in a project.

Product discovery is a hugely important piece of software architecture, but as a leader and developer, it's more important to get developers like myself into solving pieces of the problem domain with code early and be accepting when pieces need to be refactored or completely re-architected. Often I have found once a developer gets "into the zone" and actually dealing with the realities of a code-base we generally can have more contextually driven conversations about the road ahead. Fundamentally that is what we want, to deliver minimal viable value and iterate towards perfection. You'll never reach the edge of the solar system if you wait for all the supplies, sometimes you just have to buy all the aluminum foil in town. Voyager nearly missed her voyage to the ends of the solar system due to the long process it would be to properly redesign the spacecraft's shielding. Instead they called the audible and wrapped it in aluminum foil. Taking the risk and reaping the reward.

Don't be Afraid of the Big or Complex Pieces

Sometimes software projects have large pieces that just can't be broken apart. Some pieces of a project are large and/or difficult. I believe that kills a lot of side projects when learning a new technology stack. Often on projects I have been apart of those tasks are the ones brought to the very end of the timeline and cause everyone to stress over if it'll even get done.

My advice, jump for it. Take the leap of faith and get something into a file. Often writing a piece of code in its' worst form is easier to refactor opposed to getting it right the first time. With proper testing practices to ensure it behaves the way you expect, often you'll find the MVP form of that task's completion criteria and the stress on yourself and/or your team diminishes. Now you can iterate and experiment inside the guardrails that you've built in the MVP form.

Reduce Assumptions as Much as Possible

Often I have prevented myself from accomplishing an objective sooner only because I assumed I knew what the context of the problem was. Sometimes just Googling a piece of the error you think you know can yield knowledge you may have tucked too far away. That's okay! We have to keep so much up in our heads all the time! Keep a few books around for beginners and when in doubt search for the nearest assumption you are keeping and lose it!

My caution though is always remain confident. The only assumption I never allow myself to lose is my assumption there is a solution. In the end it all compiles to 1's and 0's. The shoulders of giants we all stand on turned time-sharing machines into the modern marvels you read this on. You can solve any problem you set your mind to when you keep that small fact in mind. Remain confident in the face of defeat. Sometimes life gets the best of you; You'll fail on a project at work or accidentally abandon a side project at home. Like my father before me I never assumed failure left me lesser a person than before, only wiser if I should choose to learn from it.

Finally: Never Stop Learning

With those three tips in mind never approach a problem as if it were minimal compared to others. Our industry is blooming with technical problems. Some common ones yes, but each an opportunity to learn or develop a skill we previously had not. Even in failure or retirement of a project we can continue to learn from that. One of the most wonderful things about our industry is its' ability to provide personal & professional development with everything involved in it.

Reach beyond what you believe you can do. If you're a JavaScript developer, try some GoLang or Java. If you're an embedded programmer, enjoy the playground that is JavaScript. Join technical communities & meetups or listen to podcasts & interact with their communities. The most common meme I see in the community is that there are sharp edges where people can be hurtful. Whether intentional or not, learn from it. I've bickered with the smartest and the most vulgar sometimes, but I never am the lesser for learning from their experience and growing because of it.

I hope this helps someone like myself. These are things I learned over the course of my career so far, and I had such great people like the CodingBlocks Podcast community to help develop these lessons. Feel free to leave feedback or reach out to me on my social media if you have any further comments or remarks!


- James