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?
For some non-critical stuff you can experiment til you find something that appears to work, deploy it, and fix any issues that might appear. Too much of today’s Internet is done that way, but it really is ok sometimes
For critical work, you can easily apply the same approach but replace the “deploy it” stage with “do extensive internal testing”. It takes a longer and is more expensive, but it does work. For example the first ever hydrogen powered aircraft flew in 1957, was an airplane with three engines and only one of those three ran on Hydrgoen. Almost 70 years of engineering later and that’s still the approach being used. Airbus claims they will have commercial hydrogen powered flights around 2035 and plan to flight test the final production engine next year on an A380 Aircraft.
The A380 has four engines and each is powerful enough to fly safely with only one engine running. In fact, it should be able to land with four engine failures - with a “Ram Air Turbine” providing electricity and hydraulic pressure to critical systems.
The best approach to critical systems is not to build a perfectly reliable system, but rather to have redundancy so that failures will not result in a “please explain” before congress.
It’s a bit more complicated when security is involved. I deleted that post because it didn’t seem responsive enough to OP’s question but basically there is a big difference between stuff going wrong randomly (Murphy’s law) and smart determined adversaries trying to mess with you on purpose. Testing helps more with the former.
Sure — security is one area where you do need to be a specialist.
I’d say it’s the exception that proves the rule though. Don’t write your own encryption algorithms, don’t invent new auth flows, do hire third parties to audit and test your security systems, etc etc. If you want to specialise in something like security, then yeah that’s something you should study. But at the same time - every programmer should have general knowledge in that area. Enough to know when it’s OK to write your own security code and when you need to be outsourcing it.
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.
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 :)
2 hours in administrative work, 2 hours coding, 2-4 hours learning/experimenting. Has been working nicely for me so far.
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.
_MSN_001_-_F-WXWB_(10223079236).jpg){kind=link}