Every sprint our team dedicates some time to learning together, today we watched a video by the beloved 'Uncle Bob'. This time we watched an episode on productivity. It was a good episode, but in between him doing weird stuff with his dog and the many strange characters he portraits there was a piece that got all of our attention. He talked about learning, and at the moment I heard him say out loud "Next to your job you should spend 15-20 hours a week learning, you owe this to your employer." I noticed everybody looking like they just saw a ghost. How are you supposed to do that?!?
Uncle Bob's Learning Vision
It's been a while since I've read 'The Clean Coder', to which this video series belongs. A series dedicated to being a professional software engineer. While being fairly short, his stances on learning are pretty clear:
- Spend 15-20 hours a week on your career
- Learn at least one new language per year
- You must at least know the Design Patterns, Design Principles, Methods, Disciplines and Artifacts by heart.
- You should keep up with trends and movements, while also knowing and learning the past
And he has some pretty good reasons for thinking like this, I think a quote from his book sums it up pretty good.
The frenetic rate of change in our industry means that software developers must continue to learn copious quantities just to keep up. Woe to the architects who stop coding—they will rapidly find themselves irrelevant. Woe to the programmers who stop learning new languages—they will watch as the industry passes them by. Woe to the developers who fail to learn new disciplines and techniques—their peers will excel as they decline.
Would you visit a doctor who did not keep current with medical journals? Would you hire a tax lawyer who did not keep current with the tax laws and precedents? Why should employers hire developers who don’t keep current?
And his opinion on being professional is also pretty clear.
Perhaps you don’t want to make that kind of commitment. That’s fine, but you should not then think of yourself as a professional. Professionals spend time caring for their profession.
His comparison to lawyers and doctors
For a while I've been saying, our industry is not like others, it's insane to think other jobs require this much learning. Then I saw his example, the doctor. Hmm, I indeed expect my doctor to keep up with trends. It would be nice for him to be able to diagnose me using new techniques researched in the last few years. But in my mind I kept doubting about the amount of time they would need to invest in this learning. So I decided to ask doctor Google. While not being as entertaining as doctor House, it still got me some good answers. Some quick research told me that depending on which state you live in you need to earn between 20-60 CME credits per year to keep your license, thus staying a professional. There are various items that give you these credits, attending conferences, certain meetings, reading journals, etc. And one credit takes one hour of time. That means an average doctor needs to spend the same amount of time on learning per year, as what Bob expect a professional developer to spend in 1-3 weeks. Now the comparison starts to fade for me. Some doctors may be really dedicated, but even increasing this 10 times, just matches half the time of a professional software engineer at best.
What about his tax lawyer then? The same story as doctors, there is a required number of credits per state, which is somewhere between 20-40 credits per year. And the same as with doctors, one credit takes one hour of work. Some a professional tax lawyer, or accountant, needs to spend the same amount of learning per year, as what Bob expects a professional developer to spend in 1-2 weeks.
These are two jobs, which are known to be high maintenance, high responsibility, but also highly rewarding. They require a lot of working hours and a lot of learning hours to keep your license. Although they seem nothing compared to the expectations for a professional software engineer we just read.
Being influenced
While I'm sure Uncle Bob's vision was not meant to be as black and white as I'm using it in this article, there are some dangers to such statements. His work is very well known in the industry, a lot of us will consider him a guru of some form. Thus when he says stuff like that, a lot of people will believe him. It doesn't matter if you are an experience developer, or somebody that is still learning to code. A lot of us have some form of insecurity which is completely natural for a human and widely talked about in the many, many, you would almost say too many, articles about 'Imposter Syndrome'. And those of us that already are somewhat insecure could easily read something like this and start thinking that this is just something every software engineer should do.
Be aware
Why is it so dangerous then? We'll exactly like it states in his book that it isn't. I know, confusing right? In his book he states:
Perhaps you think this is a recipe for burnout. On the contrary, it is a recipe to avoid burnout. Presumably you became a software developer because you are passionate about software and your desire to be a professional is motivated by that passion. During that 20 hours you should be doing those things that reinforce that passion. Those 20 hours should be fun!
So what, you are saying that this is a recipe for burn out? Yes it is! But it is not the number of hours you are putting in, it is why you are putting them in. If your passion for code just flows through your veins and you live and breath to write it, this will probably not be that big of an issue for you. Although you should still be aware, because even doing that much of a thing you love can burn you out, or make you hate it. It gets a lot more dangerous when you are doing this because you think this is expected of you. Although he says it should be fun, it won't be all the time, it won't be a lot of the time, learning can't be fun all the time. And even when it is fun, don't you think that will reflect on your job? If it's really that fun to do and you've just written 4 hours of code after working the full day, you will start you next day after having basically worked for 12 hours. Which accumulates to 60 hours on Friday. There is no way you can still function as good as when you would work for 40 hours. Even when the hours don't wear you down, when the half a day you work at home is that much fun, and you have to spend the next 8 hours on something that isn't that much fun, day in and day out, it will eventually burn you out at your job.
What do actual developers think?
Some highly regarded people advice you to spend a lot of time learning. Besides Uncle Bob I was only able to find the same opinion by John Sonmez, who are both well known for investing time in their career. While others like Andrew Hunt and David Thomas do describe what to do, but not how much time to invest. The thing that I noticed the most is that these people fortunately seem to be the exception, most writers seem to steer clear of advising concrete hours to put in. When you start searching for the opinion of other software engineers, that's exactly what you will find. Opinions, and a lot of them, and a lot of them are different. Although most of them aren't as extreme as the ones above. A lot of people think you do not need to do any coding outside of your job, this thread gives a great vision on this opinion. While others think you do need to spend some time on this outside your job, as discussed in this thread. There are a lot of threads on this subject, showing the insecurity we have about this subject, but I was unable to find people who had agreed on the 15-20 hours a week. Most opinions are somewhere between just coding at work, learning should happen at the job, to a few hours a week at home are necessary.
What should I do?
Great question, I'm glad you asked it! To put it short; Whatever you want! You should try and figure out what you find important in your life, what you want to reach in life and divide you personal time to do those things and reach those goals. For a lot of us, most of us, being a lot of other things will be more important than coding. Think of being a partner, a parent, a friend, having fun, traveling, volunteering, or any other thing you may find important. You probably don't want the last vision you're having on your death bed being that of a factory pattern being injected in your decoupled class, right? Coding, or having a great career may be on the list somewhere, it may not be. Do you want to do everything you can to have the best career as a software engineer, and having that be the most important thing to you, than invest that time! As long as your spare time matches your goals in life, there is no going wrong!
Latest comments (36)
15 hours a week. So that's 2 hours a day roughly including weekends. Will take me some serious self-discipline. But if Uncle Bob says I must, then I will.
Hi John, thanks for your article. I started to write an answer, but it became way too long... Here are my two cents on this topic.
In short, I think we should all keep learning and I don't see anything bad in learning at working hours and indirectly charge for that. 15-20 hours might be a bit too much either you do in at working hours or at home, but I think there should be a golden mean.
You owe it to yourself to learn ( I read it somewhere in this thread). This is the biggest take away from this.
I agree 4 hrs week is a byte to much.
But I disagree with you on some level.
Because no one really controls what we do as Doctors or Lawyers. And I believe our world turns faster than other disciplines. So we have to put in more hours. And if we don't keep updating ourselves, we contribute to the death of the discipline. It obviously won't die, but it will however make many miserable.
It's not so much the learning here that bothers me but the time. We all learn at different rates, some things are easier than others, so that time to learn each day can differentiate depending on what you are doing and what you are learning. When trying to grasp something, it may take longer than some concept that gives you an AHa! moment and things move along.
There is a ALOT to learn in software, and depending on what sort of environment you are in (Front or Back, Application or Web, Java or C#, AWS or whatever) there is a huge amount of choice to make. You can learn for the sake of learning, or learn to keep yourself up to date, or learn more about what you are doing. It's all up to us, and we all have different paths to keep and follow.
Notwithstanding the time commitment it IS a lot of time, but that is all relative to what you are doing and what you want to do. I'm more committed to learning and am always trying to learn more about something, and for me that's fine and at times I might want to learning something completely unrelated to my work just to keep myself amused, learning, and have some fun.
Great read John!! I agree on it 🙃 And BTW, a huge fan of Uncle Bob
Many of the things Uncle Bob says make sense, but the endearing nickname and accumulated fame make it dangerously easy to fall into the pits of authority bias.
Never assume something to be true just because "Uncle Bob" (or any other author) said it. Come to me with independent reasons.
I especially have an issue with his "learn in your own time" stance — he quotes that doctors do not get paid by patients to practice sutures and football fans do not pay to see players run through tires. Both are not really true: in both cases the employers will generally pay for training, and training time is calculated into the final price of the service.
Of course that doesn't mean that you should work on your random hobby projects during office time, but in my opinion when you ask about learning opportunities during a job interview, it should never be answered with "If you read Uncle Bob's books, you should know to do that in your own time".
Irrespective of Bob's assertions that "you owe it to your employer", we do owe it to our co-workers and colleagues to not create implementations that are harder to work with than necessary.
The value of learning (and mastering) patterns, principles, methods, languages, etc, is so that we start to see the mistakes that we habitually make that we often don't realize are mistakes at all. We do it so that our decisions of what is good or bad - especially in regards to the tools we choose - are not influenced by mere dev community social identity, and are instead rooted in the objective science that underpins software design, and thus implementation and testing.
It's about not being made a sucker by fads and fashions, and so that these indulgences don't leave behind work that we were once socially-enthusiastic about, but now know is objectively undesirable.
It's about respect for our co-workers. It's about not making their work harder. And when we do that, we can even free up more time to allow them to further their studies and practice in pursuit of their life dreams. It's about not increasing someone else's suffering in order to optimize for our own expediencies and conveniences.
Nice article! One part of my PhD research was to capture what constitutes software development expertise and which factors foster or hinder its formation (see this blog post). I asked my participants what employers could do to facilitate expertise development, but I didn't look into how much learning should happen at work, and how much in the spare time. It would definitely be an interesting direction for future work to investigate how much spare time developers sacrifice to improve their skills.
Thanks! I've put your article on my reading list, I'm really interested in your findings.
Thank you for researching the actual hours practitioners in the two mentioned fields need to put into learning to stay in their field. It really helps putting Bob's numbers into perspective.
While I do think that Bob's numbers are severely flawed, and I think that about quite some of his statements, I can see where he's coming from. He sees software professionals as some "hardcore coders" who love to code outside work, and to whom coding is not just a hobby but the hobby. And since his perspective is far from my own, I can only disagree with him.
A lot of my university colleagues do entirely different things from coding in their free time. They go climbing, they they perfect their cooking, or they read through several (thick!) books a week. I myself spend a lot of time making and analysing music, as well as with cooking. Are we bad software professionals because of that? Uncle Bob would certainly say "yes" and, again, I would disagree. Doing different things in your life can only benefit your coding skills, since they provide you with different ways to tackle problems. And - at least to me - coding professionally is nothing else than solving other people's problems.
So, in a way, you could say that we do spend those 20 hours per week on learning work-related things. It's just not that obvious how and when our work will benefit from them.
Cooking together, for example, is nothing more than applying parallelization and caching algorithms to biochemistry problems. In fact, we often talk about interesting technical problems we encountered at work/uni projects, so we learn in several ways - all while having fun (and an awesome meal). Playing Jazz makes you "think on your feet" - you don't have a lot of time to think about your chord progression when you're playing. And if a few measures sound shitty, you still carry on, hopefully doing a better job next time. Yes, there are "idiomatic" solutions to many situations (like II-V-I progressions and established Blues solos), but the really interesting stuff happens when those are not enough or are ignored for really good reasons. Sounds familiar? ;)
As for the part of "owing" someone something: I owe my employer what my contract (and the law) says I owe them. Nothing more, nothing less. That doesn't mean I don't put 100% effort into it. That only means that I have a somewhat healthy relationship towards working, or at least I hope so.
I love the view you have on this, very interesting how your connect other free time activities to increasing yourself general skill level and reflecting that on your skills as software engineer. Thanks for sharing!
And if it's making you happy, keep doing it! Glad things worked out for you!