5 ms·

> But if a candidate is motivated to take a job because they get to use shiny new technology I'm not sure it's about shiny tech, but the opportunity to grow an

> But if a candidate is motivated to take a job because they get to use shiny new technology I'm not sure it's about shiny tech, but the opportunity to grow and learn, and use those skills to become more marketable. The best developers (in my experience) have a growth mindset, and that includes learning new technology and new techniques.

kerkeslager 6y ago
This is just incorrect. Unless you think you know some older technology completely, there's always plenty of room to grow and learn on any tech stack. Some of the technologies I use daily, such as vim and bash, have been around for decades, yet I still learn things about them on a regular basis. In fact, one thing I've learned from working on bleeding-edge tech stacks is that communities around bleeding-edge tech stacks can often be narrow-minded in a way that hinders learning. Many (but not all) members Go community, for example, seem intent on not learning anything from other languages: if you point out that coroutines predate Go by decades and there's a lot to learn about their use from other languages, or that Go actually has a fairly weak type system, you'll get a lot of defensive pushback from Go fanboys who know literally nothing about other languages that contain coroutines, and don't understand that there's a difference between static types and strong types. There are good programmers in bad ecosystems--the folks who are bringing in generics might yet make Go a decent language--but remember that there was immense infighting to get there: I've been keeping track of Go long enough to remember all the people ranting that Go didn't need generics because it had `go generate`--a glorified C macro system (since they couldn't be arsed to learn from the mistakes of even one of the most adjacent languages) that breaks the entire point of not including generics in the first place (to keep the compiler single-pass). If this is the sort of "growing and learning" you're talking about, I generally tend to avoid working with people who "grow and learn" in this way.
- wiremine 6y ago
  > If this is the sort of "growing and learning" you're talking about. No, it's not. The key phrase is "growth mindset" [1]. That does not mean throwing away knowledge or blindly accepting the shiny new objects. I think that's where we're disconnected? [1] https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/ https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...
chooseaname 6y ago
The best developers grow by solving progressively more difficult problems. And great developers? It's not about what tech they're using, it's about what tech they're creating.

kerkeslager 6y ago

This is just incorrect. Unless you think you know some older technology completely, there's always plenty of room to grow and learn on any tech stack. Some of the technologies I use daily, such as vim and bash, have been around for decades, yet I still learn things about them on a regular basis. In fact, one thing I've learned from working on bleeding-edge tech stacks is that communities around bleeding-edge tech stacks can often be narrow-minded in a way that hinders learning. Many (but not all) members Go community, for example, seem intent on not learning anything from other languages: if you point out that coroutines predate Go by decades and there's a lot to learn about their use from other languages, or that Go actually has a fairly weak type system, you'll get a lot of defensive pushback from Go fanboys who know literally nothing about other languages that contain coroutines, and don't understand that there's a difference between static types and strong types. There are good programmers in bad ecosystems--the folks who are bringing in generics might yet make Go a decent language--but remember that there was immense infighting to get there: I've been keeping track of Go long enough to remember all the people ranting that Go didn't need generics because it had `go generate`--a glorified C macro system (since they couldn't be arsed to learn from the mistakes of even one of the most adjacent languages) that breaks the entire point of not including generics in the first place (to keep the compiler single-pass). If this is the sort of "growing and learning" you're talking about, I generally tend to avoid working with people who "grow and learn" in this way.

wiremine 6y ago
> If this is the sort of "growing and learning" you're talking about. No, it's not. The key phrase is "growth mindset" [1]. That does not mean throwing away knowledge or blindly accepting the shiny new objects. I think that's where we're disconnected? [1] https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/ https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...

chooseaname 6y ago

The best developers grow by solving progressively more difficult problems. And great developers? It's not about what tech they're using, it's about what tech they're creating.