/ software development

The Best Way to Become a Better Software Developer

Online courses, conferences, webinars (I hate that word), code academies, software gurus, CS degrees, open source projects, mentorships, books, code challenges, bloggers, vloggers, and on and on and on. These are all good things and great ways to learn. Great ways to become a better software developer. We live in an age where education is readily available. There's so much of it, you can get sick from devouring too much at once.

I have benefited from all of the above and continue to do so. I owe my livelihood to thousands of people who have published things online in the form of blog posts, Stack Overflow answers and forum replies. I'll never be able to thank all these people for the concepts they've taught me or the bugs they helped me fix. I've learned a lot from reading and interacting with helpful people on the Internet.

But there's one single practice that has advanced my skill set as a software developer faster then anything else. Not learning a new framework. Not getting a better job at hip new company. Not years of experience slinging code. Nope. The one thing that has benefited me the most in my career is building software products from start to finish on my own time.

Nothing else will catapult your abilities as a developer like forcing yourself to complete a product that you hand over to the world. Not just a product. Your own product. Not just for yourself to use, but something you put out publicly. Something people inevitably complain about because you left out feature X, or because you have the nerve to charge money for it. Something you have to go back and improve, add feature X, only to find they complain about something else. And they're usually right.

Building your own product from start to finish is baptism by fire. No online course can teach you what you'll learn on your own if you're truly committed to finishing your product. You can't hand part of it off to the back-end specialists because databases aren't your forte. You have to become the back-end specialist and learn that database. Likewise, you can't hand off the design to someone else because you are the designer. When you create your own product from start to finish, you wear many hats and become extremely resourceful.

Software development is a great career, but it's often kept at the office. Few developers venture out and create something on their own from start to finish for fun or for profit. And that's a shame because it's very rewarding to create something on your own terms, outside the confines of the enterprise and its limitations. It's also not easy to work eight hours a day only to go home and code four to six more hours. I get that. But, it is possible.

I have four failed startups and a few other products under my belt over the past several years. Even though none of my products made me rich or gained me notoriety, they did teach me a hell of lot about software development. Below is a list of things I've built and how they advanced my skills as a developer in reverse chronological order:

Gear Offer (2017 - present)

Landing page here
This is my latest startup product. It's a marketplace for buying and selling camera gear. I've been working on this thing for just over a year now and it's almost done. The amount of learning that's come from this product is huge, but below is quick summary of what I've picked up:

  • .Net Core 1.0 to 2.0 - I decided to use .Net Core (MVC) for this product and couldn't be happier with that decision. A few months ago I was able to build a web app for a client because I had previous experience with this technology that nobody in the enterprise has even touched yet.
  • Marten - Instead of using the typical stack including Entity Framework, I opted to try out Marten for my data layer and I'm glad I did. This likely won't translate into anything applicable to the enterprise, but it has exposed me to the world of document databases (using PostreSQL).
  • Stripe - Because this product facilitates financial transactions, it uses Stripe Connect in the background. Learning the Stripe API's has been a great experience. These guys know how to design a good API and they back it up with good documentation.

Down to Zero (2014)

App store link
Oh how I miss Windows Phone. I wrote an app for it and put it out into the cruel world. It was reviewed by Windows Central and did pretty well in the store...for a Windows Phone app. What I learned:

  • Mobile app development is a completely different animal than web app development. Being my first attempt at a mobile app, this was a hard shift in thinking but definitely worth the struggle. This app turned me on to mobile development which eventually became my specialty.
  • App store users are picky and not afraid to complain. This was a bit surprising but it shouldn't have been. People will complain about your app, especially about paying for it.
  • Design is hard. I had to come up with my own design for this app and it took more time then any of the code. There aren't many ready-made app designs like there are for the web (think Theme Forest) so you really have to come up with your own design when creating an app.

Togspots (2013)

No link for this product because I killed it. Togspots was an ASP.Net MVC web app that allowed photographers to add and find photography locations. It was a fairly sophisticated web app and worked reliably. I was never able to get many locations outside of Arizona but boy did it have a lot of local spots and vibrant local community. What I learned:

  • Working with geolocation and maps is difficult, but really fun. It's rewarding to see things working on a map for some reason and I became proficient with the Google Maps API.
  • Azure is pretty sweet for web apps. This was early on for Azure Websites as it was called then. I think it was a beta when I launched the product and SSL wasn't supported for several months of Togspots' early life.
  • There was lot of client-side functionality on this app so I got much deeper into JQuery as a result.
  • I also learned that people wouldn't contribute photography locations unless they were coerced...sort of. Users loved searching for photography locations but not adding them so I would allow users to search three times for spots, but they would have to add at least one spot if they wanted to search more. This worked exceptionally well.

Milvio (2009)

A friend of mine worked in the legal industry doing document support for law firms. He had this idea for a web app that would allow legal secretaries to submit documents to the print staff and the app would show the print jobs on a large screen TV with various statuses. This was the first web app I ever wrote that used audio prompts. It was built using ASP.Net WebForms. What I learned:

  • I had to got deeper into client-side development on this one and JQuery was still pretty rough at that time so there was a lot of plain old JavaScript to figure out.
  • Again, design is hard. I started with a template but had to adapt it to our use which proved difficult but I was proud of how it came out.
  • Big companies are afraid of tiny ones. I completed the app, my friend's employer loved it and wanted to license it...until they found I was just one guy. They got spooked and decided not move forward.

Clover Content (2007)

This is the single most ambitious product I ever created, even more so than my current product, Gear Offer. Clover Content was simply a CMS with no front-end. It was a CMS as a service marketed to web designers. It allowed non-programmers to add some JavaScript, PHP, or ASP.Net snippets to there otherwise static sites and it would pull content into their web pages via API. There was a back-end that they could log in to and add content. I had client libraries for ASP.Net, PHP and JavaScript. It was a really complex product and failed miserably. What I learned:

  • I picked up a lot of general software architecture on this one.
  • I designed a large API using WCF. At the time, WCF was the bees knees so this skill translated into serious benefits at my day job.
  • Writing client libraries in different languages and maintaining them is no easy task.

This list isn't really complete, there are a few false-start products missing, and some client work I did on the side, but it's complete enough to get the point across. Building products from start to finish advanced my skill set in ways nothing else would have, exposed me to new concepts and forced me to become a more resourceful developer. If you're looking for a way to improve as a developer, I recommend turning off Netflix and building something.

The Best Way to Become a Better Software Developer
Share this