Software craftsmanship is a long journey to mastery. It's a lifestyle where developers choose to be responsible for their own careers and for improving their craft, constantly learning new tools and techniques. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development.Software craftsmanship is all about attitude. The attitude of raising the bar of professional software development starting with our own skills and professionalism.
The responsibility shift
Not long ago, I was speaking to a developer and he was complaining about his company, saying that they didn't have a good career plan, that he did not have any training, that he was not given the opportunity to learn new technologies and, of course, that he was not paid enough. Apparently, from his perspective, his employer was responsible for his career.
Imagine that we need a doctor. Would we pay a doctor to learn while he cut us open or give us a diagnosis? Would we pay an engineer to learn while he draws the plan for our new house? Would we go to a concert and pay the musician to learn how to play the guitar during the show? What about a chef in a restaurant?
So why is the employer's obligation to pay us training courses and pay us to learn new technologies and tools while we are working on a project? Should the employers be responsible for what we learn and what we don't learn.
Software development is not a 9 to 5 profession. To be a professional software developer, we need to take our own time and money to keep learning and improving. As professionals, we should be paid for what we know, our ability to learn fast and for the quality of the work we do. We own our careers and are responsible for them. Working for a customer/employer that helps us with our career in terms of training, books, conferences, seminars, etc, is great but should be considered a bonus.
... but how can we learn and keep ourselves up-to-date?
Different developers have different preferences but here is a list of ways I find useful.
Literature
Books, many books. Having your own library is essential. Books give you a good overview of a specific technology or subject quickly. No, it does not mean you will be proficient and next day you will be a specialist. What a book will give you is an understanding of what a technology or subject is about. It will be up to you then to decide if you want to practice what you've learned and become proficient. If you don't have the habit, try reading 3 to 4 technical books per year. Once you get the habit, try one per month. The most common excuse is that you don't have time. The cool thing about books is that you can read them during periods of "dead" time, like on the tube, bus, in your dentist's waiting room, on the bed before going to sleep, toilet, etc.
Blogs are now one of my favourite types of reading. They tend to fit more the software craftsmanship model since they are much more personal and in general, related to personal findings, opinions, successes and failures. Reading blogs from more experienced professionals and subject matter experts is a good, quick and free way for apprentices and journeymen to learn from multiple master craftsmen at the same time. But don't think that just experienced professionals should write blogs. Every software developer should write his or her own blogs, sharing their experiences and findings, helping to create a great community of professionals.
Technical websites are also good in order to keep yourself up-to-date with what's going in the market. New technologies, techniques, etc.
Practice, practice, practice
Pet project(s) is for me, by far, the best way to learn and study. A pet project is a real project but without the boring bits. There are no deadlines, does not need to make money, you control the requirements and most importantly, you use the technologies and methodologies you want, whenever you want, wherever you want. You are the boss. Pet projects give something for you to focus and help you to understand why and how you can use certain technologies. It gives you the experience you need to apply what you've learned into real projects. Pet projects are meant to be fun.
Contributing to open source projects can also be a great thing. There are thousands of them out there. Find a project that is related to what you want to learn or know more about and download the source code. Start running and reading the tests, if any. Inspect and debug the code. If you want to contribute, start small. Add some documentation and write some tests. Then, check the list of features to be implemented and pick a simple one and give it a go. You can also propose and implement a new and small one to start with.
Pair-programming can be a great experience. Many developers are afraid to try or think they will feel uncomfortable. That's what I thought as well before I tried. Today I really enjoy it. Pair-programming gives you an opportunity to discuss your ideas, to learn new tricks and techniques from your pair and the resulting code is much better. Pairing with someone from your team is good but pairing with someone that you barely know can be a very interesting experience.
If learning a new language or new technique like TDD / BDD or trying different approaches to OOP or functional programming, try a code kata. Code kata is a small exercise that in general can be solved in a few minutes or in a few hours. Code katas were created to help developers to focus in a problem while improving their skills. You can find a good source of code katas at codingkata.org and codekata.pragprog.com
Community and Events
Be part of your local community. Software craftsmanship is all about a community of professionals, learning and sharing with each other and elevating the level of professionalism and maturity of our industry. Join your nearest user groups and participate in their events. User groups are the best way for making contacts, sharing ideas and learning things. Many user groups promote free talks, coding activities and social events. A great aspect of being part of a community if the feeling that you are not alone. There are many people out there having the same problems you've got and many others that will happily share their solution to it.
Raising the bar
The main changes proposed by the software craftsmanship movement are related to the developers attitude. In summary, it's about being proud about your work, the code you produce and the software you create. It's about constantly trying to improve your skills and learn new ones.
An aspiring software craftsman is intolerant of bad code will constantly apply the Boy Scout Rule.
If you find that the good code you wrote one year ago is still good enough today, it means you didn't learn anything during this period and this is unacceptable.
Productive partnerships
The attitude of a software craftsman goes beyond good code. The relationship between a software craftsman and his or her customer (or employer) is of a productive partnership and not employer / employee. As a productive partnership, it's our role to constantly question the requirements and propose improvements and new features. It's our job to warn our customers about the problems we see. Due to the knowledge of the code and technology, developers are well positioned to help their customers improve their business.
However, sometimes some customers or employers don't want or don't see the advantages of this partnership and will treat developers as production line workers that should just do what they are told. Coding monkeys. In cases like that, any aspiring software craftsman should move on and find another job. Staying in a place where your skills are not appreciated is a career suicide.
Raising the bar of our industry is on our own interest. The better we become in writing code and delivering valuable software, the better our lives will be, professionally and financially.
PS: If you are in London or nearby, join the London Software Craftsmanship Community.
7 comments:
"Would we pay a doctor to learn while he cut us open or give us a diagnosis?"
This is exactly how doctors learn. Let's take a look at surgeons. The theory is taught in school, but once they're qualified they will be sent into operating theatres to perform real operations that they have not previously experienced. There is a senior surgeon present to demonstrate to them, give tips or to take over for very delicate or complex parts of a procedure. It's a bit like pair programming.
When they want to specialise, they are sent on courses, paid for by their employer, to learn the theory of new areas. Then they can be sent in to test their new knowledge on more unsuspecting members of the public.
The very best, or at least keenest, surgeons will often study books to learn about new areas, or stay after work to watch (or help) with operations they are not familiar with.
Overall, a good analogy. I think a software developers could learn a lot from doctors.
Great post, as always, Sandro!
I'm not sure I agree that employers *shouldn't* be concerned about training. I think its in an employers interest to help their staff improve - both in terms of retention and helping people develop.
You're absolutely spot on that it isn't *only* the employers responsibility, though. I think its up to all of us to try to improve our craft. This means developers need to take a more proactive approach to learning and not just "waah waah my employer never sends me on training courses".
Some are cheap, why not pay for them yourself? And as you say, there are many excellent ways to learn that don't need any money at all - just time.
I do wonder though how much of "raising the bar" is also down to encouraging companies to do more? If companies were more proactive in setting up tech libraries, encouraging devs to blog, working on open source projects in their spare time, attending dojos and other community events - that would surely also raise the standard of craftsmanship?
I agree partially with your comments. If we look at software as a craft, it's our (the developers) duty to define standards for professionalism and to raise the bar. This doesn't mean that employers shouldn't be involved; they should take part in the effort, but until we convince them we should be doing whatever we can.
Also, you failed to mention code retreats, which are in my view the best type of learning event for a community.
Shameless plug: I've written an article similar to yours and I think it's a good companion to yours http://www.alexbolboaca.ro/wordpress/my-take-on/software-craftsmanship
@Gurty
"There is a senior surgeon present to demonstrate to them, give tips or to take over for very delicate or complex parts of a procedure."
That's exactly the model of the software craftsmanship where apprentices and journeymen learn from a master. This is perfect. But at the end, you are "paying" for a good service that is enforced by the supervision of the senior surgeon.
I believe that my point was more like just having apprentices performing the surgery without the supervision of a senior surgeon.
@ActivelyLazy
I completely agree with you. I was coming from the developers point of view when I mentioned that it's not the employer's responsibility to provide training or some sort of environment where employees can improve their skills.
As you said, it's on the employers' best interest to keep their employees sharp and motivated. If employers do that, it would be a win-win situation.
Encouraging companies to do more is definitely part of our job. It's easier for a technology company to understand the advantages of "doing more", as you suggested. However, non-technology companies, may struggle to understand the real benefits of it.
@Alexandru
Absolutely. I didn't mean that employers and customers shouldn't be involved in the process. In fact, they have to since they will be the ones to benefit the most. My point was that sometimes we try our best to help, proposing improvements and delivering the best software we can. Unfortunately some employers are just not technologically mature enough to appreciate that. It's our job to help and do more, but sometimes we can't help those who don't want to be helped. But as you said, we should do whatever we can.
Yes. I haven't mentioned code retreats and dojos specifically. I briefly said that user groups in general promote some "code activities". I love the idea of code retreats and dojos. The idea behind the London Software Craftsmanship Community (that we just founded) is to promote this kind of events in the future. We are still trying to organise ourselves and very soon we will have our first meeting.
I came across your blog post some weeks ago and found it very good. That's why I started following you on Twitter. I should have left a comment as well. :-)
I like what you are doing in Romania and also watched Corey Haines presentation in full. Thanks for sharing that. It was really good.
@Sandro Mancuso Wow, thank you :). I'm glad that you found something interesting in what we do.
Maybe we can help each other. I started following you on twitter as well, so let's keep in touch, shall we?
Post a Comment