4 ms·

It depends on whether you're the one paying for someone's learning curve. You'll be much better off if you learn the fundamentals then use a real project to po

It depends on whether you're the one paying for someone's learning curve. You'll be much better off if you learn the fundamentals then use a real project to polish your skills than trying to learn from scratch with a deadline looming.

sanitycheck 4y ago
The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers. Most significant real projects will need at least a couple of prototypes/POC's at the beginning. Thus a brand new project is a great time to learn a new language, you can make your beginner mistakes in code which will never ship. This goes back to that "innovation tokens" thing though, a new language is one innovation and you don't want too many others at the same time.
- nicoburns 4y ago
  > The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers I'd even say days, not weeks if the language is similar to one(s) you already know.
Sakos 4y ago
Something has gone wrong if learning on a live project is putting deadlines at risk. I've learned the most working on live projects, but it was important that the things I worked on weren't crucial for meeting those deadlines. This has a lot to do with how tasks are broken down and how responsibilities and tasks are delegated and what support there is from the rest of the team to maintain an acceptable velocity. That ensures that you're not, say, getting stuck on something for a week longer than necessary. As for "learning the fundamentals", it's incredibly difficult to know what you don't know or understand and what you need to know/understand until you're trying to solve real problems. It's so inefficient and unmotivating. I knew the absolute basics of Spring Boot when I started working as a Java developer, but it wasn't until I started working a job with Spring Boot that the real learning started and I felt the motivation and drive to learn everything I could. Frankly, businesses need to adjust and learn to be okay with paying for learning curves, instead of expecting people to know and have experience with everything under the sun. There are long-term benefits that aren't easily quantifiable.
tonyarkles 4y ago
> It depends on whether you're the one paying for someone's learning curve. When I was consulting, I would occasionally make a time box deal with the client. One project sticks out to me: I thought their project was perfectly suited to Rails at the time, but the majority of my projects had been done in Django. “I’m going to try building this in Rails. When I hit a 40h timebox, I’m going to stop, look at progress so far with a critical eye, and assess whether we’re getting value from this or not. If I don’t think so, I’ll abandon the Rails project and start over for free with Django.” As it turned out, the whole thing was done in about 30h with Rails and we didn’t need to have the rest of that conversation.

sanitycheck 4y ago

The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers. Most significant real projects will need at least a couple of prototypes/POC's at the beginning. Thus a brand new project is a great time to learn a new language, you can make your beginner mistakes in code which will never ship. This goes back to that "innovation tokens" thing though, a new language is one innovation and you don't want too many others at the same time.

nicoburns 4y ago
> The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers I'd even say days, not weeks if the language is similar to one(s) you already know.

Sakos 4y ago

Something has gone wrong if learning on a live project is putting deadlines at risk. I've learned the most working on live projects, but it was important that the things I worked on weren't crucial for meeting those deadlines. This has a lot to do with how tasks are broken down and how responsibilities and tasks are delegated and what support there is from the rest of the team to maintain an acceptable velocity. That ensures that you're not, say, getting stuck on something for a week longer than necessary. As for "learning the fundamentals", it's incredibly difficult to know what you don't know or understand and what you need to know/understand until you're trying to solve real problems. It's so inefficient and unmotivating. I knew the absolute basics of Spring Boot when I started working as a Java developer, but it wasn't until I started working a job with Spring Boot that the real learning started and I felt the motivation and drive to learn everything I could. Frankly, businesses need to adjust and learn to be okay with paying for learning curves, instead of expecting people to know and have experience with everything under the sun. There are long-term benefits that aren't easily quantifiable.

tonyarkles 4y ago

> It depends on whether you're the one paying for someone's learning curve. When I was consulting, I would occasionally make a time box deal with the client. One project sticks out to me: I thought their project was perfectly suited to Rails at the time, but the majority of my projects had been done in Django. “I’m going to try building this in Rails. When I hit a 40h timebox, I’m going to stop, look at progress so far with a critical eye, and assess whether we’re getting value from this or not. If I don’t think so, I’ll abandon the Rails project and start over for free with Django.” As it turned out, the whole thing was done in about 30h with Rails and we didn’t need to have the rest of that conversation.