Manifesto

One

The Act of writing code is a fundamentally creative process, it's not about putting together the right tools and do some plumbing to make it work. No, it's using tools to craft a work of art. Anyone not recognizing this is an inferior software developer by definition because he or she can replaced by something that also lacks creativity: a shell script or a bot. On the other hand, that bot can be created by a creative person again :)

Two

Good code has no bugs and never had any. As such we can conclude that no substantial body of code has ever been written fullfilling this requirement. Therefore there are no competent developers in this world. This means we have to be humble and respect our limitations. Every line of code will consist of bugs, whether it has been written by us or by some group of people with authority. Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of documentation and lots of tests (testing code and unit tests don't count as LOC). We should distrust every line of code written by ourselves as well as those written by others. The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs.

Three

Standards, design patterns, frameworks and best practices are useful tools but do not alleviate us from the necessity to think. Also, keep in mind that, a library is code, as is a framework. So, every reliance on whatever other piece of code increases the risk of bugs. Standards can help a team to find a common ground and style but may also corner our thoughts and prevent us to excel. So, consider standards seriously but never be afraid to throw them out of the window. In the end, rules are intended to keep people from doing stupid things but without stupid things you are locked into the status quo. The trick is to figure out which ones you need to break to outwit the competition. You'll have to break the rules, or you won't excel. Rule 2 is the only exception to this rule.

Four

Every developer is an idiot. The willingness to admit our idiocy and reflect on it is how we measure seniority. Everyone makes mistakes but those being aware of making them have a fighting chance. That being said, since the act of writing code is a creative process, idiocy is also required. Without idiocy, a bit of abusurdity and fun we limit our minds to a very narrow solution space, bordered by tradition and standards. Nature is full of counter intuitive phenomena. Math, physics, quantum technology and cryptography to name just a few, all work in ways we don't expect them to. To find solutions in a counter intuitive world, our minds need to be freed from unnecessary burdens, remain open and flexible. To free our minds, we need fun, we need bizarre thinking, thought experiments and esoteric programming. We need minds, forever voyaging.

Five

We should be very suspicious about hypes, trends, big communities, large corporate websites and enterprise class frameworks and tools. It does not matter how many people use framework X. If it has a fatal security issue, all those people are going down. It does not matter how big a company is, if it's software is faulty its survival depends on the depth of its pockets, but all its allies will probably just go belly up. It does not matter how pretty the website of your operating system looks. If its init system is systemd, oh well... The only thing that really matters is, the code. Never compromise on code quality. If you can't see the code, it's worthless. If you don't look at the code it's worthless. If you can't read the code it's worthless. If you can't understand the code it's worthless. Also note that all effort in website design could have been used to improve code quality - so always be wary of fancy websites.

Six

While nobody can write good code the best way to try is to keep things as simple as possible. Simple does not mean easy, it means understanding. The whole picture needs to fit into your mind. Also strive to keep things readable, maintainable and enjoyable. Sacrifice everything for simplicity though. The ability to grasp an idea with our mind is the fundament of any well designed program. It's also rooted in the Unix philosophy: make a program do one thing well. As such, never bolt on new features. Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed. Because as I said before, it's a creative process. By the time you have written a requirement you're aleady dead in the water. Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interaction and... thinking. If you want a developer to write a great piece of code, let him or her scratch the itch you're trying to scratch.

Seven

Code does not age well. However sometimes it does. Good old code is like an expensive whisky, there is not a lot and it's sometimes hard to find because of the noise, but it's worth your attention. Mature (and old) technologies, even failed ones, can teach you a lot about mistakes made in the past. If in doubt, look at the age of a software tool. If it's old, it has at least withstood the tooth of time, which is something. SQL (1974),C (1972), UNIX (1971), Smalltalk (1980) and LISP (1958) may not be perfect, but at least they have survived - that's often a clue indicating that the code may be reasonable or some of the ideas may be sound. Still, it's code.

Return to my homepage.