"How can I learn it all and how long will it take?"
That question has easily become the most common to come through my inbox. A request that is so common and emphatic that I can feel their energy oozing through the screen on my end. There is nothing inherently wrong about this curiosity. I would be surprised if you hadn't asked the big questions somewhere along your development journey.
How long will it take me to learn X? How did you get a job at Y? Will it take me long to get a role as a senior Z?
Here we go: I don't know the answer.
Great opening statement, right?
There is a lot to it. It would be arrogant to even consider the thought that my experience and imagination could cover even minute percentiles of the developers out there and how they've gone about their career. If you've ever read Malcolm Gladwell's Outliers, then you'll know that there are many factors to success that range anywhere from personal talent and perseverance to the old adage of "Right time, right place."
The public surface of what you see does not spell the story of one's every waking hour. As obvious as that may sound, it is necessary that you understand the weight of that statement.
There is an unruly number of listicles that push unrealistic narratives, but today feels like the appropriate time to respond to those who asked the question with an authentic contribution that (hopefully) does not become another unhealthy statistic.
Beginning the most applicable of principles and resulting with the deepest of realities, here are my empirical 10 Time Management Tips for the Developer Who Wants It All Now.
Let's begin with an opening from our dearest friend, Wikipedia:
"In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people with low ability at a task overestimate their ability. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability. Without the self-awareness of metacognition, people cannot objectively evaluate their competence or incompetence."
In layperson terms, we often overestimate our credibility in an area early in the piece. In the field of programming, there are many points of entry, in many areas, in many different languages with many different applications. This is not to dissuade you from programming, but a friendly reminder about today's first tip:
Take your time to understand and remain humble.
Looking at the image to illustrate the Dunning-Kruger effect, it has a "double peak" of sorts. The first when we are overconfident, the latter when confidence grows with experience, tenure and an appreciation for the vastness of a particular area.
You may have seen fantastic guides such as the Web Developer Roadmap and felt the importance of ticking off the box, but I implore you to slow down and truly understand each section and the why.
This is not something that happens at the start of your journey, but at each new learning curve along the way.
There are two ways to take this understanding:
- To let the imposter overwhelm you (more on that later); or
- Let it empower you with the mutual understanding that there is always more to learn and we are all going through it.
I won't lie, I have a personal vendetta against programming titles. We have tiers at work and it takes cognitive and purposeful effort on my behalf to always remind myself that one course in a new area does not make me an expert and that I can learn from others with more experience in any of these areas regardless of tenure. If you have not learned something from someone who is only just starting out in programming, then you are not opening yourself up enough.
But hang on, is this even a time management tip? All that is a precursor to understand this:
- Rushing through things you do not truly understand is more costly to you than spending the correct amount for a true understanding up-front.
- Your ego will work against you and tell you prematurely that you understand something thoroughly.
Learning is not a race and the earnest reward is intrinsic, not extrinsic. Whenever you feel confident and ready to move on, first remind yourself of the Dunning-Kruger Effect and make an educated decision about your proficiency in the topic of choice.
Puzzles themselves can be a great metaphor for how each thing we learn adds to unravelling the mystery.
One thing at university that would always deter me about mathematics during the first year of study was that concepts and applications seemed arbitrary at the time. We would jump from section to section, and seeing the endgame was difficult at first.
This too is true of programming. Your first course may have been on Object-Oriented Programming, and understanding the "modelling of a vehicle interface" may have seemed like a bizarre first stop, but as you begin to learn more about the programming ecosystem, the more the puzzle begins to unravel itself and the applications become known. The more you begin to see the bigger picture, the more you can draw the connections, strengthen and even speed up your learning. Here are some trivial examples:
- Understanding protocols such as SSL/TLS and the differences between hashing and encoding will reveal the grander picture of authentication and authorization.
- Spending time learning route tables and subnets will give you a greater appreciation for the abstraction of networking and security found in a Kubernetes cluster.
- Learning how different trees result in different read/write database performance can lead to better decision-making on the right tooling and engines for a job.
- Understanding how caches work on a fundamental level in a computer can reveal how they operate for datastores and edge distribution fronts.
The more you reveal of the puzzle, the easier it becomes to solve.
As you learn, ask yourself this as you learn, "How does this fit into the greater picture of things?" If you can see and appreciate how what you are learning will fit into the broader scheme, you can plan accordingly and connect the dots to strengthen your learning.
Jumping blindly from buzzword to buzzword will leave you without understanding and a loss of time.
A true understanding of this will lead you to better time allocation and management of a "learning pathway".
The title leading to this tip is a bit strong, but hear me out: you will come across fascinating things to learn every day in this career. For those energetic and willing to learn, you will be easily tempted to move onto something exciting when it reveals itself.
Fight this temptation and stick to a plan.
Two of the biggest mistakes I made early in my career: learning Python and Ruby because I saw they were heavily used. At the time, I was working heavily with Objective-C and PHP (grim) and this meant that everything I had learned was never being applied. While I use Python and Ruby throughout my work week these days, it is years later and I certainly remembered nothing from the first time I eagerly spent tens of hours aimlessly crash-coursing myself on these languages.
The best way to save time is to not spend time.
There really is no better way to put it than that. This in itself leads directly to the next tip.
A "10-to-1-output-to-input" ratio sounds like something ridiculous you would hear from a self-help book that comes in tandem with the idea of never sleeping and always being on, but believe it or not, this one is grounded in realism.
The 10:1 ratio is not a hard and fast rule, but the gist of it is this: spend more of your time generating output than taking in the input.
Input has its place. We consume to get an understanding, but too much of doing so idly will not lead to learning. Case-and-point: if you want to learn authentication, you could watch a 5-hour course and genuinely understand as you watch what they are talking about, but without the actual application you are bound to lose it soon after. You don't learn how to shoot a basketball by watching tutorials all day. Spend time writing the code and you will re-enforce what you have learned.
Note: I know physical learning of something to muscle memory may not be the most applicable analogy, but that is the one I always tell myself personally when spending too much time in "input" mode.
So how did I come up with the "ten hours of work to one hour of input"? That was an arbitrary figure set by myself. Most days I work up to ten hours and I am not always taking in the input (depends on what I am working on), so those numbers for me generally make that up and you will be surprised how often you actually do stick to a 10:1 ratio. The idea is more that you should be spending more time applying what you learn than the time you spending learning it from consumption.
This point is a reiteration of the previous two: understand that we do not have perfect memory and not everything is stored.
The best use of your time is to learn what is applicable to you and what you do right now. Understand that while you stagnate in one area, you will begin to lose your knowledge in others.
This time management tip is about long-term investment. If you don't want to have wasted your time in things that you have learned before, find ways to keep those learnings strengthened.
How can you do this? One way is to find a career in an area that keeps these learnings alive. Alternatively, you can find ways to keep these concepts fresh in your mind through your hobbies or intermittent revisits.
As a personal example, I no longer work exclusively with iOS nor Kubernetes, but they were two areas I spent a significant amount of time investing in and learning for previous jobs that I would like to keep my finger on the pulse for. My way around this was to build a package management system at home so that I could quickly stand up projects for the house or hobbies that still keep me in touch with these technologies without having to dredge through to tedious groundwork to get these things up and running.
"Using it" doesn't mean you need to be revising algorithms daily or trying to keep up to date in every area - it means to keep in touch just enough to jog your memory and keep what you have alive. You cannot remember everything, but intermittent and purposeful workings in those technologies will keep your experience alive and well.
If there is no reason to revisit it every now and then, then you should be justified and letting that knowledge drift away. If something truly does show itself again years later, you can always have the confidence that you will pick it up again the second time much quicker.
One of the trickier areas for time management: how do you get something done in the time you have allocated? Have you ever spent time for an essay where you dilly-dallied and got nothing done? Maybe you always wanted to build a weekend project but kept putting it off?
Here is are two axioms of productivity: Action begets action and doing builds motivation.
The best way you can be effective with your time that you've allotted to learning or building a project is to do whatever it takes to start working.
If you have ever felt uninspired but know what you have to do, I guarantee that making headway on it will make things easier on you.
Does this mean you shouldn't spend time finding inspiration in other ways? Of course not, but you should also understand that there is a difference between your body screaming at you from overwork versus the natural lack of willingness to do something. We are all lazy at times and there is nothing wrong with that, but as soon as laziness and a willing to procrastinate edges on your time that you've set aside to achieve something, force your way through that 10-second mental conversation and start.
If you do start coding and ten minutes later you feel like closing the screen, then that might be your body telling you something else.
You cannot run a marathon every day and expect to be at your best each and every time. This is also true of learning and work. If you are trying to work and learn each and hour of the day then you are on a crash course to burning yourself out and you will never perform at your best in those times that you have put aside.
Effective time management is inclusive of understanding your body's needs and being able to assign time to switch off, recover and come back at your best.
To the developer that wants to learn it all now: learn the virtues of patience and perseverance. If you are in it for the long-haul, then you need to know that the best contribution to your effectiveness is to ensure you are at your best.
Being at your best also means taking time to understand how you work best. This is different for everyone.
Ever seen those articles that almost encourage you to sleep 6-hours a night? They can be outrageous, right? Well, this was a surprise for me: I sleep 4-hours a night.
Except, that is not all of it. I sleep 4-hours a night for about four weeks and then my body does this weird relapse where I need to then sleep about 9 to 10-hours a night for about four weeks after. Why does this happen? I genuinely have no idea. I seem to feel overly excited and just do not sleep. I don't feel more rested when I forcibly sleep more hours during my "light" cycle and trying to keep 7-8 hour sleeps during my "deep" cycle leaves me feeling unbelievably exhausted.
Instead of fighting it, I have learned to embrace it. I communicate openly with my managers at work about this, and they have been very receptive and work with me on it. So for four weeks, I go a little loopy and smash out work and (during this pandemic with little else to do in Melbourne) a number of courses, then I let my body recover and I work as best I can with everyone knowing that this is when I am most susceptible to slower turnarounds.
Obviously, this isn't everyone. But there are some others who operate like that. Reflect and learn on how you operate and try to set ways to work with it and keep everyone in the loop.
Knowing when I am coming into an "on" or "off" period helps me to effectively plan my hours and allows me to manage my downtime to ensure that I am doing the best I can during whichever period.
I touched briefly on this during the first section: how can you navigate with confidence when you face self-doubt?
This is a section that is easier said than done, so take what I have to say from experience with a grain of salt.
Change your paradigm and learn to embrace the realisation that you will always have more to learn.
I say this is easier said than done as I know there are many out there who are required to be "experts" in their area, particularly when working with clients. I'm not sure on the exact answer for this, but open-honesty and acceptance of yourself come to mind. If I've had clients or interviewers ask questions that I don't understand. I level with them and tell them how I would try to find the answer. If they don't accept it then you should find solace that it was never meant to be and that it is the better result for all involved (not just you).
If you operate with the mindset that the world is vast, there is always more to learn and curiosity becomes your driver, then with you will at times reach that rare nirvana of acceptance.
In earnest, you will always constantly be wavering with this: at different times we will be tired, emotional, egotistical and these will combat our ability to remain humble and acceptive. However, the aim is to set yourself up for success as often as possible to have these realisations go into autopilot when you feel self-doubt.
Without these pillars of support to help you go into autopilot, then I have some words of warning: you will always continue to put more and more time aside for programming and not the other things in your life that matter. Even the greatest learners with the best time management skills could not keep up with the ever-changing landscape of technology. You will chase your tail and lose sight of what matters.
To be great at time management means to also be great at time delegation, distribution and denial. Find ways to embrace the unknown and let it be a source of awe and inspiration, not one of degradation.
If there is one strikingly obvious thing that has come from this article, it is this: not everything can be achieved in the now. The journey into a field requires persistence, perseverance and a healthy long-term commitment.
This isn't to say you need X years before things can be achieved. In reality, it is the opposite. It is incredible how much you can learn in an area if you invest your time wisely. If you have ever seen the "show dev" posts, then you will see firsthand that we live in a time where you can make your ideas a reality, even if they can be rough around the edges. I truly enjoy the Indie hacker stories of those not driven by perfection but that managed to create solutions to real problems and get their work out there. If you've ever known someone to pick up and instrument and be incredibly proficient after a year, then you know that things can be achieved in short time-frames if you know your purpose and what you need to learn to achieve it.
To the developers starting out who want to know every area and technology under the sun, ask yourself the following questions:
- Why is that I want to learn all these things?
- What is it that I can prioritise?
- How can I set myself up for the long-term?
Ask yourself these questions and be very hard on yourself. It will help you begin to ask the right questions to help shape the time in a way that truly is efficient and manageable.
To the developers I know who have had the most success in life (and I am talking about balance and personal achievement here over career progression), they have learned how to become "perseverant" developers, not "now" developers.
Image credit: Sonja Langford