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?
2 hours in administrative work, 2 hours coding, 2-4 hours learning/experimenting. Has been working nicely for me so far.
My thoughts are spending too much time on the computer is bad for you, and once you find a good long term job, you dont need to learn so much. Youre 2 years into your career, hopefully you’ll find a good fit.
Knowing how to Hello World in ADA is not very helpful, try to find in demand things to learn. There really isnt that much.
Well, that, and programming itself is starting to slow down.
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).
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.
In my opinion the best developers are “generalists” who know a little bit about everything. For example I have never written a single line of code in the Rust programming language… but I know at a high level all of the major pros and cons of the language. And if I ever face a problem where I need some of those pros/don’t care about the cons then I will learn Rust and start using it for the first time.
There’s not much benefit to diving deep into specialised knowledge on any particular technology because chances are you will live your entire life without ever actually needing that knowledge and if anything, it might encourage you to force a square peg into a round hole - for example “I know how to do this with X, so I’m going to use X even though Y would be a better choice”.
Wikipedia has a list of “notable” programming languages, with 49 languages just under “A” alone and I’ve personally learned and used three of the “A” languages. I dislike all three, and I seriously hope I never use any of them ever again… but at the same time they were the best choice for the task I was trying to achieve and I would still use those languages if I was faced with the same situation again.
That’s nowhere near a complete list - which would probably have a few thousand under “A” alone. I know one more “A” language which didn’t make Wikipedia’s cut.
The reality is you don’t know what technology you need to learn until you actually need it. Even if you know something that could be used to solve a problem, you should not automatically choose that path. Always consider if some other tech would be a better choice.
Since you’re just starting out, I do recommend branching outside your comfort zone and experimenting with things you’ve never done before. But don’t waste time going super deep - just cover the basics and then move on. If there’s a company you really want to work for, and they’re seeking skills you don’t have… then maybe get those skills. But it’s risky - the company might not hire you. Personally I would take a different approach, try to get a different job at the company first then after you’ve got that, start studying and ask your manager if they can help you transfer over to the job you previously weren’t qualified for, but are qualified now. In a well run company they will support you in that.
As for learning outside of your 9-5… you should spend your spare time doing whatever you want. If you really want to spend your evenings and weekends writing code then go ahead and do that… but honestly, I think it’s more healthy long term to spend that time away from a desk and away from computers. I think it would be more productive, long term, to spend that time learning how to cook awesome food or do woodworking or play social football or play music… or of course the big one, find a partner, have kids, spend as much time with them as you can. As much as I love writing code, I love my kid more. A thousand times more.
Programming is a job. It’s a fun job, but it’s still a job. Don’t let it be your entire life.