A good programmer with great habits: a thought on Kent Beck’s quote
The one you are about to read is my favourite quote.
It struck me from the first moment I heard it; you can also find it as a “mantra” in the description page of my site, in fact; this is because I believe it’s a phrase that marked a turning point for me.
I’m not a great programmer. I’m just a good programmer with great habits.
Boom. Powerful. Powerful, almost revelatory, at least for me.
There was a long period of my life in which I lived with the feeling that certain topics regarding Software Design were light years away from the reality I was in, away from “my” reality and from the work possibilities within my reach.
TDD, BDD, DDD, CQRS… A myriad of acronyms and buzzwords that represented advanced concepts that have always seemed an unreachable utopia: everything seemed so far away, so impossible to implement in the usual working realities such as those in which many of us work; only “they” do it, only “they” succeed.
They.
Legendary, mythological figures, in my head comparable to the Minotaur. Elite developers, lucky to be in the right companies and super gifted in terms of intuition and skills. The distance I perceived between me and advanced software design concepts was really comparable to the distance to a science fiction movie: very cool but practically impossible.
Then, in the last year and a half, I had the chance to work with some developers very skilled in those topics. Thanks to their mentorship and in-house training I started to realize how concrete these concepts were, how attainable they were by putting in the right amount of dedication, interest, passion, commitment and desire to learn. I found out how useful they could be to any business and that is possible, then, to see all of it implemented for real.
The first time I understood something about TDD, I realized how the basic principle of the technique is simplicity; indeed, the idea is really about not complicating things more than you have to, as little as possible. The technique explicitly suggests to advance in small steps, one test at a time; find the simplest possible solution first, so it will be easier to improve the design.
Domain-Driven Design is also a good example: when I started to hear about it, everything seemed linear, simple, consistent with my way of thinking. But I didn’t know its name, its key concepts and all the way of thinking that’s beyond it.
I don’t want to be misunderstood: I am not trivializing the complexity of these topics, which is evident, especially in the practice side. Also I still am a newbie with some of these topics, far from mastering them. What I have realized, however, is that they are within reach.
Perhaps, at the base of this reverential fear of mine there was low self-esteem, a lack of belief in my abilities. The classic impostor syndrome.
I can see why many developers are affected by it, it’s not surprising considering how much knowledge there is in the world: you always feel like you don’t know enough. My 2 cents: you will never know everything!
At the same time I say to you: ignore that feeling!
Each of us can understand any topic by studying and applying ourselves with passion and dedication, maybe without necessarily becoming a Ninja but becoming able to use them for our daily work in a profitable and effective way.
If you are driven by the desire to grow and curiosity to learn, don’t be held back by fears of any kind, jump in! Keep improving, ask for feedback, work on yourself to find the way that allows you to realize this desire.
In my case, the low self-esteem is something I always had and, for example, led me to think that studying the theory of a topic was not good for me; I never felt satisfied, like I got it but then forgot it immediately. I had to fight myself and force me to get over this, learning some study techniques that helped me a lot. Find your weakness and fight it! You may not solve it entirely, but you can definitely stop it from stopping you.
Also, you may have not the best job situations; maybe your company doesn’t offer time for learning during working hours or Agile practices are not very common in your daily job. Don’t let this stop you if that’s what you really want: you can study and put them into practice on your own. You will improve in any case and maybe you’ll be able to speak about it in your company.
For some topics, exercises like Katas are enough, for others you may need to create a real, small project. Find a way, your way, without being blocked by anything you may fear, because there is always a solution: focus on the growth it can bring you personally and professionally.
Also remember to find your objective and focus on that: maybe you don’t have time during working hours allocated for training, you may not know which topics are best for you, you maybe have a personal life full of stuff… Similar thoughts stopped me for a long time and it was definitely a mistake. You can find your balance if you really care.
If you are not really much into improving yourself and your knowledge, let me tell you something: developers are knowledge workers, meaning that our work is to know the more we can about something, programming in our case. It means that doing your best improving that knowledge it’s actually a key responsibility of a developer and it defines its professionalism or at least part of it. Don’t you agree?
Those are my feelings about the developer job and my experience with the growth I’ve had from the point of view of autonomy and the ability to create a personal path and fight my weaknesses on the learning side.
Hope this can inspire someone that might feel lost and unsure about the right steps to take, like I felt a couple years ago.
