Software Craftsmanship: What Have I Learned So Far?

Not long ago, Vega IT organised a “Book Week”, where we were invited to read the book of our choice from our internal library and share impressions with our colleagues afterwards.

One of our colleagues had nothing but the words of praise for the book “The Software Craftsman” by Sandro Mancuso, which was enough to convince me to grab the book myself and learn more about the perspective of a truly exceptional professional from IT industry.

As I was reading the book, I took notes and highlighted some sentences that reminded me of my own journey as a software developer. A number of times I could identify what I read with real-life scenarios which I have encountered on my journey. Here are some of the notes I found particularly interesting and familiar.

"How it is done is as important as getting it done"

The time we spent at university went fast. With each test which we took, every grade was on the line. Working software was the primary unit of measure - the barrier between a failed and a passed test.

Sometimes we got only 30 minutes to make the software work. Sometimes we had about two weeks to write a project, but as we were constantly interrupted by other responsibilities, the main goal remained the same: Make it work, by any means. Most graduates had this “make-it-work” attitude when they started their first jobs. Just remember yourself when you were a bachelor. Your attitude was probably something like: "Working software? What could possibly be wrong about it?".

When I was still studying, I decided to apply for an internship at Vega IT. I got a mentor (a great dude if I may add), who provided me with a plan and well-defined tasks. The goal was to build an internal app replica. After I finished with my initial tasks, the outcome was as I expected - everything worked. Perfect, if you ask me - at least at first glance. ;) Once I was “done” with some tasks - this great dude suggested that we should get back to some of the previous tasks, and try and figure out if they could be done differently. I was wondering: “It works very well now. Why should I return to what I have already finished? “.

The mentor introduced me to some (edge) scenarios, proving that the code indeed had a lot of space for improvement. At that moment, I figured out that we should have taken some time to analyse a piece of code before we call it a day. This was the first time I was requested to rewrite something that already works.

Later on, as the app was growing, it was clear why the changes had been imminent. As hard as it was for me to swallow this, after some time I finally understood the significance of carefully choosing a way to write something, or at least taking some time to consider other different approaches. I suddenly realised that it is not only important that it is done - it is important how it is done as well. Moreover, how it is done is as important as getting it done.

"If we think that a piece of code we wrote some time in the past is still good enough today, it means we didn’t learn anything since."

This sounds brutal, doesn’t it? But let’s get honest for a moment. When you look at the code you wrote during your student days (or for example last year, if you are still one), does it look to you as good as it once did (particularly at the moment you realised it worked)?

Evolving is a natural process of every professional, especially in an industry with ever-changing nature, as it is ours. Being able to rewrite and improve our own code every once in a while, means we learned something new. In other words, we are eager to make ourselves better which, in my opinion, is one of the key values that define a true professional.

“People who are always eager to learn and do things in a better way are always looking for opportunities to work with people who are better than them."

Have you ever felt you are being overlooked when trying to share some new ideas, suggest changes and new approaches and generally make the project evolve?

Some people tend to stick to their comfort zone, where they are perfectly aware of everything that is going on. In such a scenario, they tend to follow the defined template, without paying much attention to any possible alternatives to the existing well-defined routes. This kind of attitude is the last thing you want to be surrounded by.

What I’m thankful for is having a team which is constantly looking for different ways to make the project better and more stable. Being surrounded by the people who have different opinions than you, and are willing to share their knowledge is a highway to success. When you’re in an environment like this, the rest is only up to you. Take the ride, it’s highly rewarding. :)

"The day we convince ourselves that there is just one way of delivering software - is the day we stop evolving."

Let’s get back to the second note for a moment. What happens when we do find a better way to write something and we rewrite our code making it more optimal? We feel amazing. But, is that it? Did we just write the best code possible? Is there even such a thing as “the best code possible”?

What made us rethink, try and rewrite out existing code in the first place? It is our willingness to try new ways to do things - and this should always be our mindset. Every once in a while, we should spend some time trying to rewrite the existing code. One thing is for sure - when it comes to delivering software, there is never just one way to do it.

"If you want to bring passion and motivation to a development team, make sure you bring in a few software craftsmen to join them."

Like in any profession, demotivation might be lurking from any corner. However, that does not necessarily have to have anything to do with our feelings towards the job itself.

In my opinion, to keep their spirits high, developers need someone who is closer to them in terms of their profession - someone they can relate to. Sandro wrote it perfectly: “The best person to motivate a developer is another developer. A software craftsman. A developer whom other developers can look up to, who can inspire them.”

Back to my story, an experienced developer from my team approached the rest of us, and completely spontaneously started to share his story. He was explaining the significance of the knowledge we are going to gain along the way as well as our contribution to the project. He even went on to share some interesting anecdotes from his career and previous projects. At that moment, he related to us and I’m still thankful that he recognised that this type of talk was just what the team needed. It also made me realise how important it is to have a team player willing to motivate the colleagues he is surrounded with.

"Software craftsmanship is about professionalism in software development." - It is a journey to mastery.

What do all these values and approaches bring to us after all? Why should we care so much about spending all that free time improving ourselves if, at the end of the day, it is just a job?

Well, If I have learned something through my career so far, it is that software development is not just a regular job, but rather a journey full of exciting challenges. It is how we approach those challenges that determine how we are going to deal with them. It is how we deal with the challenges that will drive our motivation towards the ones that are yet to come. It is our motivation that makes us eager to learn new things. And, being eager to learn is what will eventually help us achieve our goals - and finally reach the ‘mastery’, whatever the term represents for us.

So, cheers to all the great dudes, craftsmen and journey-loving software developers out there! :)