A software craftsman’s manifesto

I am a software developer and I would like to be one for as long as possible because I like what I’m doing. In the past, I thought I would have to put my keyboard aside after a few years and switch to working with Excel tables, constantly writing e-mails or attending endless meetings. Luckily, I discovered something that changed my attitude towards what I was doing and what my future could look like. So, I would like to share with you my idea of how to become a better developer and have a safe future in the IT industry.


How I became a craftsman


The defining moment in my career was when I chose to become a software craftsman. Have your ever heard of the Software Craftsmanship movement? After the announcement of the Agile Manifesto at the beginning of the 21st century, the entire software development world became intoxicated with the idea of rapidly delivering functionality to production. Unfortunately, many companies paid for this with the reduced quality of the software they were developing. The most important thing was to add as many features as possible in a given period of time. When the deadline was approaching, developers would make more and more mistakes due to the pressure and would fail to ensure the reliability of their code. The sad fact was that people often forgot that the program they were writing would be used for a long time, and that changes to the code would not be made by the developers who originally wrote it. I’m sure many of you have worked on code (not always “inherited”) which had not undergone unit testing and was written in an obscure manner. Every modification was risky. A change in one place would cause things to stop working in another area of the software. As a result, it took more and more time to add new functionality, and eventually it turned out that rewriting the program from scratch was a better option. This annoyed people like Robert C. Martin (known to all developers as Uncle Bob), who proposed adding a fifth value to the Agile Manifesto at the Agile 2008 conference: Craftsmanship over Crap (please excuse the language). In the early 2009, a group of developers willing to challenge this state of affairs published the Manifesto for Software Craftsmanship, which expanded on each of the values of the Agile Manifesto:

  • Not only working software, but also well-crafted software
  • Not only responding to change, but also steadily adding value
  • Not only individuals and interactions, but also a community of professionals
  • Not only customer collaboration, but also productive partnerships

While more than 24,000 people have signed the Manifesto to date, the above items may have a different meaning to each of them. What does being a software craftsman mean to me?


Pay your debts


The first value of the Manifesto refers to well-crafted software. I believe that each of us tries to write good code, but we sometimes do allow ourselves to abandon good practices when working under time pressure. First and foremost, the code you write must work, but it is also important to keep it clean. Remember that at some point in the future, badly written code will be unintelligible not only to others, but also to yourself. Next, if your program’s code is to be reliable, it must be adequately covered by tests. Otherwise, any subsequent change will entail lots of stress and risk. If you incur technical debt due to time pressure, you must find the time to pay it back. So, set aside some time for that, and the project will only benefit in a longer term. Paraphrasing the motto of one of the houses in A Game of Thrones, craftsmen always pay their debts. A software craftsman should leave the code in better condition than when he or she received it. All this is done in order to extend the lifespan of the program you are writing.


Talk about risks


You should not blindly follow the assigned tasks. Instead, you should look out for risks and communicate them to the right people. For example, if a task description does not clearly state that security must be taken into account (probably because someone forgot to include that), it is in your best interest to incorporate the required security features and inquire about the details with the person who defined the task; this will benefit everyone involved. When a supervisor or client asks whether you can finish a task on time, tell them the truth. If you feel that the probability of missing the deadline is 90 percent, communicate that well in advance. It may be possible to reduce the scope of functionality so that your business partner does not have to risk losing trust and reputation due to unfulfilled promises, either.


Keep developing your skills


A professional developer should constantly hone their skills. To do your job well, you need to invest in yourself – that’s a simple fact. You need to spend some of your spare time (and often money, too) on improving your skills. Unfortunately, there is an increasingly widespread belief in our industry that unless your employer sends you on a training course, you don’t need to continue your education. In his book The Software Craftsman (which I recommend to anyone who takes their job seriously), Sandro Mancuso goes as far as to compare developers who show that attitude to repairmen who ask you to fund their training when you call them about a service (e.g. a plumbing repair). You can be grateful to your employer for the opportunity to attend courses and conferences they send you to, but you cannot blame them if they don’t do that. You should stay in control of your career. If you don’t take care of your future, nobody will do that for you.


Share your knowledge and build a community


We often complain that our younger colleagues have written outrageously bad code, but did we really take our time to share our experience with them? By teaching good practices, we are changing our environment. Which one of us would rather work with botchers than with professionals? If you open yourself to other developers and actively contribute to the community, this will affect not only the development of your technical skills, but also your mental state (by reducing the risk of having to work with badly written code). Mentoring is just as important to the pupil as it is to the master. Frequently reinforcing the basics by explaining them to others helps consolidate the knowledge in your memory. In addition, I also recommend opening yourself to people from outside your closest circle of associates. Whenever you learn something new and interesting, write about it on a blog, present it at a local meetup or attend a meeting of your local developer community (e.g. JUG). This way, you will get in touch with other craftsmen who also want to share their knowledge with you.


Uphold your reputation


Always remember that your are not a production line worker but a skilled service professional. So, start treating your employer or client as a partner. Your employer may not be aware of all the technical intricacies with which you are familiar. If you see that there is a better way to solve a problem or that a small functional change may save your team a week’s worth of work (and a lot of money to the client), talk to them about it. If you treat your client/employer seriously, they will treat you in the same manner. You need to uphold your reputation.


Sleep peacefully


What benefits do I get from being a craftsman? Peace of mind and a sense of fulfillment when I come back home from work. If you think about both functionality and reliability when writing a program, you can sleep peacefully. When you hear that something has gone bad in the production environment and angry users with pitchforks and torches are demanding justice, you’ll know that it’s not your piece of the software that caused the problem. If you write “clean” code and make sure that your colleagues want to do the same, you’ll be able to go to work with the reassurance that you’re not going to deal with something that’s likely to turn into a headache. We all spend a sizable portion of our day at work, so let’s do what we can to make the best use of that time.

By Paweł Młynarczyk – developer working tirelessly with Java for the last 10 years. He codes, does DevOps and helps his younger colleagues grow as professionals. From time to time, he can be heard at IT conferences, and he uses every available opportunity to learn. In his private life, he is a dad and a lover of comics and Czech cinema.

Leave a Reply


From reconnaissance to reporting – about the security testing process

From reconnaissance to reporting – about the security testing process

Penetration testing (or pentesting) is an authorized process of finding weaknesses, vulnerabilities and security risks, in order to prevent them from being exploited by potential adversaries. We will go through the basic methodology and more technical (and non-technical) details of the penetration testing process.

Business continuity in times of crisis and RPA technology

Business continuity in times of crisis and RPA technology

The COVID-19 pandemic has created a crisis the size and scope of which no one could have previously imagined. What is more, it is more severe than most crises before – it has led to a revolution on an unprecedented scale, bringing almost the entire business world to a standstill and creating quite a challenge for organizations.

From reconnaissance to reporting – about the security testing process

From reconnaissance to reporting – about the security testing process

Penetration testing (or pentesting) is an authorized process of finding weaknesses, vulnerabilities and security risks, in order to prevent them from being exploited by potential adversaries. We will go through the basic methodology and more technical (and non-technical) details of the penetration testing process.


strzałka przewiń do góry strony