As I put down my year-long investigation into languages and runtimes that was IO Ledge Software and Compare Basic, I have more relief than grief about the process. My inspiration was partly a reaction to what I had experienced across my 15 year career.
This post's title mentions bicycles because it highlights the mechanic of needing different amounts of effort and force while moving at different speeds. The most important thing I've learned over the last year as a solo-prenuer is that the resistance I (and many engineers) face when proposing re-work or in-depth technical projects, has a basis in the idea that building the next gear in the bicycle is a balance of effort and uncertainty that is best evaluated by the need for an increase in the travel speed of the team.
Let's take an example scenario. What is the most common complaint among code-writing and non-coding writing technical staff?.. "Refactoring", everyone I know loathes discussing this. If you're a coder, you want permission to refactor something, and if you're a non-coding professional you want to understand why it wasn't built right in the first place. I had ideas before I started my own venture, but now have way more perspective about it, as the person who wanted the power of the codebase, and to afford groceries, at the same time.
Back to the bicycle analogy. When you start peddling it's usually from the easiest to pedal gear. This is because you need a small amount of effort from your legs to get you off and going. Very soon after that you will upshift into a hard to pedal gear, with higher effort-to-torque ratio. This is to match the speed you are at, and the amount of peddling you will put into the bike. As you accelerate this process continues. Think about what happens if you stay in a lower gear. You pedal a lot and don't go a lot faster.
When a code-writing employee approaches a non-coding manager with a refactor request. The message can sadly be that the code they are using was not written "properly" before. And this may be the case, or the need-for-speed may just be higher, and the team now possesses knowledge it did not have at the time it was originally written. The coding professional with the refactor request is simply proposing to write a gear that can accept the effort of the team and appropriately generate the speed they need to move forward.
But here's the catch, is the bicycle traveling fast enough to need the new gear? And if it is not, will it be soon? It's very common to look longingly into the future, especially if you dream in code the way I do and love the power of a massively flexible system. The MVP approach, asking users for feedback during user-testing, and Agile in general is designed to make sure the future focused "Perfect is the Enemy of the Good" paralysis does not set in. The refactor discussions that go well in my opinion are not the ones that avoid commenting on how badly written it was originally, but focus on what the new gear of the bicycle will do, and what speed the team will be able to move when it is complete.
This is no longer a discussion about tech debt it's a discussion about tech leverage, about how much more work a better lever can lift, or a better gear can power.
I learned the hard way that this process of "building the gears" left me with little to show for my efforts, and a very challenging fundraising path at times. Several components were built and rebuilt until they had the power I wanted them to have. BasicTypes is on generation V, CycleServe and Templang are both on generation III. And while they function exceptionally better compared to previous iterations, the process of having nothing to show left me with more empathy towards non-coding professionals' resistance to "not refactor" than I have ever had before.
As I hang up my "I can do it myself" badge and head back to a Senior Engineering position in the industry. There is one thing I am looking forward to more than anything... Code Reviews. That's right, the thing I did not look forward to is my new favorite. There is something about an idea that is seen from multiple places that makes it much more fulfilling than being a lone-wolf independent voice. Across my two ventures, I wore all the hats myself. I have gone without a code review for almost an entire year. I've done projects where I was the sole author before, and know first hand what one engineer's bias can do to a code base. That was an expected compromise when I set out to build so many of the components myself, but what emerged was an unexpected understanding and level of empathy for why certain practices are discussed and certain responsibilities are shared.
I've always known that a focus on core-components was very powerful. But having the ability/blind-spot from rebuilding everything all the time has shown me just how important discussing the approach of a software project is, and possibly how much more could have been done at the companies I used to work for to discuss the approach further.
I've always been an optimist (to a fault sometimes) and I'm very excited to join the industry again.
Both Compare Basic and IO Ledge Software were companies I started from my own ideas, and ran for around 5 months each as the only member of the team. Both were born from ideas I had been kicking around for several years. Some dating back to ideas I proposed at my interview at Shutterstock in 2011, a few during my time at HavenTech that were cut because of timeline constraints, and a few more from my experimentation in C in the evenings while I worked mostly in JavaScript for mid-sized companies.
But there was also a dark side to why I went out on my own. I had a lot of pent up frustration from the work I was asked to do as being too shallow or short-sighted. Having the chance to see first-hand how risky, volatile, and invisible some of my ideas were has been an amazing experience. I come back to the work force ready to embrace the balance of building components in-house vs borrowing them from libraries, and with ways to propose and discuss work with a favorable light about what is being done along with how it is being done. If I had taken a year to travel the world to air out after 14 years in the tech industry, a lot of my friends would understand, I like to see this time as a tinkerer's safari, an adventure that let me see all the wild animals. To quote nirvana:
I'm so happy because today I found my friends... they're in my head.Nirvana
I say this as I look forward to working on a team again, and as recognition that being kind to myself is an often overlooked part of a software engineers day. Wish me luck as I search for a new home for my full-stack software engineering skills, it's been a crazy year, but I feel a lot less crazy than I did this time last year, it's odd how challenging times can be grounding times as well.
If you or your company has an interest in my skill set, I am seeking to be a software engineer in a full-stack role, remotely from my apartment in Iowa. Resume available upon request.