I have about 2 YoE, and I’m sure this changes with more experience.
I often hear this idea online that programmers should follow “just-in-time” learning, meaning you should prefer to learn things you don’t know while on the job. ( The way some people talk about it, though, it sounds like you shouldn’t dare spend a single minute learning anything new outside of your 9-5. )
This seems generally reasonable advice, especially for simpler things that take a few hours like learning a specific language feature, library, or similar. But when I lean too much on this JIT learning, it feels possibly detrimental.
Many times I do something big and new to me, say, deciding how to approach auth, microservice architecture design, automated testing, containerization, etc., I end up making a big decision after a few hours or days of cursory reading on documentation and blogs, only to come to regret it some months later. At that point, maybe I’ll slow down, find a book on the subject, read it, and think, “Oh, darn, I wish I knew that N months ago.” It certainly feels like spending more time learning upfront could have avoided mistakes due to lack of knowledge. Though there’s no way to go back in time and know for sure.
I’m not asking about any area listed in particular. I feel like, for all of those, I’ve learned more in the time since, and would probably avoid some of my prior mistakes if I did it again. The question is more: How much do you subscribe to this idea of just-in-time learning? And if you do, how do you know when you’ve learned enough to be confident, or when you need to slow down and learn in more depth?
You must log in or register to comment.
I think what they mean is don’t spend your personal time learning stuff for work.
If you need tech for work learn it at work.
If you aren’t learning it we’ll enough at work spend more work time learning it.
If they won’t give you that that’s their problem, not yours.
I think the best advice is don’t make huge decisions based on a small amount of research tbh.
Your personal programming shouldn’t be driven by work requirements.
You should spend your time at work doing work and your time at home doing anything else. Some people really enjoying programming and building in their off time, some people don’t. Follow your interests :)
I feel like I have been doing this all my life. I think it’s more to do with the depth of understanding too. But the environment has to support it, if there is an expectation that everyone is an expert from day one, and there is no room for self improvement then it can’t be done.
As stated there are down falls with the approach such as lack of exposure to new ideas. You still need to look just not study. But to me it’s also a work/life balance policy. But don’t practice it in extreme as it can hold you back. Good work places should allow for some learning time and I’m hoping that gets normalized.
If you want to level up your game, find a new job, or grow into a new role, by all means take a course or training on your own time. All of the concerns that you listed are probably worth spending dedicated time to upskill on.
If you stay in this field for much longer, you’re going to run into a lot of cases where the thing you’ve been doing is replaced with the New Thing. The New Thing will have a couple new ideas, but will also fundamentally handle the same concerns as your Old Thing, often in similar ways. Don’t spend your free time chasing the New Thing without getting something out of it - getting paid, making a project that you wanted to make anyways, contributing to New Thing open source projects.
If you sink work into the New Thing without anyone willing to pay for it, that’s fine, but it means that you might never get someone to pay for it. Most companies are more than willing to hire experienced Old Thing devs on New Thing jobs, and will give you some time to skill up.
2 hours in administrative work, 2 hours coding, 2-4 hours learning/experimenting. Has been working nicely for me so far.
Don’t know if my experience can be related by other people here. I’m a mathematician and I work in insurance writing python/SQL to transform data into knowledge. Everything python/SQL related I’m learning it on paid hours, like testing libraries or others. While outside my job I’m working on an actuarial sciences MBA, where I’m learning theoretical knowledge that couldn’t be learned “on the job”. When something I learn on the MBA can be used on the job, I rush to learn how to apply it on python (while being paid for it). For example, a couple of weeks ago we learned how to find the probability distribution parameters of a sample using maximum likelihood estimation, and while on the clock I learned how to that using scipy on the claims database.
I’m already thinking on doing a computer science masters after finishing this MBA, because I’m really enjoying the opportunity of studying theoretical stuff on my time while being paid to practice it and learn how to apply it in real life applications.
Your description of JIT-learning sounded more like learn-only-on-the-job than JIT.
When you say “should have learned more upfront” I don’t see how that would necessarily have to be outside or within the job. Where you learn it is open and arbitrary. For me, it’s a question of what’s reasonably necessary or efficient, does it make sense to explore more or prototype at work? Outside of that, I would have to have a personal interest in it to explore it in my private time just in time.
Usually, I learn upfront unspecific to concrete work. And that experience and knowledge come in handy at work.
When I’m on the job I work on and learn what is necessary to the degree it makes sense. I prefer to fully understand, but sometimes that’s not possible or reasonably, acceptably efficient. Then you can weigh risk vs cost and prospect. There’s no way around weighing that each time and individually. Development, in/as general, is too varied to have one arbitrary supposed weighing to follow.
I read books at work when I need to, and in some cases that can take several days. As long as it is relevant to what I am being paid to do. Make sure to clearly communicate. Learning is part of this job.
When you’re faced with a tough architectural decision, identify which option is easiest to change from. Part of the job is to make decisions with limited knowledge.
The benefit of solutions that are easy to change is that if it turns out you made the wrong decision, you probably still have the chance to do some course correction.
Programs are also dynamic. No decision should be final. Sooner or later you probably need to course correct the ship anyway when requirements change, and you will be grateful you chose the option that’s easy to change from.
This principle is called ETC (Easy to Change) in the book Pragmatic Programmer, which is also the book that coined DRY (Don’t Repeat Yourself).