Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Zen of Missing Out on the Next Great Programming Tool

thepracticaldev.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: The Zen of Missing Out on the Next Great Programming Tool

#11

Post by JustSomeNobody »

swah wrote: post #7
theodorton wrote: post #6

Earlier quoted context omitted.

People should be more concerned with fundamental skills IMHO. I don't think there are Ruby and Javascript programmers. You're either a programmer or you're not. What language/framework is just a means to an end.

It is unfortunate that recruiters don't seem to understand that...

True, but as a programmer, I believe you have to at some point start filtering out jobs that are hiring for . That doesn't leave many jobs and one has to be willing to look long and hard for them, but when you find them, you'll be more satisfied.

Re: The Zen of Missing Out on the Next Great Programming Tool

#12

Post by AnimalMuppet »

siscia wrote: post #8

Maybe I am biased, I work with Clojure since 2012, I use elixir and go, but still, I believe that once you master the paradigm (OOP, FP, or procedural) then it always the same deal, the syntax may change, but find a value in am hash map will always be faster than find a value in an unsorted list. For a programmer, once the basis are solid, learn a "new" language should be matter of a couple of weeks...

Depends on your definition of "learn".

Learn it well enough to write it? Sure, a couple of weeks, maybe less.

Learn it well enough to write professional-quality code? That takes longer, because you have to learn what the pitfalls are. (Writing professional code, in large part, boils down to knowing what not to write.)

Learn it well enough to be as productive as you were with the previous language? Maybe three to six months?

And that's the real problem, IMHO. It's going to take me three months of lower productivity to make the switch to the new language/framework/tool/whatever. How long will the new thing take to pay me back for that time it costs? If it's not significantly better than what I'm using now, it's not worth the cost.

Re: The Zen of Missing Out on the Next Great Programming Tool

#13

Post by tboyd47 »

To me, being a late adopter is obviously the best path to take. I'm honestly perplexed by devs who are so obsessed with the idea of being the first to hop on a bandwagon. What do you get out of it?

The wisest time for a dev to learn a new technology is probably at the peak of its popularity. That way, you learn from the community when it's most active, and your expertise grows more valuable as the technology slowly goes out of style. Like the author, this happened to me when I first picked up Rails in 2008-2009. I jumped on board at a time when everyone was talking about it, so I never had to look hard to find information. For the next 5 years or so, it seemed like my job prospects were getting better and better, even though the hype train had left Rails behind shortly after.

I have a pet theory that a lot of the shiny-toy syndrome we see in web development is actually fueled by startup founders who deliberately choose unproven technologies to attract talented developers ("Join us, we actually use language XYZ in production!"), since programming geniuses are often eager to delve into Turing tar-pits, and also dazzle tech journalists by promoting it as their magical secret ingredient. (...and yes, I'm aware that perhaps Rails rose to popularity this way)

Re: The Zen of Missing Out on the Next Great Programming Tool

#14

Post by shubb »

tboyd47 wrote: post #13

To me, being a late adopter is obviously the best path to take. I'm honestly perplexed by devs who are so obsessed with the idea of being the first to hop on a bandwagon. What do you get out of it? The wisest time for a dev to learn a new technology is probably at the peak of its popularity. That way, you learn from the community when it's most active, and your expertise grows more valuable as the technology slowly g…

Early adopting a tech that becomes important = being an rare, high paid experienced expert when it goes mainstream.

Also, these technologies are generally designed to solve some problem, and get adoption because it's a common problem. Struggling with a solved problem rather than using that new tool that solves it is upsetting.

Re: The Zen of Missing Out on the Next Great Programming Tool

#15

Post by sotojuan »

swah wrote: post #7
theodorton wrote: post #6

Earlier quoted context omitted.

People should be more concerned with fundamental skills IMHO. I don't think there are Ruby and Javascript programmers. You're either a programmer or you're not. What language/framework is just a means to an end.

It is unfortunate that recruiters don't seem to understand that...

Yep. Here and on reddit people are happy to say "we hire for programming skill, not framework or language knowledge!" and they may be right.

However, almost every time I have been rejected or offered a job and given a reason has been for a lack of domain knowledge (or in the latter case, possession of that knowledge!) of a particular framework or language.

Re: The Zen of Missing Out on the Next Great Programming Tool

#16

Post by AnimalMuppet »

tboyd47 wrote: post #13

To me, being a late adopter is obviously the best path to take. I'm honestly perplexed by devs who are so obsessed with the idea of being the first to hop on a bandwagon. What do you get out of it? The wisest time for a dev to learn a new technology is probably at the peak of its popularity. That way, you learn from the community when it's most active, and your expertise grows more valuable as the technology slowly g…

I don't think it's that simple. When starting a project, of the available options, which one gives you the most leverage toward building what you're trying to build? What is the cost of using that (training people plus machine resources)? Pick the best cost/benefit tradeoff and start to work.

For an existing project, the bias is to not change unless the new language gives you a massive improvement. Re-writing is always harder than you expect, because the existing code base has more bug fixes and handled corner cases than you think it does, and your re-write has to preserve all of that (or suffer the consequences of failing to do so).

Re: The Zen of Missing Out on the Next Great Programming Tool

#17

Post by falcolas »

shubb wrote: post #14
tboyd47 wrote: post #13

To me, being a late adopter is obviously the best path to take. I'm honestly perplexed by devs who are so obsessed with the idea of being the first to hop on a bandwagon. What do you get out of it? The wisest time for a dev to learn a new technology is probably at the peak of its popularity. That way, you learn from the community when it's most active, and your expertise grows more valuable as the technology slowly g…

Early adopting a tech that becomes important = being an rare, high paid experienced expert when it goes mainstream. Also, these technologies are generally designed to solve some problem, and get adoption because it's a common problem. Struggling with a solved problem rather than using that new tool that solves it is upsetting.

But it's a gamble. If it fails (and so many do, in a month or a year), then you have a head full of domain specific knowledge that you can't apply to any other technology.

Let's take web templating: How many solutions are out there, and how many of those actually turned out to be winners? To ride the crest of the React wave, you had to pick it out of a thousand others, at a time when there were other "winning" solutions.

And even React is beginning to show signs of falling, with new stars starting to shine. Do you jump ship, or hold the course?

Re: The Zen of Missing Out on the Next Great Programming Tool

#18

Post by mardiros »

the practical programmer is lazy and not passionate. More, he loose the more important skill he have: think. He build softawre by copy pasting from stack overflow.

I am not saying use every nee cool tech posted on HN, but if something looks great for you, you should investigate in it. I am not saying put it on production tomorrow... But if you have similar broblem, look how it works to have a different view of how to build a better solution...

Re: The Zen of Missing Out on the Next Great Programming Tool

#19

Post by tboyd47 »

AnimalMuppet wrote: post #16
tboyd47 wrote: post #13

To me, being a late adopter is obviously the best path to take. I'm honestly perplexed by devs who are so obsessed with the idea of being the first to hop on a bandwagon. What do you get out of it? The wisest time for a dev to learn a new technology is probably at the peak of its popularity. That way, you learn from the community when it's most active, and your expertise grows more valuable as the technology slowly g…

I don't think it's that simple. When starting a project, of the available options, which one gives you the most leverage toward building what you're trying to build? What is the cost of using that (training people plus machine resources)? Pick the best cost/benefit tradeoff and start to work. For an existing project, the bias is to not change unless the new language gives you a massive improvement. Re-writing is alwa…

If it were just about trading costs and benefits, you wouldn't see fashions and fads in tech like you do. There's a definite herd effect. Some people wear themselves out trying to be at the front of the herd all the time, when it's enough just not to be at the very back.

Re: The Zen of Missing Out on the Next Great Programming Tool

#20

Post by rapha22_1 »

derefr wrote: post #9
siscia wrote: post #8

Maybe I am biased, I work with Clojure since 2012, I use elixir and go, but still, I believe that once you master the paradigm (OOP, FP, or procedural) then it always the same deal, the syntax may change, but find a value in am hash map will always be faster than find a value in an unsorted list. For a programmer, once the basis are solid, learn a "new" language should be matter of a couple of weeks...

I think the big problem with the idea of "learning a language" is that most programmers conflate a language with any bits of CS theory that are only to be found in that language. For example, when most people say they have a hard time "learning Erlang", it's not the syntax they're complaining about (no, really!); they're really complaining about trying to wrap their heads around the actor model, which writing idiomat…

Agreed. On one of the first classes I had in college, a teacher said we should favor "knowledge" (that is, concepts) over "technics" (that is, knowing a specific way to apply knowledge), and never confuse one with the other. That stuck with me and, in retrospect, was one of the best advises I've had in my career.
Post reply on HN