The Solo Developer

Matt Pogue -

Throughout my career I've worked on multiple engagements where I was tasked with cleaning up after a fellow developer who - after anything from writing a few lines of code to automate a process to writing a full blown application - disappeared, leaving the client company in desperate straits. While I was tempted at times to "punish" the client for their ignorance, after evaluating the situation I typically realized that it was not the client who was at fault, but rather the developer who had failed to properly set expectations and deliver a finished product to the customer.

In my current full-time position, I spend more than 50% of my time writing code in support of our in-house project management application. The current version (with some major modifications over the years) was put into production in 2010 and still performs beautifully. However, the world has moved on in the interim, so most of my development efforts at this point are dedicated to rewriting the application to bring it into the modern era.

The point of all this is that I harbor a very low opinion of those long-gone developers I mentioned in the first paragraph. The ones who couldn't be bothered to deliver source code (where appropriate), use a version control system, or even prepare the most basic documentation; and while I am a team of one, I vowed that anyone who came behind me would not suffer the way I have. So in this post, I will outline the steps I've taken to make my small development world a better place for those who will someday follow in my footsteps.

Step 1 - Version Control

Before writing any code, you should decide on a version control system and implement it. Personally, I prefer Subversion as it contains all the features I need - file diff between versions, easy branch/tag capabilities, and compatibility with all operating systems. On Windows, I use the TortoiseSVN client, and on Linux the command line client. If you prefer to host your repositories on Windows, VisualSVN Server provides a nice graphical interface to manage your repositories (although there is a cost associated with it). In addition, the WebSVN project provides a beautiful web interface to your repositories. That being said, any well-established VCS will do the trick, from CVS to Git. Typically, I structure my code repositories with a tags/ directory containing my release versions and a trunk/ directory that contains my current working version. A new release gets its own version-numbered folder under tags/. I've found that this is typically enough; however, feel free to use whatever structure makes sense. The structure you choose is far less important than the fact that you're using version control. I also document each commit, tying as much as possible into my bug/issue tracking software (next section).

While it's important to document and commit your code, don't hesitate to get creative and use your VCS for anything where version/change history is important. For instance, I have a second repository that contains all database-related code and documentation, including:

  • A SQL script to recreate the database schema
  • A backup copy of the database with any seed records that are required to perform a "default" install of the application - e.g. an "admin" user account in the users table, pre-populated quantity/measurement tables, etc., and the SQL script(s) to create it
  • Any miscellaneous SQL scripts that relate to the project, such as data import scripts, performance/troubleshooting scripts, etc.

Finally, I also keep a "devops" repository with copies of all my generic server and workstation config files, miscellaneous scripts, server update logs, and anything else I feel is relevant. This gives me an easy way to keep my scripts, files, documentation, and change logs together.

Step 2 - Issue Tracking

Even as a solo developer, it's a good idea to maintain an issue tracking database as a supplement to the documentation in your VCS. My personal favorite for the last several years is Redmine, however, I've also had success with Mantis and The Bug Genie (now known as Pachno, so YMMV). Redmine provides easy integration with my Subversion repositories; linking to an issue is as easy as putting "Issue #123" in my commit log which provides an automatic link to the issue when the repository is viewed in Redmine. Redmine also allows me to track time spent per issue, customize my categories and priorities, and autogenerate change logs and wiki entries. Between Redmine and my repository documentation, I can easily tell when a feature was added as well as tying a feature to a specific change in my source code. With its support for multiple projects, I can also use a single Redmine installation to track work for multiple clients.

Step 3 - IDE

Without starting a holy war over which IDE is preferable, I think it's safe to say that for C#/.NET development, Visual Studio is going to provide the best bang for the buck, especially considering that my version of choice is Visual Studio Community (free). Since my project management application is composed of several C# class libraries on the backend and and .NET MVC web frontend, the full version of Visual Studio is my primary IDE. However, for almost everything else - including Python, PHP, shell scripting, and Powershell to name a few - I'm now using Visual Studio Code.  With its ever expanding universe of plugins and themes, settings sync via Microsoft, support for Git and other version control systems, and cross platform compatibility, it's hard to beat! As a fallback, on my Windows systems, I always have Notepad++ installed as well. From editing config files to viewing code snippets to debugging JSON from the browser, you really can't beat it. I also use it for making quick edits to scripts and HTML.

Regardless of which IDE you prefer, the bottom line is to find one that does what you want and supports the features you need. Learn it from top to bottom and stick with it. Over the years, I've tried just about everything from Atom to Jetbrains and they've all had some features I liked. However, at the end of the day, I just didn't have a reason to switch, especially since most of my coding is in the Microsoft world.

Step 4 - Miscellaneous Applications

Finally, I want to mention some of the apps I use that are an indispensable part of my toolkit. There are many, many more tools out there that are just as deserving of praise as these and I encourage you as a solo developer to always be on the lookout for apps that can increase your productivity, automate repetitive tasks, or provide those killer features that you can't get anywhere else. Most - if not all - of these applications have alternatives, some of which are probably better, but I'm a big believer in simplicity and stability. Again, that being said, I'm always keeping an eye out for new stuff; constant learning is one of the main requirements of this job. If you're not willing to put in the time or the effort to continually learn and improve upon your skills, you're in the wrong profession!

Here are some of the apps I use frequently to support my development tasks:

  • OpenDBDiff - Diff tool for SQL databases. I use this frequently to make sure that my changes are sync'ed between my Development and Production databases. Quick, easy, and performs as advertised.
  • Postman - API testing tool. I recently worked on a project building out an API and Postman was exactly what I needed to test both locally, in Development, and in Production. The free version is enough for me, but the paid version provides extra features.
  • pgAdmin - the only GUI you need for working with PostgreSQL databases.
  • HTTPToolkit - a relative newcomer to the toolbox, HTTP Toolkit allows you to intercept HTTP and HTTPS traffic from within the browser. Similar to Fiddler Classic, another great tool I've used over the years.

Step 5 - Philosophy

In conclusion, I want to talk a little bit about the philosophy behind the decisions I make as a solo developer. As I mentioned earlier in the post, I take a dim view of any developer who holds clients hostage by not providing source code or documentation on a project, hijacks domain names, or otherwise operates in a way that gives the rest of us a bad name. In order to differentiate yourself from the bad actors in our profession, here are a few suggestions from my personal experience:

  • Whether you're in a full time position or a contract/freelance position, determine upfront what's expected of you in terms of timeline, pay scale/rate, and work output. It should be decided upfront who will own the source code you produce; generally, in a freelance situation, documented source code (including VCS repositories) is part of my final deliverable. If that's not going to be the case, then think about offering some type of source code escrow so that future developers can enhance and improve on your original code in the event that you're not available.
  • Document, document, document! Utilize your VCS and issue tracker to generate "developer docs" in addition to the usage documentation you provide the client. Future developers who have to work on your stuff will thank you for it.
  • Build a solid and stable development environment. This is more of a personal recommendation. As I mentioned, in our profession, we should always be learning and on the lookout for tools that can enhance our productivity or make our lives easier. However, I've found that deciding on a core set of tools and learning them inside and out has made the biggest boost to my productivity. Especially your IDE - figure out how you work best and go with it. If you prefer VIM and the terminal, then go that way. If you're more of a GUI person, then go that direction. Whichever direction you go, commit to it and learn it.

These are some of the tips and techniques I've developed over the years as a solo developer. I'm sure there are many other ways to get the same job done and that's kind of the point - pick what works best for you and stick with it! If you have any questions about this post, feel free to email me - matt@thesoloadmin.com.