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!
Top comments (36)
I would like to turn it upside down:
Since you started your career in programming, you have a certain interest in the field. You typically work 8 hours a day 40 hours a week in this demanding field. You get paid to solve problems. And mostly as long as you solve problems you are getting paid for longer.
This makes you a good (sic!) programmer. And there is nothing wrong with it. You do not need to have a twitter account, a githubrepo or blog about what you do, to be good at what you are doing - though the hype wants you to believe otherwise.
If your employer wants you to improve, it is in his own interest to pay you (or to give you time) to do that. Of course he could fire you and hire others, but that works only for some time - it is a sign for bad corporate climate, which doesn't bind people to the company and which is detrimental in the long run; although, the company doesn't realize at first.
So, what to make out of Uncle Bob's advice? You could read it in two ways:
1) If you are dedicated to your job and love what you do, it will be natural to do more than others - even in your spare time: because it is fun to you. That's the way it works for me. I spent time beyond my workday on education, because I like to do so. And when I am doing nothing, I have no guilty conscience about it.
A side-effect is, that my knowledge about things may be broader than that of others. But, that doesn't degrade their knowledge or make me magically better.
2) You could read it as a general advice: If you want to get better at something, you should perhaps spent more time on it. If you want to be a competitive programmer, you should invest more time in training your skills. But that is nothing, one wouldn't have known without Uncle Bob.
Uncle Bob's advice is ill advice, because it is a recipe to feel bad about yourself.
You are not your job.
This is an important fact which Uncle Bob seems to forget sometimes. It's a good thing that software devs are not only trained to code, but also to think! So I hope that most of his readers remember that fact, even if Bob doesn't.
Love how you look at this, thanks for sharing your vision!
I learn on my own because I want to know things outside of what my job requires. Because they are more exciting. And maybe because I would like to change my job eventually and I need relevant skills for that. So I tend to invest more time in learning when I am especially bored at work.
Anything I need to learn for the job I do during work hours, it is just a part of whatever task that requires new skills and knowledge. I don't feel in any way obliged to do it on my own free time.
thats interesting, just curious if you have a system for learning ? and how do you decide on what to learn ?
I just follow whatever sparks my interest, this way I am faster and more efficient getting that knowledge into my head. I rarely follow courses from start to finish, getting only things I need at the moment and while I am still interested. Sometimes I think I should be more organised but it never works out, I just waste time dragging myself through.
I like watching videos as well as looking at many examples of similar thing in different context and from different sources. And apply it, better to something I am already working on, if I can. If I cannot think of practical applications or the thing seems too vague and complicated to grasp then I assume it is too far from my current bubble of knowledge and I need to get to it later.
For example, if you are just starting learning a musical instrument, playing a complicated melody with two hands is out of your reach. Maybe you need to try to get comfortable with one hand first and with simpler things, but keep getting back to the complicated stuff to check if this time you are close enough. Same with tech.
I agree, some courses are just too long and sometimes you just need the relevant parts atm.
yeah, its always best to start with simple then aim towards complicated parts! :)
I think Uncle Bob's idea comes from the (misguided) idea that the software industry is comprised of folks who live and breathe code, love solving complex problems, and want to be the best of the best. For a lot of people, this might be the case. Maybe it used to be like this in the early days of tech. The problem is - for many, perhaps even most developers, software development is a job. It's not their passion (maybe it used to be!), they don't want to study and prep after hours, they just want their paycheck. A paycheck to support themselves, their family, their lifestyle, whatever it may be.
It can breed a toxic work culture to believe that yourself and your coworkers should be studying and advancing their skills outside of work. This isn't required for other professions. Yes I read the bit on doctors and lawyers, but are software developers comparable? Is it not a bit presumptuous to compare our work to those who studied for a minimum of about 10 years in universities, go through licensing exams, etc when our work doesn't even require a university degree? There's no 6 month bootcamp to be a doctor or lawyer. They're legally required to keep up to date on their skills because the requirements to enter the job are so high to begin with.
The fact that a company values your output casts a hierarchy ordering individuals by the quality, quantity and character of their output. All else being equal, people who put in more time to learn will be more effective (and therefore valuable) than those who don't. It's not a "toxic" fact, it's just a fact.
Bob's advice is merely an estimate for what it takes to gain upward momentum in the hierarchy. It seems from your argument (correct me if I'm wrong) that you find Bob's ideas "misguided" because your analysis is rooted in the notion that the number of people actively trying to climb the hierarchy somehow diminishes its existence. The hierarchy exists whether you participate actively or not---because it's induced by the free market.
And sure, there's no 6-month bootcamp to become a doctor. But there are no doctors working on non-critical projects. If you were hiring a team to craft software for a life-critical medical device, you wouldn't hire someone out of a 6-month programming bootcamp either.
There's certainly evidence in the psychometric literature showing conscientiousness is a strong predictor of professional success. The explanation for that is precisely the one I give above. You can therefore argue that the number of hours in Bob's estimate of how much time should be spent learning is too high, but you can't argue that it's misguided.
Wow, this is a great article, I'm glad someone touches this topic since it's been a while very controversial. I personally believe that you should learn whenever you feel like, or whenever there is a need for, but not to put a number on it (4h a day or similar) that will definitely make learning obligation, not fun.
I think the freedom of it makes sense but how do you keep yourself accountable ?
Depends, sometimes I rely on people which carrier I respect, and keep up with their recommendations (what to read, which conference to attend, what's hot) or by listening to the community. Then I have an idea what should be nice to learn/understand + something which personally interests me and that's the recipe. Really not more than that. As I said I do not put any number on my tempo, I read/listen/watch material in tempo which is every week different, but it is most comfortable for me
I see, thats interesting. Thanks for sharing
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".
I believe that in any job, you need to constantly improve and I totally agree that you should Do so in your spare time. But learning/education also has to be Part of your Job - an employer who wants to have devs with up to date skills needs to invest in These skills. But: Improving my skills is something I owe to myself, not to my employer.
I think you hit the nail on the head by saying you owe it to yourself. This shows me that you value, maybe even prioritize your job / career / skills enough to make the investment. And that is great! Don't get me wrong, I'm not telling people not to learn. I'm trying to tell people to get to think about why they are learning, it should be because of an alignment in your own live priorities, not because that's just what you need to do when you are a software engineer.
One thing to be aware of for any recommendations from Robert Martin:
They are written for a very specific, highly simplified version of reality. A spherical cow for programming.
The more specific and fine-grained his recommendations, the less susceptible they are to change due to real world factors; guidance on code is more likely to remain applicable than guidance on Coders.
The result of this simplification is that when you try to apply behavior-based ideas to actual people, messy reality steps in.
When you accept his definition of how a Coder behaves, the only people who can meet that definition will be people who are the most like him.
Anyone who has a different reality and cannot (or will not) follow his rules of behavior is therefore either "not a real Coder" or is a less valuable Coder. It is a form of gatekeeping, and we need to recognize it as such.
Wow, just wow! I really like the way you look at it and how you describe it. Thanks for sharing!
It depends on your values. If it’s super important for you to be top of the pile, knowing it all and so on, go nuts. If, like me, its ok to just do good work and live a balanced life, avoiding burnout - then choose how you use your time - it’s totally fine (I’ve done some work I’m proud of).
Nicely put, this is a great summary of my intended message :)
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.
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!