Hacker News Reader

Comment by wiremine | Hacker News Reader

For context: I'm VP of a software consultancy responsible for delivering software on time and on budget.

My take is that older programmers who maintain their skills on new technology are worth their weight in gold. The financial trick is to pair them with younger developers to create an overall cost effective team. If both the older and younger devs go in with the right attitude, it can be wonderful for both the project and their respective careers.

I also think it's really, really dumb to push developers into management positions if they can't do the job. I'd much prefer putting younger managers with great management skills into the mix than just rotating older devs into that role.

Bottom line: software requires lifelong learning. If you can't or won't stay current, you're in trouble. If you can, then it's just agism or a bad business model that's keeping you out of awesome projects.

View on HN

In the article they mention a Python conference. I think Python is a good counter-example. It's an old language and still as strong as ever. On Stack Overflow, it recently passed JavaScript [1]. Unlike JavaScript, new Python code isn't all that different from old Python code.

A lot of older Python candidates are being passed over for younger ones. Sure they might not be learning Rust, but there are younger python developers that are having an easier time getting a job, and they aren't necessarily learning Rust either.

[1]: https://stackoverflow.blog/2017/09/06/incredible-growth-pyth... https://insights.stackoverflow.com/trends?tags=python%2Cjava...

> It's an old language and still as strong as ever.

Does it make sense to consider Python an old language if it's still a living language? The next version is coming out in October, and most new projects started today are running on versions released within the three years.

This seems pretty different than something like COBOL, where it's technically still being developed but not in anywhere near the same way.

Not if being old has a negative connotation, or if being old implies that they have no new ideas, neither of which should be true, of technologies or of people.

It's also worth noting that recent python versions have added tremendous quality of life improvements. If you haven't kept up with the language, then the code you're writing may still run, but it's not "pythonic" anymore.

I haven't touched python in years. Can anyone link to a list of examples? I remember hearing about optional typing, which is always my favorite addition.

Python is indeed getting better and better, but I personally wouldn't include optional typing... yet. Mostly because the optional typing in Python is just for tooling, not for the run compiler or run time [1]. Python is one of my go-to language, but I haven't found a compelling reason to use type hinting yet.

Python's really good at binding C code [2], which is one of the reasons you see it in so many machine learning and scientific projects (Numpy, Scikit, Tenserflow, etc.) I think that's what given Python a lot of legs in the last few years.

[1] https://stackoverflow.com/questions/41356784/how-to-use-type...

[2] https://stackoverflow.com/a/10202569

> Does it make sense to consider Python an old language if it's still a living language?

Python, I'd argue, is very much a living language. It was introduced in 1990, so it's 29 years old. Last release was 5 days ago as I write this [1]

Java, is also a living language. It was introduced in 1995, so it's 23 years old. Last release was in September 25 [2]

Cobol was introduced in 1959, so it's 1959. [3] The last table release was 2014 (which is a lot newer than I would have expected). Cobol is a great object lesson, I think, as the parent comment calls out. I don't think many software engineers would consider it a "modern" language, but according to the Wikipedia article, as of 2012, 60% of businesses use Cobol. So it's far from a "dead" language.

Lisp was introduced in 1958... 61 years old. [4]. I don't think many developers would consider Lisp dead, either.

Cobol's longevity seems to be tied to the fact that much of the legacy code encapsulates business logic, as opposed to UX logic (websites, mobile apps, etc.) There's more than a few lessons in there I think...

[1] https://en.wikipedia.org/w/index.php?title=Python_(programmi...

[2] https://en.wikipedia.org/w/index.php?title=Java_(programming...

[3] https://en.wikipedia.org/w/index.php?title=COBOL&oldid=88324...

[4] https://en.wikipedia.org/w/index.php?title=Lisp_(programming...

I consider the 1958 Lisp to be dead. The Lisp family's longevity doesn't stem from maintaining legacy code from 1960, but because it actually embodies attractive concepts that continue to captivate new generations of coders, often not in connection to anything mundane, like a job.

Not ragging on Lisp here in any way, but it's been long since the original Lisp is has been viable. It continues to historic significance, and anything that calls itself Lisp still has cons, car, cdr, atom, lists ending in nil (which is a symbol) and such. In 1958, you had no macros, no lexical closures, no exception handling, no backquote, no objects or structures, no bignum integers, ...

Whereas COBOL today is pretty much the same pile of stuff it was in 1960-something. It's not a vibrant language family with newer members. COBOL does not absorb new concepts.

There are new, young people learning COBOL, but only in order to become maintainers of legacy systems: job security in banking, finance and government sectors. Maybe a few have a perverse curiosity: they want to know what is really behind the dirty five letter word.

New people coming to a Lisp are coming for the Lisp itself. There aren't that many Lisp jobs involving new or legacy coding; new Lisp people learn and make new stuff from scratch.

There is simply no comparison.

I'll be 50 soon and I've been dabbling in Rust. Not to improve my skills or any of that, but simply because my 40 years of coding experience tells me it really is awesome. I have some specialization the will be good for some time to come. When I read these ageism articles I just keep shaking my head. Last company I worked at had tons of them. You startup folks must live in a fucking bubble. (That was for effect, I love HN in case you oversensitive millenials can't tell)

So did you experience ageism or not? I couldn't tell from your comment.

No. Not even a little. My post was a bit unclear. One company I worked for has lots of older guys and it was clearly good for their products.

Companies should embrace a multi-branch management approach. Have technical managers, who are experienced engineers that can focus on ensuring that people are doing quality work and building great products. Then along-side them, the team should also have a people manager, who is responsible for navigating the politics of the company.

I've had managers who were both technical and people-oriented. They both bring a lot to the table. But the older I get, the more I value having a manager I can go to who is good at managing optics and helping me deal with political or institutional roadblocks. In an idea world, I'd have both.

This is somewhat the dream of matrix organizations, but has it's own set of problems.

But fundamentally, if you can't move the decision making power/responsibility/(+ to some degree compensation) out to non-traditional locations in your org structure, you'll naturally have to move those people towards the more traditional locations....

I work at a small matrix organization. Deployments and time allocation are fairly chaotic due to lack of communication, but on the other hand we do have relatively many older people doing technical work and projects are managed by a mix of older and younger people.

   I also think it's really, really dumb to push developers into management positions if they can't do the job.

Even if they can do the job, it may not be the best use of their time. If someone is really good technically, they are more difficult to replace than a competent middle manager. So if that's the trade off you are making, you are probably losing out.

> older programmers who maintain their skills on new technology are worth their weight in gold

and also true of older programmers who maintain their skills in older technologies. see all the COBOL comments below. If history is any guide, competent Java programmers in 10 years will not be aged out, and will be compensated more than whoever is competent (regardless of age) at the current tech stack.

>> I also think it's really, really dumb to push developers into management positions if they can't do the job.

This has been known forever, yet it still happens - Why?

>> I'd much prefer putting younger managers with great management skills into the mix...

One reason is it is impossible to tell if a young manager has great management skills. It's really hard to tell if an experienced manager has strong skills.

As a result, technical proficiency is used as a proxy for management potential. It probably has a stronger correlation than picking a random person, but is not great. The new manager is then really unhappy, quits or is fired or eventually learns the new skills and is successful.

Repeat.

Some companies only have one kind of career track. If you want more money, you have to be in a manager position. They don't have a way for experienced programmers to keep moving up in their careers as programmers.

Is there any tech company where the technical track doesn't plateau below the people-manager track?

GitLab (I work there) does allow you to become Staff-Level which is the same multiplier as a manager.

Yes, that's common: but I have yet to see a case where the tech track goes as high as the management track. For example, "Distinguished/Staff Engineer" might be the equivalent of a "Senior Director" in an org with two or three levels of management above that (VP, SVP/CTO, EVP, etc.).

Google's tech track does go all the way to VP equivalents.

Many companies have separate tracks for independent contributors and managers. You can stay an IC and level up to Distinguished Engineer or Fellow or Staff Engineer or whatever, without needing to go into management.

I think we might need a curated list for those. At 17 years of career I've only seen one such company.

It seems pretty common with bigger companies: Google, Apple, Facebook, Amazon, Oracle, Box, Zynga, Electronic Arts, Pinterest, Microsoft, etc.

The tracks and levels are commonly referred to as the "job family architecture" -- don't be afraid to ask a recruiter for this information. Otherwise you'll never really know if you're being properly leveled. (For instance, I believe a Principal SE at Microsoft is roughly equal to a Staff Engineer at Google.)

The issue isn't the absolute height. The top manager (CEO) is going to make more more than the top IC, that's just obvious.

The real issue is that management is a pyramid but IC is ziggurat with, if you're lucky, an obelisk sitting on top of it.

People like to point to the principal staff engineer or whatever, but there's one of them for every twenty upper-mid level managers making the same money. And all those managers can take their skills to another company, but if an IC guru leaves the company where he made his bones he's probably destined for consulting (at best). Consulting has its upsides, but that's no more for everyone than management.

I think both are true. There are more "slots" for management than technical leaders at the same compensation band. There are also generally at least some compensation bands in management that are above the highest band tech lead role (architect, chief/principal/distinguished/staff/whatever).

In my company it’s also much slower to move up the technical track compared to the manager track. If you want to make money it’s much better to be manager.

I guess that would just not be realistic. There was a comment from a while ago that I think makes total sense: The organization has to evaluate the value that you bring and create. If your position moves and directs dozens of people, it will be hard for an individual contributor to match the importance no matter what. Of course, it's fine if you prefer to remain a more individual, engineering-oriented position. But there is little reason to expect you'd reach the same level of importance to the organization as some top managers/executives.

Agreed, completely. Most ICs overestimate their importance by far. Most people do regardless of title.

>> I also think it's really, really dumb to push developers into management positions if they can't do the job.

>This has been known forever, yet it still happens - Why?

This problem exists in hardware departments too. My best guess is that they want managers familiar with the tech/industry/company. My second best guess is that it's a natural human tendency and hasn't been addressed systematically.

I come frome a industry that sees software written under management that largely has no clue what software is, how to evaluate its qualitys and tech debt - and thus creates exponential tech debt time bombs.

Reply on news.ycombinator.com