Hacker News Reader

Comment by henrik_w | Hacker News Reader

My perspective, as an older developer (I'm 54):

- I love coding, and I still code every day. I have no desire to move into other roles (such as management).

- As for job security, I think it is harder to find a job as a manager than as a developer, simply because there are many more positions for developers than for managers

- Family-wise, it is much easier at my age, because my children are getting into their twenties now. Much more free time for me (including for work if I want), compared to when they were younger and need lots more attention (and being picked up from daycare)

- As for learning - that's one of the attractions of being a developer. There are always new things to take in, it never gets boring

- On the other hand, even if some things in programming are fleeting (the currently popular frameworks etc), there is a core of fundamental knowledge that you gain over the course of your career that will always apply.

View on HN

50+ here. Never had an issue. Many media articles in this context also "consult" or "quote" or "interview" someone from a company that "consult older software developers how to stay in the market". One note: you have to respect it from both sides, and factor out age when young person is your manager or colleague. Your age is not an argument in a technical discussion.

Not everywhere is a high demand market. Brazil here. The job market really wants low paid workers that will work Saturday nights for peanuts. A lot of my older colleagues emigrate to have good technical jobs. Others become sellers or open a restaurant.

Very much agree with this. As someone who’s managed people 20+ years my senior, it always annoyed me when I overheard them complain about reporting to someone younger. I don’t hold their age against them, it should be reciprocal.

20 years is a huge gap. Those guys were writing operating systems at school before you were born. Of course they'd complain

But the age gap alone is not a valid reason to complain. The young manager could be in their 30's with over a decade of experience themselves, and they may be highly competent at the work they do. Assuming the young person is not qualified to manage veteran programmers is also a form of age discrimination.

If they're managers they should be in management jobs. If they're not, why should they complain about not being management? Management is its own job, not a "reward" granted for time in service. Not even the military works like that.

The point is that it’s still age discrimination. If someone wants their age to not work against them, they have to be willing to look past the age of others.

Besides age is not an indicator of quality of work, nor are college credentials. I’ve seen much older devs run circles around younger ones, and vice versa.

I am sometimes tempted to tell colleagues "well I've done this professionally since before you were born, so...", but so far I've resisted the temptation. Hope I can keep the streak going :)

Even if you're right, it's not a great argument, because there isn't really a rational counter argument.

If the argument is only based on having more experience - the "I've done this professionally since before you were born" argument - it can be correctly rejected as an argument from authority fallacy.

If the argument is based on a pattern you've seen before that's germane to the situation at hand - the "I've seen this movie before and it ends with regret and a data breach" argument - it can be much more convincing.

> I am sometimes tempted to tell colleagues "well I've done this professionally since before you were born, so..."

This sounds like you want the respect due to age alone.

The respect due to age alone is horrible. I wouldn't inflict it on my worst enemies.

The respect due to age and experience, on the other hand, is substantial, and something to strive for.

Back up your gray hairs :) with some relevant knowledge and the intelligent people will listen attentively.

> "well I've done this professionally since before you were born, so..."

This sounds like something coming from the advanced or expert beginner:

https://daedtech.com/how-developers-stop-learning-rise-of-th...

You don't influence by pulling the seniority card, you do it with data. If there isn't data to back up your suggested approach being better, it might not be, and you get to learn something new!

Well, often the data is conclusions from my decades of experience. It's not like I can show that in Wikipedia.

What I actually mostly do is saying "Doing X never works, because Y, instead I like to do Z because...", and it has reasonable success.

People want to hear it can work.

Sourcing data is expensive. I think it's best not to underestimate just how much development has to be done based upon gut feel, trust or experience simply because proving it would take too long.

If it's two people arguing their own opinions at each other and neither one has relevant data where exactly do you go from there? The one with 2 years experience or the one with 15?

Sometimes the data is the experience, and it's hard to dump your personal experience on someone and make them ingest it. Sometimes you've tried approach X a couple of times and it always failed, but you don't have a scientific proof it will fail again. You just know from experience if you do X it usually ends up in tears and all-nighters and missed deadlines. Not because you have an Excel table proving it, but because you've lived it.

"Historically this has turned out badly" and back it up.

If we are going with anecdotal evidence, I'm 55, in top 1% in my field with comprehensive knowledge of modern and cutting-edge technologies. After age 45 was denied promotion and had to look for another employment; was fired (from another employer) at age 52, was out of work for 7 months and had to take a position way below my level. Still there but could be fired at any moment (cost cuts, esp. under current circumstances). Receiving a lot of calls from headhunters based on my excellent linkedin profile, but never went pass first interview in 3 years.

I'm only half kidding here, but have you tried dyeing your hair, wearing slightly "younger" clothes, not including everything on your CV (and definitely no graduation year, etc.)?

It seems ridiculous but I wonder if it would work.

It's not ridiculous: I'm partly bold so I always shave my head. I tried to remove graduation years from my resume and did not find it's useful; it would only work if ageism was a sin of a few. Now I keep all my cards open: if my age would be the reason I prefer to skip erroneous interviews that hiding it would have brought (wasted 2 months and 4 interviews, Amazon, yeah?).

> - On the other hand, even if some things in programming are fleeting (the currently popular frameworks etc), there is a core of fundamental knowledge that you gain over the course of your career that will always apply.

Spot on. Ignore the popular framework of the month.

A lot of developers focus only on the surface (popular tools) and neglect fundamentals, algorithms, OS internals, how CPUs work, networks...

You can't ignore it. If you ignore the framework that is a requirement for 20-30% of advertised positions, then you are limiting your ability to get hired. That may be good advice if you are the one architecting the new project, but not if you are looking for a coding job. If you are looking for a new coding job, look at what people are hiring for and at least get familiar with a good number of those things.

Of course if you aren't having trouble finding a job then you don't need to follow this advice.

I interviewed a whole lot of people when I was in Amazon and no candidate was rejected, in my memory, for not knowing a tool, a framework, one language or one category of technologies.

The interview topics of on-sites are general enough and focused on principles, and, by far, the large majority of candidates are rejected for giving vague and superficial answers.

My experience convinced me that, as a candidate, I don't want to divide my time preparing and interviewing for many "typical" companies. I instead focus on very few interesting ones and maximize my chances there.

"shotgun versus sniper" if you will: you need one good offer, not 10 so-so ones.

Among other reasons, the typical buzzword-driven company is less likely to be an interesting environment to work in.

You can still ignore the framework.

You won't apply to to 100% of jobs. So you already make a selection.

Some jobs are require highly specialized skills and knowledge. Keeping up with the framework-of-the-month costs time as well. Time you could have spent getting better at Linux kernel programming or Cobol.

"If you ignore the framework that is a requirement for 20-30% of advertised positions,"

The "framework of the month" is not "a requirement for 20-30% of advertised positions". The "framework of the month" requires a minimum of a year to get to that point and 2-3 years is a lot more common, even in the JS frontend space. By the time something gets to 20-30% penetration it's past that phase.

What's the path around this?

I've tried to keep one main language and work with something different each time. It creates diversivity in my resume but allows me to use my core anchor language to find a role.

How do you pivot to something brand new?

Well, one option is just to ignore framework of the month entirely. It is perfectly feasible to just pay attention to things that prove themselves to the point that they're 10% of the relevant listings and have sustained that for a year or two.

A mature engineer doesn't need to be bleeding edge. It's perfectly fine to merely be tracking technologies that have gotten to their high-growth phase.

The other thing I try to do is have coverage, such that even if I don't know a particular tech I have a story that says I can learn it easily. I've used enough DBs that I don't need to chase the latest things; I'm confident that even if I've never used a columnar database that I can pick it up quickly if I need it. I've used enough programming languages that I don't need to go chasing the latest one, because it is still frankly mostly a different spelling of things I've already used. And so on. So I don't need to go chasing everything all the time. I generally don't pivot into anything brand new, because within the domains I work in, there isn't much fundamentally new stuff left for me to pivot into.

(A lot of my recent growth involves learning how to do engineering while being more directly tied into the business and interacting with business people, and learning how to be an interface between business and tech, rather than more types of tech. I'm doing this from an engineering perspective rather than a "management" perspective, because it turns out there is quite a difference between the two once a company scales up enough.)

I was taking "framework of the month" a little less literally.

Yeah, but that's a pretty big gulf.

Why ignore? Take a look, have an idea. Add another data point to the chart of where the industry is going.

Once you have seen, say, 15 frameworks, it becomes easier to map a 16th in the coordinate space, and quickly learn it when needed by reusing the knowledge you already have.

I find keeping up with the popular frameworks improve my knowledge of best practices and patterns.

All good points, brother.

I'll just add that the perspective of many years of experience brings clarity to many discussions.

= have you chosen tooling that is going to last five years?

= is the design as simple as possible or are we building a Rube Goldberg machine that will assert a life of its own?

= how are you going to train people / maintain the system? do we have a resource plan or is this a death march?

I agree that it brings clarity. You need good soft skills though, or else that clarity can become bitterness as your pragmatic advice is ignored and your teammates wonder why you always seem so oppositional.

Hasn't happened to me, but I've had a couple older coworkers who seemed to be in that place, which just seems like such squandered experience.

>> but I've had a couple older coworkers who seemed to be in that place, which just seems like such squandered experience.

It is squandered. It's one thing to know the right path based on experience. It another to be able to share that experience in a way that benefits others and helps them understand why it's the best choice. Nobody knows everything either, so having a real conversation can result in learning both ways.

Question regarding your last 2 points: how do you reconcile the fact that "there is always something to learn" with "I'm basically just learning a library/framework that does the exact same thing but with different names in the API"?

I'm being a little hyperbolic here, but after a few decades in the industry it's kind of baffling how few novel ideas are in these new frameworks. There is even a trend to go back to server side HTML and SOAP-like APIs. The tech industry sometimes just looks like the fashion industry. But maybe I'm just too cynical :)

> I'm basically just learning a library/framework that does the exact same thing but with different names in the API"?

I won’t say I reconcile anything, but I get a chuckle out of it. Makes it easier to learn the new flavor.

As The Who said, “Meet the new boss. Same as the old boss.”

To add another example to the two you provided: how many different designs and implementations have you seen for pub/sub and message-based systems (topics/queues). I literally lost count. Even fucking Redis has an implementation!

They go back at least to the 1970s. (Remember Enterprise Service Busses in the 90s?)

I think it easy to lose sight of the big picture.

Things are constantly improving, even if the road is winding. People just forget some of the horrors of the past. We used to have VB/VBA, now we have Javascript. We used to have Ada, now we have Rust. C++ has evolved.

Even C has evolved, in a kind of meta way: C itself hasn't evolved much, but the ecosystem around it has evolved a lot. How common was something like Valgrind back in 1990?

Whenever you forget how much we've moved forward, despite occasional setbacks, look at this: https://www.youtube.com/watch?v=fPF4fBGNK0U :-)

I think there is some cyclic property here, but I like to think of it as a sort of meta-refactoring. As we go back to SOAP-like APIs, as we return to mainframe computing, as we rediscover peer-to-peer networks, we take all the knowledge and improvements from exploring an alternate area with us. The advancement is in the nuance.

And, of course, there's also just the Eternal September effect with the vast majority of developers needing to learn things that the grey beards have already learned but have no succinct way to communicate (or just aren't heard over the roar of constantly greater numbers of developers with each passing year)

"SOAP-like APIs"

Do you mean things like Swagger?

[NB There have been few things I've hated more than SOAP]

No, as far as I understand Swagger it's just a tool to document your API. I'm more thinking about some ways GraphQL is used/implemented.

No question about the job security angle - a software engineer in tech is the best job security you can get. I also agree it has better work life balance than mangers, as long as you can get yourself motivated to get things done.

> a software engineer in tech is the best job security you can get

Can you explain this? Anywhere I have ever worked (Fortune 500 orgs) I have always had an "at will" employment contract as a W-2 employee. They can fire me at any time for any reason. Furthermore, when budgets are cut typically the first group to go is the IT department, since they do not bring in any revenue, unless the company is selling IT products and services.

I think there is a difference between working at a company where software is the product, vs a company where software only supports the main product (i.e. an IT department). Companies where SW is the product value developers more I think.

From a management perspective a company where software is not the product makes the software team is what's called a cost center. And companies love cutting costs. At a company where software is the product, the software team would be treated more as a profit center. In general, you want to be in a profit center, not a cost center. Hell, half our homework in accounting 102 was problem sets calculating if it was economically beneficial to outsource a given cost center - even at the most basic level cost centers are places that people want to cut.

Definitely. When an engineer is part of the “front office,” they’re valued and paid. When they’re part of the “back office,” they’re commoditized.

Has much less to do with software than strategy: maximize core competencies and minimize overhead.

> Companies where SW is the product value developers more I think.

And the IT budgets are different. Very different. On a related note, remember when some organizations had IT (and specifically web dev) under their marketing departments?

In case the OP doesn’t reply my interpretation is there is way more demand than supply so sure you’re “at will” but you could find another job quickly. As for fortune-500 and IT layoffs I imagine we are talking here about technology companies for which “IT” isn’t a line item to be cut but _is_ the business. Rules may be different at BestBuy or Bank of America but I bet not by much.

This. I haven’t been out of work as a developer in 28 years. And I’m definitely not in the top 5% of developers skill or intelligence-wise.

I am not the person you are replying to but I would imagine they mean "job security" as in if you get fired you can find another pretty quickly.

The “in tech” part I think was meant to say in technology/IT focused companies.

Oh, that's nothing to worry about. Any halfway decent software engineer who gets fired on Thursday should be able to just waltz into a new job the following Tuesday.

I keep reading that on Hackernews, so it must be true!

No one who works from home has job security in a global market. Plumbers have job security in a global market.

High demand is still providing pretty good job security. I'm fortunate to be in the us and get paid a good bit more than if I was in another country. Many many companies want developers in the us for various safety reasons. If you do work on a generic project that could be done safely by people in other countries of course that reduces your safety.

I think this is the key. Developers in our age range that keep their skills up and keep learning new things can be very productive and an asset on a team. You have to stay humble and admit you still don't know everything.

In my experience (I'm 51 myself), the older the guy, the most likely he's aware he doesn't know everything

And also the more likely they have wisdom that is far more valuable than whatever the flavor-of-the-month tech skill is anyway.

This is ignoring the stereotype of the recent college grad or someone with just a couple of years experience who thinks they know everything. I see everywhere at my work. When you take into account that 90% of software developers of all ages are just not that good at their jobs, things start to make a lot of sense.

+1 in all points, specially in the learning part. Continuous learning is a must IMHO to work in this sector

I’ve had a hard time adjusting to the AWS devops phenomenon. There is so much damn uninteresting configuration and button-pushing, rather than engineering, that I get bored with it. Yet I feel social pressures to get various AWS devops certifications to remain on top of things. Previously used Jenkins successfully for many years so I have devops experience, but there is something about EC2 instances, elastic beanstalk, load balancing, etc at AWS that just makes me want to retire (yet I still get tremendous joy from programming and designing).

Get used to it. Engineers are expensive, so if they can be replaced with button pushers they will be. Learn to push the buttons if you want to stay in the industry. You'll protect your value as an engineer because an engineer who can push buttons is more valuable than an engineer and a button pusher (especially if the company can get away with not paying an increased salary for the increased responsibility, which they usually can).

How is Jenkins not button pushing?

And besides, AWS has a stable API and a set of CLI tools to actually manage everything in the cloud without button pushing.

I am 29 now. Used Jenkins about 5 years ago because I couldn't find a much better alternative for a single-developer workflow, but it's a glorious pile of buttons that has 0 consistency and/or an API.

We manage, install and configure Jenkins as code, without clicking buttons. You can fully automate jenkins activity and setup, from install to job creation, execution, plugin updates, config changes validation etc. Of course only power users will fully use Jenkins power.

Jenkins isn’t really worth the hassle today in my opinion - there are a bunch of new build tools that solve the problem better without all the garbage that comes with it.

And they also look better.

For god’s sake, you could even use GitLab today. What does Jenkins give you? What is there to defend?

For complex pipelines and code reuse (plugins, pipeline libraries, scripting) between projects, Jenkins offers more features for power users, and its maturity has been proven while GitLab CI still suffers from his young age. Other examples with the Cons at the end of this article : https://medium.com/sv-blog/migrating-from-jenkins-to-gitlab-... and https://stackoverflow.com/a/37430097/2309958 (and I can probably find a lot more :-) )

It has a much bigger API than you'd expect, have you even tried to use it? :-)

Yeah. Can you create a user via the API?

First of all, Jenkins was created in 2005, when REST was barely past the stage of being a gleam in Roy Fielding's eye. Yet, almost from the start, almost every page had an API (you'd add /api after the URL for its corresponding HTML page). With XML, JSON and Python (!) formats, with built-in search and filtering.

Secondly, to your point, there you go: https://stackoverflow.com/questions/17716242/creating-user-i... I'm pretty sure that the reason there is no REST API for it is because you're supposed to be using your favorite back-end (LDAP, AD, etc.), with which Jenkins can integrate.

It's quite disingenuous to complain about the Jenkins APIs, there are a lot of them. They're not perfect or designed necessarily like something you'd design in 2020, but they are there.

It is indeed also a pile of buttons.

You can try out Microtica (https://microtica.com), a tool that abstracts the complex cloud setups and provides easy configurations from the UI, so you don't have to spend time on boring stuff and continue the engineering you love. Try it out and let me know what you think.

college professors can get stuff done in their 70s, so should be software engineers as long as they keep learning, both demands a working brain. software is getting complex, experiences matter.

I used to work for motorola, engineers with gray hairs are gems, full of knowledge and always learning new stuff, eager to coach new comers. it unfortunately stopped when outsourcing became a fashion.

I'm old too, I kept learning everyday, delving into c++17 these days, and it just makes my day fulfilling.

I come to HN because it's my access to grey hairs. Unfortunately I haven't ever met a grey hair that really enjoyed coaching.

Coaching and mentoring turns out to be as valuable for the Teacher as it is for the Student. The good ones will take the time to do this - even if the original plan was to shape the thought process of their evil minions. :)

I do. You will.

I'm curious about the attraction phase.

Can you describe what you do/have done on your day job, and what you are doing on your side project to prevent boredom on day job?

I have always worked for product companies, on products that I find interesting. Currently it is a product for margin calls in finance, before it was SMS routing and delivery, before that VoIP. Even if everything I do isn't new or interesting, there is enough variations and challenges, both in the code and also learning more about the domain. The times I have started to feel that it was boring and repetitive, I have changed jobs (but I've stayed at least 5 years in each place).

I also like to try to get better at what I do as a developer. Mostly this is by reading books or taking MOOC courses. I think there is quite a lot to learn about developing SW well (because it is a really complex activity). So that also keeps me interested.

About eight years ago I also started blogging [1] about SW development. I've found that trying to formulate what I think about it has also kept it interesting.

[1] https://henrikwarne.com/

Thanks for sharing. I'm currently doing fullstack web development and find it not as interesting anymore as it used to be (close to 6 years now). I'm trying out various projects but it is either need higher learning curve such as deep Math (i.e., machine learning, graphics) or domain specific knowledge which I usually don't have expertise about.

I guess it is part of the learning.

Reply on news.ycombinator.com