Advancing the Craft with Side Projects
Invest in yourself and share the dividends with fellow developers
The evolved relationship between you and the code
Many developers’ careers began with side projects. A spark of passion lit with learning the fundamentals of a programming language by developing small applications or static webpages. The novel, exhilarating experience of watching the live server update the background color of the browser page by changing one character in the Hex code. Perhaps you can relate to the experience of making a simple to-do list, cultivating a portfolio site to showcase your budding skillset, or searching for a free, open-source API to attempt CRUD.
But then, the duties of the job has its demands. The time since you last worked on a project of your own interest continues to grow. The consistent turnover of new stories assigned to you, or the never-ending list of priority bug fixes to work on, becomes the norm.
Inspire passion and adventure on your terms
Software development requires commingling of the left and right brains. It’s an art. You are creating something that didn’t exist before. It has a design, and plans are made to ensure it is aesthetically pleasing. But it’s also a solution. Analytics and problem-solving are very much at play.
I’m convinced that side projects are essential to advancing the creative and applicable skills of software development faster and more deeply. Will developers naturally grow with the duties of a job? For the most part, yes. However, there are several benefits to working on something of one’s own choosing that provides the freedom to boost not only technical repertoire but also interpersonal and leadership capabilities as well. Let’s try to relight that flame in 2023!
Collaborative Side Projects
At Slalom Build, opportunities frequently arise for builders to participate in internal projects. These opportunities can range from simple challenges with fewer than 10 hours of time commitment to more complex MVPs that may take a few months. With team side projects, you get the benefit of the collaborative experience but aren’t confined within the parameters of a typical work project’s requirements. It’s a networking platform to connect with coworkers (or peers). Roles are more flexible and time is a more plentiful commodity.
In the Quality Engineering capability at Slalom Build, we have an initiative for building reusable technical artifacts accessible to all our QE builders globally. It’s basically a bank of reusable test automation frameworks for Builders, by Builders. I was recently a part of a team of five Builders that created a framework for mobile application testing. I previously had no experience with mobile apps, but this opportunity gave me the chance to get my hands dirty with both Android and iOS testing.
The gains from this commitment were much more than I anticipated. I thought “mobile testing experience sounds cool,” but what I didn’t realize is that I would get the opportunity to work with fellow QEs from my Build Center that I typically don’t get the chance to work with. These teammates are now additional resources that I didn’t have before, who I can lean on for assistance or guidance in future project assignments. The nature of this project lent itself to a lot of spike stories where I was able to gain a deeper understanding of mobile app testing through lots of research. I also had the chance to try out different aspects of the tech stack that wouldn’t ordinarily be assigned to me, such as building the pipeline for the repository.
Solo side projects
Software collaboration is extremely important for delivering excellence in products. However, there is also a great number of benefits from practicing and trying out new languages or frameworks on your own. These benefits often stem from simple freedom. Freedom from timeline pressures. Freedom to choose. Freedom to chase down the rabbit hole or the freedom to completely throw something away and find ways to improvise.
When I was working on the reusable artifact team, the language and framework was already set by someone else when I joined the project. In a solo scenario, you are calling all of the shots yourself. Picking the language, choosing the framework, finding cool packages. It’s all on whatever drives your interests.
When the project relies solely on you, it often forces you to go deep. You are going to run into brick walls. You’re code is going to run fine today, but when you pick it up tomorrow — it’ll be broken. The success of the project will all be on you — your ability to weigh the pros and cons of optional solutions. The pressure cooker of having to rely only on yourself and the resources you have to your disposal is a table set for new territory. The luxury of calling on a teammate for a bailout isn’t there. This newfound territory is what will make the project worthwhile for you and the ones you share it with.
Moving the needle
The next part, after the completion of a side project, is what makes impact: sharing. In work projects, we are most familiar with the sharing portion as the wrap up of a sprint — demo day. But there are many ways to lean others into what you’ve experienced — leading a lunch ‘n learn, sharing the code repository with a reviewer, collecting volunteers to test the end product, creating a video tutorial, or writing an article.
The platform of sharing should be viewed as another way to challenge yourself. Choose the option that you are least comfortable with or the option that aligns most with your goals because remember the pressure is off — it’s simply a side project.
When you share, of course it’s a great opportunity to showcase your triumphs — “look at what I made!” — but what is going to stick with people more, long-term, is the vulnerability of “this was my plan, this was went wrong, and so this is how I pivoted.” When I’m a receiver of someone sharing his or her experience, the note taking moments for me are the “don’t do this option because it’ll take hours to fix” guidance. Save the highlight reel for social media. The transparency of your experience is what will be remembered and allow others to improve based on what you were able to discover from your experience.
Sharing is not only an opportunity for those in attendance but it’s also a good measurement for you on how well you’ve accomplished your set objectives. A good mark for gauging one’s depth of learning is one’s capability to teach it. “I understand, but I can’t explain it” is not a great place to live. Go deeper.
Be sure to set the tone of the environment for however you choose to share with a “let’s be partners in learning” aura. Someone digesting your material may be privy to the technology and could add to the conversation. Encourage commentary; just be sure to establish conditions for it as you deem appropriate. Welcome questions and critiques with a positive spirit.
Parting challenge
The break of a new year is often a time period of goal setting for many. Consider investing in yourself this year. Stay humble and curious. Make a goal of “I want to work on x number of side projects this year,” or keep it broad with “I want to look into x framework by the end of May.” Commit to reigniting the flame then stoking it to keep it going!
And be sure to keep in mind the ripple effect that occurs when you invest in yourself. The end goal is to share and help others to advance the craft. Be vulnerable. Be transparent. And if you are anything like me — take notes along the way so you don’t forget anything important!
Wishing you, and everyone around you, a big return on your self investments this year!
