>The surprising costs of a mid-career break involve falling far enough behind industry trends and methods, that it would be faster to train a new person than retrain you.

In programming -- and, I think, perhaps in most industries -- more people fall behind in learning because of their job than because they're out of the daily grind. Any large-scale enterprise is chock-full of devs who have plenty of experience developing inside Websphere, Liferay, Sitecore and so on, but who haven't had the time between work, family and sleep to gain knowledge and experience in SPA development, CI, CD, microservices, and so on, let alone more outre topics like ML or NLP. Giving knowledge workers the opportunity to sabbatical out and build new expertise would benefit both them and their employers.

Except if their employers need people maintaining the legacy systems using the legacy technology. Then having people there who know nothing else is highly beneficial, since they're unlikely to quit.

> When an organization can operate without your presence for over 300 days, your role may not be very necessary.

Which is a good thing. Everyone should be replaceable in corporate jobs, maybe not a startup, which makes sense. If you're not replaceable then your business is not doing the best it can to future proof itself.

I try to find my replacement actually, I take the interns and coops in every meeting as well as CC them on all emails. I do not see myself in the same job for my entire career, what better bargaining tool to move up than say you have your replacement ready?

People skills have a much longer half-life than, say, proficiency in the latest javascript framework or machine learning trend.

That's the absurdity of modern business in many places. Short term, stupid thinking.

I'm glad to work for an employer with more enlightened work rules. When I had my back surgery, I was out for nearly 6 months. We had about a weeks notice, and my #2 person was able to take things on and I was able to transition most projects to her. Everything went fine. Actually it was a great thing because my fill-in's talents became apparent in my absence, and she got promoted later as a result.

Any workplace that changes so quickly that an above average player is totally out of touch in <1 year, the place is a shitshow.

If you work somewhere with such turnover that your knowledge is useless in 300 days... should you?

I tend to believe the rate of change in programming is grossly overstated anyhow, but that takes it to truly absurd levels.

True. I did a year of sys administration, and when I got back I realized I had missed that year's JS frameworks du jure. Panicked, I began learning everything I could about Bower, Grunt, Angular JS 1, and Mongo.

I lucked out, though, because the team decided these technologies were woefully outdated, and we were to migrate to Gulp, React, and Postgres.

Unfortunately, end of this year, and these have been eclipsed by Angular 2, JSPM, etc.

I think you mixed up "du jour" and "de jure" there.

It does suggest, however, both "de jure du jour" and "du jour de jure".

It may not come from an individual, but there is certainly an element of the JS community that seems to operate de jure. Frameworks are "the next hot thing" before they've hardly shipped a production site of any consequence, let alone shown the ability to improve things across a large array of sites, or had time for the negatives to be shaken out. Or a "next hot thing" ships one massive site like Facebook or something and it's the "next hot thing" before anybody can realize that they aren't Facebook and don't have three hundred dedicated front end developers themselves, and it's way less clear the NHT will work for two guys in a closet working on a startup.

Wouldn't that be de facto? De jure would mean there is some kind of law. I feel we have the opposite, quickly shifting de facto standards without any place to reference what is "correct" today.

I'm using de jure to contrast the de facto; I think frameworks are the "next big thing" before they're even fact. That Javascript Guy comes up to you, asks you what you're using, and then berates you for not using Hot New Thing, de jure-ing you into using it, or at least feeling bad for not using it.

Part of the way I've resisted being sucked into the JS vortex over the past few years is that I thoroughly reject the authoritative claims that I should be using X or Y, on the grounds that I don't particularly respect the technical judgment of the people making those claims. (And check that last clause carefully; all the Next Big Things are generally engineered pretty well, it's the advocates berating you for not keeping up to date that I'm dissing.)

What's the longest break you've taken from working? You might be surprised how little actually changes in the course of 6-12 months, once you get past the obvious surface changes. The perspective that can be gained from stepping away for more than two weeks can be invaluable.

Mostly it's projects that were "90%" done, expected to compete in a few weeks are now "had some unexpected complications, but we're past those now."

In most companies nothing of substance changes over the course of a year. You won't fall behind trends and methods. It's like not reading the news for a year. You miss a lot of noise but the substance doesn't change.

> When an organization can operate without your presence for over 300 days, your role may not be very necessary.

For an alternative view: When an organization can't operate without your presence in that role, how can they consider promoting you out of that role?

I've seen people stall their careers by becoming the only person able to cover a particular role. I personally fell into this trap for a couple of years.

In hindsight, feeling like they couldn't do without me for a week or two for a holiday was a huge red flag. Since then, I've been conscious and cautious of this, and actively planned to avoid it.

Anything I feel I'm the only one who can cover, I make a point to properly document the process, have someone shadow me the next time I need to do it, and eventually perform the process themselves while I supervise.

If you are not replaceable, you are not promotable.

> If you are not replaceable, you are not promotable.

Not accurate. You can be promoted and take on additional responsibilities and/or title.

I've learned mostly the opposite. Those that become indispensable rarely get promoted because moving them would create a huge gap in a necessary role. At best, these engineers are rewarded with 'pseudo promotions' like team lead or lead of two projects - with no pay increase or perks, just more people to manage, PowerPoints to create, weekly status meetings to attend, etc.

Playing politics, dressing better, getting in shape (opposite of the typical hoody-ed neck beard) and befriending those above you, while learning a little bit of lots of business facets, is the path to real promotions.

RE: 300 days.

Not always true, I took 6 month break from a large consulting firm - they have thousands of consultants so you can take a break without killing the company but obviously they want as many consultants billing hours as possible.

I'd be really interested to learn about companies that replace their entire codebase twice a year. That seems amazing.

while they may not be changing their codebase twice a year, code can evolve enough to be hard to recognize, especially in big, intermingled (i.e: poor) codebases which interact with other systems (can someone say microservices?)

Small things change here and there and suddenly you don't understand the beast.

Granted, this is not a general case, but do not underestimate several months work by a team of people.

Eh, there's so much thought built into getting code into production. Things like logging, monitoring, service discovery, orchestration, rollback, authentication, authorization. Couple that with all the other stuff for just coding, formatting style, testing standards, code reviews, version control patterns, allocation of tickets. Then sprinkle in some institutional awareness of who's responsible or who can answer questions about system interaction, connecting to databases, sending email, creating new users.

I'm skeptical that all of that changes often enough to make a rehire less valuable than a new person. Sure, you may have switched to k8s from docker. In that kind of environment, can you really get a new person really productive in less than 6 months? And with the new person, you're never really sure they're actually capable of doing the work, until they do the work.

Ok, sure, if the potential rehire wasn't all that great, it's probably worth rolling the dice. But if they can point to a few successful projects, why not rehire? You know they're a cultural fit. They accept however dysfunctional the organization is, and tolerated it well enough to want to come back. Plus they know a bunch about how to actually get things done in your particular structure.

this isn't reddit...