[thr0wawayf00]

I used to think this way and wound up completely exhausted in my career. Coming from web dev, I used to volunteer to dive into a Objective C repo to fix some random bug in a mobile app and then a week later my boss would ask me to build a big feature in that app. I'd spend a few weeks getting up to speed on the language and build the feature, and then I would never use what I learned again. My boss would ask me to dive into another tool I don't really know and the cycle would repeat ad nauseum. In hindsight, I've wasted so much time digging into tools that I've never used again.

I definitely learned some good lessons and recognized some patterns along the way, but I think the "just pick it up and learn it" attitude contributes to poor code quality in a commercial context since jobs usually time-box things. I'm a fan of picking something up that I can get expert feedback from, which there again, requires expertise.

[kevinmchugh]

There are organizations that generate forgotten apps that are basically used but unmaintained. These are tarpits for developers. You don't want to be the person they fling at every forgotten codebase. They tend to be sideshows - if they really brought in the money, or the users, the business would invest in them and have people who know the language.

There's value in being able to go in, fix a little problem, and make things better for your customers. But you have to balance that against becoming the guy who works on the unimportant projects. That's real bad. If there's growth potential for the forgotten app, you have to get buy-in from the business and not just sideline yourself away from the things people care about.

Often these tarpits were contractually mandated. One customer wants a particular integration, so a developer builds it, and it works for the customer and everything is fine until another customer comes along wanting a similar integration and now the original dev is gone.

[sdoering]

I know from quite a few traditional corporations, especially banks that have very central old systems that they pay people enormous day rates to maintain.

But the question would be if one wants to be the go to guy for keeping old cobol things running.

[szundi]

The value of any other stuff you learn other than solving problems has half life. If you can be paid extra for Cobol stuff for a decade or two, then why not use this opportunity and get up to speed in 2-3 years after that.

If you have just a bit of bad luck, you may have a carreer with no real deep involvement with anything, not even talking about the fact that the language is just one aspect of your productivity.

[HPsquared]

You could call the general skill "software archaeology".

[edgyquant]

Refactoring old codebases into something nice to work on is comfy though. It’s basically what I do in the startup world I just use less niche languages.

Although I’d suspect there isn’t a lot of refactoring going on in some of those code bases you describe.

[kevinmchugh]

I think this is a healthy and productive career path. If you can identify when a dead codebase is about to become fertile, and how to clear the debris to support new development, you can make a lot of money, have a lot of fun, gain a lot of respect, receive a lot of autonomy.

You just don't want to be the person tasked with work that's only done because some contact got signed. Identifying the difference is hard.

[jjice]

> Coming from web dev, I used to volunteer to dive into a Objective C repo to fix some random bug in a mobile app

The thing about this is that this isn't just a language change, this is an ecosystem change. It's one thing to go from writing Python based web apps to Ruby based ones, because web dev has a lot of concepts that will apply no matter the language. Objective C might be something you can pick up no problem, but having the learn all about mobile development and that ecosystem is a much larger task, and I could absolutely see that getting exhausting if you're hopping from web, to mobile, to desktop, to embedded, etc.

Ecosystem switching requires a lot more of a knowledge shift than just a language does, IMO.

[wizofaus]

I'd agree with that. I even think the difference between frontend JS development and backend JS development is bigger than, say, backend Java and JS development. But managers, even ones with tech backgrounds, tend to assume the language is the key skill. A good developer should be able to master a couple of different ecosystems given enough time but expecting them to constantly jump between them is never going to lead to great results.

[rtlfe]

That's pretty excessive. I've switched languages whenever I get a new job, every 2-5 years. I think this is more what OP had in mind.

[ipaddr]

How do you switch languages during a job search? Are you avoiding companies with language requirements (four years Ruby)? Do you run into language/framework tests and/or homework assignments in languages you are unfamiliar with?

[rtlfe]

I've interviewed at probably 15+ companies over the last decade, and none of them had language requirements or tests. Honestly I see those things as red flags. If you can find somebody with good problem solving skills and proficiency in any language, they'll be able to pick up your language no problem.

[hutzlibu]

"they'll be able to pick up your language no problem."

That still takes time. If someone is already experienced in an (complex) ecosystem, he or she will be way more effective in it, than someone who has just general skills. I guess I am a very good problem solver. But if I suddenly would have to do a C++ project with all its footguns, I am not aware of (last time I coded in C++ was in university)? I would suck in it for quite a while. This would not be effective at all, unless I would want to change my skillset to the C++ ecosystem.

[rtlfe]

> That still takes time.

Yes. I want to work somewhere that shows they're committed to the long term, not somewhere that's focused on how much I'll get done in my first week.

[wizofaus]

I'm guessing that's not typical for most devs and most job openings. Recruiters in particular seem to assume they need to find devs experienced with particular stacks, and for companies who need to quickly re-fill roles after losing staff, a good dev with experience in the stack/ecosystem you've been working with is always going to get up to speed faster than one without that experience. I'd also say convincing hiring managers that specific libraries/ platforms/languages/tools that you've been using shouldn't be listed as "must have"'s in a JD is hard.

[rtlfe]

> most devs and most job openings

I'm not sure. I'd guess very few companies that hire more than 20 devs a year would have any language requirements. But I don't know what % of jobs are at companies of that size.

[wizofaus]

In my own city I'm not sure there are any such companies. But I was involved in helping out with a hiring round for Thales recently that were looking for 15 devs. They had very strong language requirements.

[fab13n]

I prefer companies which are open about the technologies and languages I'm experienced with. That's a huge green flag, that they consider their software engineers as smart people solving hard problems while continuously learning new skills. It also means they listen to their senior technical staff, which consider that learning new bits of stacks is hardly the most complicated thing they expect you to do.

As opposed to companies which consider them as glorified factory workers, who are insufferably hard to manage and monitor.

I'm currently working with RoR, which I'd never used before, and what matters is that I know algorithms, SQL beyond ORM, how to write code which won't be a nightmare to maintain in a couple of years, etc. All those skills are the same in Rails, in Django, in C++.

[jrockway]

Does anyone still have language requirements? I did my Google interviews in Perl and wrote mostly Java and Go there. At my current job, our codebase is all Go (expect frontend) and pretty much nobody we hire has prior Go experience.

Prior experience is almost a curse these days. I learned Go by having the Go team review every one of my CLs for a year. Now I do Go code reviews and think "that simply isn't done, I would never have been allowed to check that in", but often have a hard time supporting my arguments. (When Effective Go, Code Review Comments, and Test Comments fail me, I usually resort to snippets from the standard library. "This pattern appears 0 times in the standard library, I don't think we should use it." It's a lot of work, but I will say that a few things I thought were simply never done are actually done. And that's my standard; I hate it, but Go itself did it to implement Go, so you can too.)

Side rant: I guess the Go team stopped doing this. Read Kubernetes for the current state of Go at Google. Wow.

[azemetre]

Is the wow bad or good?

[lmarcos]

It's easy to trick recruiters about tech stack ("We require someone with 5 years of experience in Django". Me: "Sure, I'm qualified"... While in reality I have over 6 years of experience in RoR and I have probably used Django in one side project). The moment you pass the screening part, then it comes the part when you judge your future/potential team: do they care about good engineers or good django engineers? Usually, it's the former.

[BryanBeshore]

Having done the merry go round of different languages, it also feels great gaining expertise in an individual language and to utilize new (release) capabilities of that the language.

[thr0wawayf00]

Absolutely. Conversely, it's frustrating to deal with a build and release system that's subpar compared to what you're used to working with, but I recognize some folks probably feel that way about my preferred tools. That's just where I've chosen to invest my time I guess.

I was shocked at how hellish compiling and releasing a large iOS app was compared to deploying a web service, not to mention setting up the development environment and installing dependencies.

[wizofaus]

Yep, if I never have to deal with an automated CI/CD pipeline for iOS again (especially trying to reliably run unit tests - the simulator is flaky as hell) I'll be very happy. I don't even mind the MacOS-only requirement so much (though it does suck), but Apple's tendency to constantly force breaking changes on you is just an endless source of pain (by force I mean, release to App Store not permitted unless you build with version X of Xcode, which requires version Y of MacOS which is incompatible with version just-about-anything-else or everything else you're using.)

[rco8786]

> I've wasted so much time digging into tools that I've never used again.

Don’t think of it this way. Learning new tools is almost never a waste of time, you just don’t know when you’ll need the lessons learned next. But you will.

[weatherlite]

What lessons do I learn from learning webpack? Or whatever the new way of bundling things in FE is called now?

Compare that to understanding C or UNIX. There are skills that decay much slower than others.

[biztos]

Maybe it's counterintuitive, but I think the "jack of all trades" role should be given to someone who's very senior, but isn't focused on career advancement.

It sounds like you got stuck learning more trivial things before you had a good foundation in something more substantial (like C or UNIX).

If it weren't for the rampant ageism in the industry, that job might be a perfect fit for someone in their 60s who has already written a few million lines of C and is happy to help less experienced people just get unblocked.

Instead it often falls to the "junior senior" because the "senior seniors" are all pushing 30 and need to work on portable skills.

(Just my observation of the industry, maybe your own case was different.)

[goodpoint]

> Compare that to understanding C or UNIX. There are skills that decay much slower than others.

Correct! Knowledge around C, Linux, CPUs and optimization last many decades.

Knowledge of tools and libraries in high-churn languages last years at best.

[EddySchauHai]

I've found a lot more career happiness with focusing on a long-term domain (networking), long-term expertise (testing), and a stable tech stack (python, c, etc). Got pretty close to burnout chasing the latest libraries in the latest languages a few years ago but now I'm very happy making sure the product is cutting edge but the tech stack is stable.

[weatherlite]

This is what I'm trying to do as well now (move from full stack web dev to something more in the lines of what you're describing). Any tips you can remember on how to make the move?

[EddySchauHai]

I spent a bit of time practicing these tech stacks in my own time and fitting them into prior jobs where I could, but honestly it’s worth just getting out there and applying.

[LAC-Tech]

As a fellow webpack victim, the new way of bundling things in FE is esbuild and it's better in every way - faster, simpler to configure, easier to understand... and did I mention faster? my god it's so much faster.

Your point about wasting your finite life dealing with webpack still stands, but just want everyone to know that there is a ray of light in frontend.

[mmartinson]

It's valuable to consider the opportunity cost of this compared to a deepened knowledge of an already productive tool

[rolisz]

It depends. Maybe the alternative is to get better at a tool you already know. Maybe you can be a jack of all trades, master of none, or you can go really deep into only 2-3 things. It depends a lot on your personality I think.

[sys_64738]

> My boss would ask me to dive into another tool I don't really know and the cycle would repeat ad nauseum.

There is power in saying No.

[unnouinceput]

There is power in saying "Yes, for this price" too. Explain the problem and the damage to your mental health if you do that, hence the price.

[afarrell]

Your first sentence is correct. Your second sentence would be better revised to "Explain the problem and the fact that the client will be signing on for a long timeline and high level of schedule-risk. Then work at a pace which does not damage your mental health."

[zinodaur]

an edit I would make to

> think of yourself as a problem solver, rather than a programmer of a specific language

would be to

> steer away from problems that are boring to you

E.g., there are very cool programs being written in Objective C, so I wouldn't write off a job just because it was in Objective C

[winternett]

I can't tell you how often a huge and expensive Oracle DB app design project turned into just emailing spreadsheets instead... That would get me fired.. -Senior Developers Everwhere. :P

[Aperocky]

> contributes to poor code quality

I have another perspective, I think code quality are pretty uniform across languages, either all of ones code quality is poor or it will be fine across all language one writes.

Most of the code quality stems from logically dividing the building blocks and making it readable. Hence it should be logically traceable and uses the basics whenever possible. This is good, readable code.

Obviously some languages demands greater knowledge (e.g. C, Haskell) to master and use appropriately but they are a minority.

[wutbrodo]

I strongly disagree. It's very visible when someone is trying to write (eg) Python in C++ or vice versa, in a way that can substantially harm readability.

[AlwaysRock]

Yeah I agree. I know growing and learning is the job. But how much am I going to use X in the future? I did one project in PHP. Just enough to learn I don't really like working in PHP. Is a few months of PHP experience useful in later job searches?

[zerr]

Sounds like a dream job! No joke.