Comment by keyle | Hacker News Reader

Comment by keyle | Hacker News Reader

Heck no I regret nothing.

I can program anything, bring me your dead and I will raise it.

Specializing, that's called a job. Work is work and they have a stack you gotta use, better or worse.

No one can take the hacker out of the hacker though.

My resume in terms of languages basically goes back in time, where I'm "expert" of what I use every day, but what I haven't used for a while I just put "good".

How do you sell yourself as a specialist to a company with a stack? Simple, "I don't know X but I'm keen to learn. I'm sure I can scale up to it". If they pass on you, it wasn't meant to be. As a job, your job is to return higher value than your cost. If you do that within a team, you're a net positive. Whether it's by teaching what you know as an expert, of coming up and scaling up to help wherever you can.

Either way, there are very few stacks that are permanent enough that you could be an expert in the matter for decades. Things simply move too fast.

So get behind any shiny new stack that you fancy and become a subject expert, it might pay the bills in 5 years. If not, you probably learnt transferable skills. At the end of the day, no matter the language, stack, team, we're just all trying to get the computer to do X.

> ... If not, you probably learnt transferable skills.

Actually, I like to think that I focus primarily on the "transferable skills" part, with languages being secondary. Many patterns, algorithms and data structures are quite general from language to language, while they can be quite specific to a problem domain.

Once you know 10-20 languages, learning another is usually tivial, even though learning most libraries, style guides, etc requries some more effort. Properly learning the ideas are harder, but also more rewarding.

Many devs will use structures like HashMaps based on heuristics or cookbook approach. But when you're able to see the similarities and differences between HashMaps within microservices in k8s, hash joins in a RDBMS or broadcast cash joins in Spark, and you understand the strengths, weaknesses and compromizes of each, you have a type of understanding that almost certainly will be useful in whatever langauge is popular 20-30 years from now.

The counterpoint to this is the C developer who promises they can scale up to C++ and then takes a disproportionate amount of review time to be taught not to use malloc/free/new/delete/etc.

This is why I say I can do any language but C/C++. It’s a skill I’m sure I could build, but it’s not going to be pretty at first.

Educate me, pkease: why no new or delete? Does C++ now discourage heap allocation or is the common practice to use smart pointers, etc.?

Constructing into a unique_ptr[1] will mean you don't have to risk forgetting to delete it or risk managing something you don't own. You'll also sometimes get compiler spew that you'll learn is telling you you're trying to do something nonsensical e.g. use its copy ctor. In contrast, if you try to copy a raw pointer that is intended to be unique then you get a copy of a pointer and a Heisenbug.

Also a lot can be done with things that are on the heap but act as local variables.

[1] You probably don't actually need a shared_ptr and if you do then it won't stop you from creating memory leaks.

Yep. In new code you should use smart pointers for allocation as much as you can.

This. This is exactly how I feel. Instead of waiting for work, I can find work and get dangerous quickly anywhere. Try me.

Reply on news.ycombinator.com