Live data from Hacker News

Programmers: Before you turn 40, get a plan B (2009)

improvingsoftware.com

311–320 of 446 posts

Re: Programmers: Before you turn 40, get a plan B (2009)

#311

Earlier quoted context omitted.

I think a lot of problems some older developers have is that the culture has shifted. Maybe I'm off the mark, but I feel like older devs come from a world where programming was all about programming and it was less a formal career than it is now. To succeed in programming, you have to work well in a business. You can't be Linus Torvalds, walking around with a big ego, unless you're so important it's hard to get rid o…

There's a big difference between being a developer and a programmer. Wrote about it here: http://www.mooreds.com/wordpress/archives/871

In companies that I've worked in, the traits listed would (very roughly) distinguish a junior from senior developer.

There's various ways of describing these levels, but I think programmer/developer is less clear, and seems to suggest programmer almost as a pejorative.

Re: Programmers: Before you turn 40, get a plan B (2009)

#312

Earlier quoted context omitted.

Being a valuable senior developer is about 10% what technology you know and about 90% how good you are at working in a team to solve a business problem with a machine, and those fundamental skills haven’t changed much since 1960. That’s true. But if you haven’t learned that in 10-15 years - there is something wrong. That means the difference between someone with 15 years and 30 years would be marginal.

I'm going to disagree. For every year I've spend doing something, I've got better at it. While there are definitely people with "1 year of experience repeated 30 times", I can't believe that you hit a point in software engineering where there is nothing material left to learn and/or where everything left to learn has marginal benefit.

There are things left to learn, but how many of those things are valuable to an employer who is just wanting yet another software as a service CRUD app, mobile app, or bespoke internal app that will never be seen outside of the company?

Re: Programmers: Before you turn 40, get a plan B (2009)

#313

Earlier quoted context omitted.

I worry the real problem is not that managers are looking for someone who can do the job, but someone they can exploit. The gleeful exuberance over 'new' things is something you can use against a younger programmer. The older one who knows the vintages doesn't get as excited, because it's really not that exciting. You haven't discovered Shangri La. We've kinda already done 90% of this before, just maybe not all at th…

Maybe the problem is the big tech producers that introduce new technologies over and over, that don't raise productivity but create churn, force software rewrites, etc. Tech history looked at from 40yr perspective, really seems like reinventing wheels over and over. I'm not sure if there is another industry with so much churn yet with a lot of rehashing of old ideas.

"It used to be the case that people were admonished to "not re-invent the wheel". We now live in an age that spends a lot of time "reinventing the flat tire!""

Alan Kay AMA: https://news.ycombinator.com/item?id=11941199

Re: Programmers: Before you turn 40, get a plan B (2009)

#314
post #46

I'm not sure I'm buying that. The JVM ? Still rocking it 20 years after. Memory allocations pattern ? Still there. The network stack ? Well, doesn't seem to have changed a lot. The older guys, they seem like they had the time to correctly learn the unix network tools, the jvm debugging ones, the memory inspection ones. I've known older devs for which I have the utmost respect because I felt like they can just debug t…

The javascript ecosystem however... The entire stack literally (for the actual meaning of literally) change completely every year. Frameworks, language, package manager, libraries, etc.

Ecosystem, sure, but I am still using the JavaScript I learned x years ago when I need to see how something is implemented in Angular or React under the hood, etc.

Re: Programmers: Before you turn 40, get a plan B (2009)

#315

Firstly I am a proponent of the idea of software as a new form of literacy - it is eating the world and as such if you are literate you run rings round the illiterate - no matter what your age. But companies are pyramids - and some roles (like sales) mean their value to the company can be measured on an individual basis. But most roles cannot - and the further away from the customer you are the more it is true As suc…

This is why you need to have Senior and Principal engineering roles. As a programmer or operations engineer you should be able to choose between a management or engineering track for advancement.

The managers work as an interface between the management hierarchy and the individual contributors.

The top engineers work across teams to steer technical solutions and provide cross team focus and continuity. Your principal engineers are charged with breaking down the silos and sharing and setting technical standards and encouraging the reuse of existing services and systems.

Tech managers and team leads don't have time to do the technical leadership and work properly with business. Workplaces without this structure invariably fail to have well articulated, cross team technical decision making capabilities. Everything winds up fragmented and reimplemented.

Re: Programmers: Before you turn 40, get a plan B (2009)

#316
post #241

Earlier quoted context omitted.

Yes. But as the article said, there is a diminishing amount of value after every year of true experience after a number of years. I would say around 10. I definitely don’t believe in the “10x Engineer” (individual contributor) - yes they do exist but are so rare they aren’t worth talking about. I do believe in being a force multiplier as a team lead/mentor.

> But as the article said, there is a diminishing amount of value after every year of true experience after a number of years. I would say around 10. I don't buy it. 10 years is about when you start moving into the actual expert category. Note I said start . At 35, I finally had real, full control over multiple languages, could pick up CLR and understand and implement any algorithm in it, finally understood exactly w…

At 35, I finally had real, full control over multiple languages, could pick up CLR and understand and implement any algorithm in it, finally understood exactly why concurrency was so damn hard and how to mitigate that, and would pass practically every interview with flying colors. I could finally drive my tools with some facility and started to realize gdb was my friend.

You may be an expert in multiple languages but as the article said, if the company is looking for Ruby developers to write a CRUD app, they no more care that I spent years doing C than they do the years I spent doing 65C02 assembly in the 80s.

No matter how many subdomains you are an expert in, if the company doesn’t need that experience, it doesn’t matter.

Re: Programmers: Before you turn 40, get a plan B (2009)

#317
Maybe some folks here will find my perspective informative, speaking as someone who made the transition from individual contributor to engineering manager around the age of 40.

I've worked at big companies since I graduated college. As a software engineer, I remained hyper-focused on specializing in pretty much one specific thing. I've never considered myself particularly brilliant in comparison with some of my peers, but the thing I chose to specialize in just so happened to become super-important to the technology sector about five to seven years ago. I was in the right place at the right time. I cleared my calendar for about half a year, shut out the world, and focused entirely on embodying all the expertise I had accumulated up until then into a new feature.

Now the thing I created is a critical feature in the phone you probably have in your pocket right now. As in, if I hadn't created the feature, it's very likely that a team would have been spun up in a company like Google or Samsung to create it instead.

This catapulted me into a relatively senior position, and then I found that my hyper-specialization couldn't keep me competitive among my more capable and more generalist individual contributor peers. I got to my position by pulling a rabbit out of a hat at a critical point in time, and then I (proverbially) got promoted to my level of incompetence. I can't possibly keep delivering the same super-high impact on a continual basis.

Shortly after I got promoted, my organization started to grow very quickly. Upper management was scrambling to build levels of hierarchy to absorb the growth, and they pretty much pushed me into managing a team in addition to working on some of the residuals of the technology I had built. I soon realized that I didn't have the capacity to continue designing systems and writing code while effectively managing people at the same time. I felt that I had to make a choice: Either give up management and focus on individual contributor work, or make the switch entirely into management.

Of course I had formed for myself a false dichotomy. I could always go into consulting, switch career ladders to sales or product management, or something else along those lines. But getting a taste, I was finding that I liked management. Politics started becoming less of a dirty word for me, and I felt fulfilled and useful when I successfully negotiated a mutually beneficial compromise among parties in the organization. I loved figuring out what my reports needed and helping them to achieve their goals. I loved that I could hack some code here and there and not worry at all about whether it ended up shipping in the near future, since my impact was not being evaluated by that metric any more.

And so now, a little bit past 40, I am 100% an engineering manager. It's something that I just sort of grew into, but at the same time it feels sort of inevitable if I am to stay at my current company. At my level of seniority, upper management would only be happy with me going back to an individual contributor role if I were to pull more rabbits out of hats. I suppose I've accepted that those days are probably behind me, and I'm ready for the next set of challenges.

Re: Programmers: Before you turn 40, get a plan B (2009)

#318
post #11

What are some common Plan Bs?

Shouldn't that be "Plans B"?

I believe "plan b" is a head first compound noun, and should pluralize like "hangers on", "mothers in law", or "attorneys general".

But I could be wrong. The plural form doesn't get much usage.

Re: Programmers: Before you turn 40, get a plan B (2009)

#319
post #195

Earlier quoted context omitted.

Yes. But as the article said, there is a diminishing amount of value after every year of true experience after a number of years. I would say around 10. I definitely don’t believe in the “10x Engineer” (individual contributor) - yes they do exist but are so rare they aren’t worth talking about. I do believe in being a force multiplier as a team lead/mentor.

On the one hand, sure, percentage-wise you learn less in year 20 than in year 10, because you already know a lot more in year 19. But that is no more true of this field than any other field. Is a doctor, architect, civil engineer, or auto mechanic with 20 years experience more valuable than one with 10 years experience? Heck yes.

20 years ago,much of what I used today didn't existed there was no AWS, no C# (but C++ was close enough I guess), mobile where you had to worry about semi-connected networks and syncing, etc. There is no part of the human body that exists today that didn't exist 20 years ago.

Re: Programmers: Before you turn 40, get a plan B (2009)

#320
post #46

I'm not sure I'm buying that. The JVM ? Still rocking it 20 years after. Memory allocations pattern ? Still there. The network stack ? Well, doesn't seem to have changed a lot. The older guys, they seem like they had the time to correctly learn the unix network tools, the jvm debugging ones, the memory inspection ones. I've known older devs for which I have the utmost respect because I felt like they can just debug t…

> Observables are all the hype in javascript ? Well, great, I've learnt that pattern 15 years ago... Well, the listener/observer pattern is used to explain observables in order to make them familiar, but no, it's not the same thing. Observables are streams and you work with them the via composition of streams. When viewed from that high level, the underlying protocol (the observer) becomes irrelevant and in fact, if…

Well, it was my obvservation reading typescript code (never wrote a line in this language) with a background from java and then c# and then scala. The observables part felt really easy even without knowing the language syntax, but I suppose that the past 4 years of scala made me instantly translate the code in functional fashion and it was all smooth.

On the other, while it's wrapped differently, the whole idea of "this object will start emitting events, and we will be having functions as callback on them defined in various objects" really feels a lot like good old java observables/listeners, even if it's applied with a different paradigm. The stream part really feels like an implementation detail to me, it's just less boilerplate than before.

Then again, it was just an anecdote based on reading code in a language I don't use ^^ javascript and typescript aren't even mentioned on my resume, for good reasons, so I should be safe in interviews !

Post reply on HN