this post was submitted on 19 Mar 2024
37 points (97.4% liked)

Programming

17398 readers
242 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

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 are viewing a single comment's thread
view the rest of the comments
[–] jeremyparker@programming.dev 1 points 7 months ago (2 children)

Look Ma, this guy says it's ok that I'm a full stack dev. He says it's even good!

Also: counterpoint: if you teach your kids to code, you can outsource to them.

[–] yournameplease@programming.dev 3 points 7 months ago

Great advice, you two. Have a bunch of kids and teach them APL, Actionscript, and Autohotkey. On it!

:)

[–] abhibeckert@lemmy.world 2 points 7 months ago* (last edited 7 months ago)

this guy says it’s ok that I’m a full stack dev

I'm also a full stack dev - so maybe I'm biased. But I'll add that there's definitely a place for specialist work, but I don't agree, at all, with people who think specialist developers are better than full stack ones.

The way I see it full stack devs either:

  • are good enough to be the only type of developer your hire; or
  • sit in between specialists and management

Take OpenAI for example. They have a bunch of really smart people working on the algorithm - so much so they're not even engineers they're more like scientists, but they also have a full stack team who take that work and turn it into something users can actually interact with, and above the full stack team is the management team. Maybe OpenAI isn't structured that way, but that's how I'd structure it.

But most software isn't like ChatGPT. Most software isn't bleeding edge technology - you can usually take open source libraries (or license proprietary ones). Let the specialists figure out how to make TCP/IP handle complex issues like buffer bloat... all the full stack dev needs to know is response = fetch(url).