I built my first desktop app today. It’s also the first real Python app I’ve ever built. Wild.

I build software for fun, but one of the hardest parts of self-guided learning is finding a decent problem to solve. When I’m left to my own devices, I solve problems I consider interesting, and ignore problems that sound tedious. I usually settle on a technically interesting project that has no practical use, build it for a week or two, then abandon it because it has no practical use.

But software doesn’t need to be technically interesting to be useful. Applications with enormous business value can have less than 200 lines of code and they can be built in less than a day.

My first Python app

Today I found an opportunity to write one of those pieces of small-but-useful software. My boss had asked for help hashing email addresses and phone numbers on a spreadsheet, and he was interested in having me build a reusable solution. I’ve been interested in developing Python desktop apps, and I knew that Python3 came preinstalled with MacOS. I also knew that Python came installed with a GUI toolkit called Tkinter. I decided I’d build a Python app with Tkinter to solve this problem.

Four months ago, I watched YouTube videos about Tkinter. I read articles outlining the costs and benefits of USING Tkinter vs GTK. I read docs and tried to understand what using Tkinter would look like.

I learned virtually nothing during the days I sunk into that endeavor, other than the fact there’s a GUI toolkit called Tkinter for Python.

Employment as a developer often presents you with small-but-valuable problems that you’d never think to tackle otherwise. By the end of the day, I had a working Python application. I understand the high-level overview of how Tkinter works. I used Python’s built-in hashlib, csv, os and re modules for the first time. I learned about Python’s with keyword for files. And I managed to do this all while building a working desktop app with under 150 lines of code.

Being pushed to solve these small-but-useful business problems is the most valuable part of doing paid work as a developer. I’ve spent months trying to think of a good starter project for learning Python and digging into GUI development. Had this real-world problem not presented itself to me today, I imagine I’d continue to mull over what to build for quite a bit longer.

So much of my growth over the past year has been driven by needing to solve real business problems with real-world constraints on my time. I started diving deeper into Linux systems administration because I was managing servers to run my apps. I became an adamant believer in the traditional monolith because I could hit tighter deadlines than I could with ultra-modern full-stack JS. I learned about scheduling, queues, Webpack, state machines, email, migrating legacy code, testing and object-oriented design patterns because each of these helped me solve real-world problems when I was building software at my day job.

Looking towards a future of self-employment

In under two months, I’ll be an independent software developer again. I plan to spend some focused time on self-guided learning. I have a shelf full of books that I haven’t had time to finish because of my day job. During the coming months I plan to complete Refactoring, Design Patterns, Clean Code, Domain-Driven Design, Smalltalk Best Practice Patterns, Cracking the Coding Interview, and Patterns of Enterprise Application Architecture. Free from the obligations of my job, I will finally have the opportunity to familiarize myself with these important pieces of software engineering literature.

However, I do worry that without paid work to focus my efforts, I may miss out on building my skills through more practical projects with real-world considerations and constraints. I think that right now, focusing on learning is an investment worth making.

Also, paid work carries no guarantee of improving my skills. I spent the first three years of my career building low-impact WordPress sites that offered little opportunity for me to level up. When building these, I either forced myself to try something new, or I learned nothing at all.

The majority of my growth during my WordPress years came from learning Laravel, Node, ES6, TypeScript and React in my free time. My after-hours investments in these technologies allowed me to graduate from WordPress developer to software enginneer. Making the switch was a years-long process, and it would have never happened had I only focused on the work that was paying my bills.

Uncertainty and exhilaration

I’m nervous and excited for my future as an independent software developer. I’m hoping that my investments in focused learning will pay off the way they did when I decided I wanted to learn Laravel, even though it wasn’t immediately practical or profitable. And I hope that as I build my own projects, I continue to focus my energy on making small-but-useful applications that have real-world value.