The Cranky Developer Manifesto

I spend a good 90% of my week focused on other people. That comes with the territory when you run a software company: training people, maintaining tools, polishing the devops workflow, coordinating with open source developers, and so forth.

A recent dev.to article, How to Fix Burnout as a Developer, put me in mind of the past year. I've burned out. I've spent all my time doing admin and devops work, and virtually no time coding.

Now, I have started carving out more work time for coding, regardless of what else is on my plate. I have to, just to stay sane. However, as much as I love coding at work, there are still a few nutshells in the cookie dough:

• I have to follow company standards. Yeah, maybe easier for me since I helped author them, but they're still there: coding style, approved libraries, licensing policies...

• I have to make sure everything works in our carefully crafted build system. I built that system, so I know it better than anyone else, but that doesn't mean I'm always a fan of working with it. I built it to ensure we wrote clean, efficient, stable code.

• I have to account for project and team needs in all my coding decisions.

• I have to submit to code reviews in most cases, just like everyone else. I'm accountable to my staff for the code I write.

• Performance and portability are always at the front of my mind. It should work, work well, and work on all our supported platforms.

When all those goals and expectations are reasonable, coding is still a fairly pleasant experience, but I'm still coding for others.

The trouble is, I don't operate that way naturally. I am happiest when I'm off in my proverbial TARDIS, doing my own thing, regardless of what other people (or the laws of physics, for that matter) have to say about it.

This is where personal projects are so very important! Working on something by myself, I can do whatever I want. I can set my own goals, and chart my own path there. I have no one to answer to but myself.

And if I want to write terrible code, that's my choice! Yes, I know that sounds horrible, but it's all about escaping expectations. Coders often learn more from mistakes than anything else, and having the freedom to totally mess something up without it affecting anyone else is, frankly, delicious.

So, to achieve this, I set a few rules for my personal project -- a music library application called Elements.

It should be noted that these rules should never be used on an earnest production-grade project or within a company.

Rule 1: It's My Project

Don't ever lose sight of the fact that this is your own personal project. If anyone knows about it - especially if it's on Github - people generally won't be shy about sharing their ideas with you.

To a small extent, that's fine. Someone could come up with an idea that you absolutely love. However, the important thing to keep in mind is that you are the only end-user that matters in this project.

I know that sounds really REALLY selfish, but it's actually quite therapeutic. We spend so much of the time designing software for other people, conceding our ideas to their needs, that we don't actually get to think much about ourselves. A personal project is a great place to remedy this: only your ideas, your preferences, your design sensibilities, and your workflow matter in this particular end result.

It is important that you enforce this boundary for yourself. If you feel like building a text editor with your favorite font and color scheme hardcoded in, go for it. If you only want to support your operating system of choice, and ignore all the others, there's nothing stopping you! If you want to make the entire interface only work via a set of esoteric keyboard shortcuts known only to you, design standards be darned, more power to you!

Now, it may well be that you want to make your personal project usable to other people, but that is a feature you deliberately choose, and it comes at a high cost! You may be best off limiting your user base to specific individuals, and not to entire groups. For example, Elements is built for two people: me and my mother. No one else even factors in right now, and that keeps it fun!

There is one important corollary to this, however, that is necessary to keep you grounded in reality: you need to be your own end-user. Build something you're going to use. Therapy or not, you don't want to get into a habit of writing convenient code at the total cost of design. You are designing for yourself, but you're still designing.

Rule 2: It'll Be Done When It Is

In a personal project like this, you should make it known that you answer to no deadlines or schedules, except the ones you decide to create. Take your time and enjoy yourself!

This rule should go for yourself as well. We spend so much time already trying to complete code according to schedule, with the goal of shipping to production by the deadline. There's nothing like urgency to suck the joy out of a project. So, unless having Target Dates for tasks is something that actually adds to your enjoyment, don't set any. Just glide. It's a rare enough luxury in this field.

This rule is also important, because it makes the next one possible...

Rule 3: Go Overboard

There is a time and a place to avoid creeping-featurism (or feeping-creaturism), but this is not it! Seeing as we spend a lot of time self-censoring our project features to within the scope of practicality and realism, we need an opportunity to let our imaginations run wild.

This means that if you want your custom-build code editor to have a keyboard shortcut that remote-starts your coffee maker, you should absolutely put that on your list of features to build. Yes, that feature may be entirely useless to anyone else on this planet, given that you used a Raspberry Pi and some custom code to pull it off, but who cares? You can enjoy the perks of being able to press Ctrl+Alt+J and brew some fresh joe.

For this to work, however, you need to set a simple regulation for yourself: you should be using an issue tracker, and determining what order you want to build things in. If you spend three months getting the text editor to talk to the coffee maker, and yet you can't run code from your editor, you're probably going to be quite unhappy using the program you wrote. Even worse, if you start on the coffee feature, and then decide to hook up the toaster as well, you can end up putting off the most basic functionality of your code editor while you're off on a rabbit trail.

Instead, you should write down your ideas in your issue tracker, and then decide if and when you want to work on them. It may be that, in four months, you realize that you're not actually that much of a fan of toast at all, and spend that time integrating your favorite static code analysis tool instead.

In short, don't let anything hold you back from planning to add any feature you imagine to your project, but for the sake your own sanity and enjoyment, do make an effort to prioritize those features.

Rule 4: Humbug To Stability

We are often held back from freely coding because of bugs. Professional projects need to be stable above all; it doesn't matter if the program can make toast if it crashes every ten minutes.

In personal projects, on the other hand, stability isn't automatically a factor! You are the only end-user that matters in this project (Rule 1), and you probably know how to not break the software.

You should always keep track of bugs, but feel free to delay fixing them indefinitely. If they aren't bothering you, and you don't feel like debugging them, don't! Debugging can sometimes be fun, but it can be a hassle other times. You want to look forward to working on your personal project.

Rule 5: Set Your Own Practices

Standards are important for ensuring clean code and smooth collaboration. At work, you almost certainly have certain conventions you follow. We also have to consider Good Practice, and more often than not, Popular Practice.

Within your own personal project, however, you should take a break from all these sorts of burdens placed on you by other people. Instead, work out your own personal standards for the project as you go, and stick to them.

Consistent style is helpful in ensuring the code is easy for you to keep working with. If you find you're usually inconsistent in style, considering using AStyle, clang-format, or any number of other automatic coder styling tools to do the heavy lifting for you.

As to everything else, reverse the usual rule: instead of Practice > Preference, make it Preference > Practice. I am completely serious about this! It doesn't matter whether it is considered better practice to use a generator instead of a for-loop in a particular case; what matters is which you'd rather write! You can always go back later and refactor it if you wish, but this isn't meant to be production code; it's meant to be fun code!

Rule 6: License At Will

I don't personally like the GPL, for ethical reasons I won't go into here. At work, we have to tread around it very carefully. However, in Elements, I ran into a unique problem: the libraries that would make my coding experience the most fun were all GPL. After several months of dragging my feet with the alternatives, I finally decided that the license didn't matter on this at all! I could still make my code BSD-3, license the whole project under GPL, and satisfy all the legal requirements.

You're probably going to get the best open source coding experience out of the GPL, whether you agree with the license's aims or not. Find the most expedient license given the libraries and tools you're using, and then move on.

There is another, even more drastic, path you can take. If you have no intention of sharing or releasing the code or software, you can blow off licenses entirely. At that point, you're effectively just studying. You can use bits and parts from completely incompatible licenses, and not even bother to set a license on your own work. Just remember never to let that project see the light of day. Don't put it on Github, don't publish it on your site, nothing. Set up a local repository and host it privately.

The point is to figure out the path of least resistance, both technically and legally. Put yourself in a position where you can use all the libraries and code you need.

Rule 7: You're Not A Diplomat

This isn't meant to be a big, public project, it's meant to be your project. If you post it on Github or some such site, you may wind up with Issues, Pull Requests, and the like from outside contributors. Thus, while you should never be rude, you should set some clear boundaries for how you'll be interacting.

So, on my Github project, I warn people of my expectations. In short, while I'm not trying to discourage anyone from contributing...

• Feature requests may be rejected for any (or no) reason,

• Bug reports may be blown off if I don't feel like fixing them,

• Pull requests may be ignored indefinitely or rejected for any arbitrary reason, and I owe no explanation. It's not personal.

Conclusion and a Warning

I believe it is vital to the health of a developer to have projects just for fun. It keeps our skills sharp, allows us to explore and experiment, and above all, reminds us why we love coding in the first place! To be most effective, these personal projects should be different from Production Code, and that's what the rules above are.

However, as I mentioned before, you should never apply the Cranky Developer's Manifesto to production-grade software projects.

If you really want to apply the Cranky Developer's Manifesto to your project, consider including the following file, CRANKY.md, in your repository:

# THE CRANKY DEVELOPER'S MANIFESTO

I am developing this project for the sole purpose of my own enjoyment.
I make no promises about release date, features, usability, stability,
practicality, or compliance with any normal standards of software
development.

In pursuit of my unhindered enjoyment of this project, the only end-user
I choose to care about in this project is myself, and maybe a few select
friends. The timeline, the features, and the implementation are all
solely at my discretion. I reserve the right to make arbitrary decisions, 
and change them at a moment's notice, without owing anyone an explanation.

If you see something here you like, you're welcome to fork the code under
the terms of the LICENSE and do as you wish with it.

If you're still intent on treating this as a viable project, you're welcome
to submit issues and pull requests. I may respond, or I may leave it sitting
indefinitely. If I ignore your bug report or brilliant contribution until
doomsday, don't take it personally.

If you decide to try and *use* this software, you're taking your sanity
into your own hands. As long as it runs on my machine, that is all I care
about. It may be unstable, or not support your system. I offer neither
warranty nor technical support.

Long story short, I'm just coding for the love of coding!