Ask HN: Do you feel comfortable learning new technology at work?
Or do you feel like the company can’t afford for you to be wasting time playing with stuff instead of building features?
3 comments
Not only do I feel comfortable learning new stuff at work, I actively look for positions where this will happen. It's a perk I greatly value.
I've pretty much built my career on stuff I learned at work.
The "trick" I guess, is to carefully evaluate and attempt to selectively invest paid worktime into "new technology" that will have a reasonable benefit in at least the medium term to the company. You don't _always_ get that right - both ways. Sometimes you pick a thing and spend a bunch of time learning and prototyping using it, and it turns out to not actually be commercially viable right now. Make sure you don't "hang on" too long, and make sure you document why it looked like a good idea at first, and then why it turned out not to be a good idea in practice. A track record of getting it right often enough, and for sometimes getting it wrong but with well documented learnings about what looked attractive at first, and why it didn't turn out that way under scrutiny - that will build you a reputation which allows you to chase more of them... I suspect there's always a risk/reward tradeoff going on too, I bet there's a lot of things I've encountered or been recommended where the initial analysis didn't look beneficial enough to be prepared to burn company time and "personal reputation" on, which would have turned out super well had someone spent enough time testing it out.
Mostly I think, better architecture and newer tech are much more likely to be beneficial to a company long term than short sighted feature-chasing. You need to be in a company/project where that makes sense though. If you're a start-up scrabbling for product/market fit, there's zero benefit to prototyping, say, a Flutter reimplementation of your existing React app, or rebuilding your Rails backend in Haskell. You almost certainly need to be building/testing/demoing/selling new features to see what actual customers want/need/use when they've got it in their hands (and this probably includes turning off or throwing away features they never use).
Quite where the discontinuity is where you switch from "Sure, run up the technical debt on this hacked together prototype we've convinced our initial customers to buy, and our investors to invest in!", to "OK, it's time to get serious, there's no way we are gonna scale this evolved pile of crap to FAANG scale. Time to stop code-monkeying more features in, and to start behaving like actual 'engineers' who've designed the entire system properly..." - is super hard to do at exactly the right time. That's something I don't think _anybody_ gets right more than once or twice in a career (and even that only if they're lucky).
The "trick" I guess, is to carefully evaluate and attempt to selectively invest paid worktime into "new technology" that will have a reasonable benefit in at least the medium term to the company. You don't _always_ get that right - both ways. Sometimes you pick a thing and spend a bunch of time learning and prototyping using it, and it turns out to not actually be commercially viable right now. Make sure you don't "hang on" too long, and make sure you document why it looked like a good idea at first, and then why it turned out not to be a good idea in practice. A track record of getting it right often enough, and for sometimes getting it wrong but with well documented learnings about what looked attractive at first, and why it didn't turn out that way under scrutiny - that will build you a reputation which allows you to chase more of them... I suspect there's always a risk/reward tradeoff going on too, I bet there's a lot of things I've encountered or been recommended where the initial analysis didn't look beneficial enough to be prepared to burn company time and "personal reputation" on, which would have turned out super well had someone spent enough time testing it out.
Mostly I think, better architecture and newer tech are much more likely to be beneficial to a company long term than short sighted feature-chasing. You need to be in a company/project where that makes sense though. If you're a start-up scrabbling for product/market fit, there's zero benefit to prototyping, say, a Flutter reimplementation of your existing React app, or rebuilding your Rails backend in Haskell. You almost certainly need to be building/testing/demoing/selling new features to see what actual customers want/need/use when they've got it in their hands (and this probably includes turning off or throwing away features they never use).
Quite where the discontinuity is where you switch from "Sure, run up the technical debt on this hacked together prototype we've convinced our initial customers to buy, and our investors to invest in!", to "OK, it's time to get serious, there's no way we are gonna scale this evolved pile of crap to FAANG scale. Time to stop code-monkeying more features in, and to start behaving like actual 'engineers' who've designed the entire system properly..." - is super hard to do at exactly the right time. That's something I don't think _anybody_ gets right more than once or twice in a career (and even that only if they're lucky).
If the technology is something that could be useful to the company, then I would talk to the team & superiors and discuss with them whether we have time for that and how important it could be.
In the case they agreed, and I gave them an explanation for why and what I am doing (and how long is it approx. going to take), then I would feel comfortable learning new technology at work. I believe good communication is the key here.