Hacker News Reader

Comment by hnthrow90348765 | Hacker News Reader

>And with those new skills, your old skills will start to atrophy.

Skills don't work like muscles, please stop with this thinking model of the world. No one is going to fire you because you don't have the same speed of recall of language constructs and have to look more things up. Speed of coding is not the damn bottleneck.

Plus have a little faith in your brain that you could get back to that point if you wanted to.

View on HN

This is absolutely not true. Think of all the studying that is required before applying to tech jobs these days. Sure someone won't fire you because you can't balance a binary tree by hand, but it certainly might exclude you from getting that next job, regardless of if it applies to their day to day workloads.

If people stop manually coding their ability to do so WILL atrophy. Take away the coding agents and you'll soon have a generation of graduates wondering why their tab complete isn't writing the entire feature for them.

> Think of all the studying that is required before applying to tech jobs these days.

Surely you realize this is the problem. I just landed a mid 6-figures job _without_ grinding leetcode. They’re out there. This game everyone plays is an abomination.

Right, but are you going to fix it by yourself? No. Is the point correct that most people wont remember half of the arcane rituals we're expected to perform on command only in an interview or in very specific parts of the job? Yes. Can we relearn it? Sure. Will skills atrophy if unused? Definitely, balancing a binary tree is not like riding a bike.

Remembering how to balance a binary tree is a complete waste of brainpower. We have lots of papers, books, and reference material that can show us this.

The arcane rituals of jumping though leetcode hoops reminds me of pledging a fraternity.

Surely you don't believe that there's a significant fraction of tech jobs that pay $500k?

No, not sure where you got that from.

Oh, I guess you were just sharing and this wasn't advice:

> I just landed a mid 6-figures job _without_ grinding leetcode. They’re out there. This game everyone plays is an abomination.

I’m way too humble and jaded to give advice to strangers on the internet, yes.

I offered an anecdote.

Surely you realize that "balancing binary tree" is just an example and the topic is not about recruitment process.

There’s a difference between not learning something, and not using something after learning it. For the latter the relearning process is fast. And often it may only requires a few hours of practices. There’s such thing as long term memory.

> but it certainly might exclude you from getting that next job, regardless of if it applies to their day to day workloads

As others have mentioned this is the problem. Not being able to pull up a binary tree the most efficient way on the spot should not be the criteria to identify a good developer.

But then the question becomes what are good criteria to do that ( and what is the easy way to do it for HR )?

If you properly learn the skills, then refreshing your skills takes way less time than learning them the first time. This means you didn't really lose the skill.

>Sure someone won't fire you because you can't balance a binary tree by hand, but it certainly might exclude you from getting that next job

People that do this need their behavior changed. Testing people on quickly find-able implementations is an absolute circus. Obviously an exception if the job actually involves writing CS algorithms, but most of them do not.

I learn new languages mostly for hirability or to explore new and fun concepts. After the realization that my job is solving problem and not using shiny tech, most of my reading has switched to what problems people are facing and possible solutions. And that usually involves a mix of theory (to understand) and best practices (as shortcuts).

There’s one optimization path that people seems to barely explore (other than editor nerds): navigation based on search and marking stuff for further actions. You see people using VS Code like notepad and they go on to complain that coding is tedious.

Sounds rewarding, any particular resource you would recommend that you've enjoyed?

Here is my current reading list (in CSV Format).

https://pastebin.com/BXwTjY54

As for the second part. Learn vim, emacs, kakoune, or try to be fluent in your current editor. The reason I put Vim and Emacs on top of the list is that they have powerful primitives for coding and they're not notepad patched with external tools.

> Speed of coding is not the damn bottleneck.

What you say would only be true in an anarchist island colony devoted to software craftsmanship where everyone is healthy and under 40 years old.

Skills 100% atrophy.

But they never atrophy to 0%. The body remembers. You're never restarting from scratch.

For sure. It comes back quicker the next time. “Muscle memory” is real.

This post is completely false

Reply on news.ycombinator.com