The fundamental rule of career progression in the technology industry is to position yourself as a domain expert in something more specific than "programming".

It's very difficult to "own" "programming" in a way where you can use scarcity to drive integer multiple increases of the median salary. It is not as difficult to "own" distributed systems, sensor fusion, software security, or OS kernels.

As a general rule, the people getting outlandish half-mil-a-year offers from big tech companies are domain experts, and the people on Twitter shocked and upset that they're never seeing these offers are either (a) generalists or (b) people who have chosen to specialize on the craft of programming, rather than a domain to which programming can be applied.

That's not a value judgement! There are a lot of ways in which refining a true engineering discipline for assembling software is harder than kernel development or fast computer vision processing. It's just a statement about supply and demand, and about ease of demonstrating value.

Also I've noticed a lot of sub-fields like computer vision or self driving cars where there's a great deal of nerd interest but very little actual employment.

In fact, I have a feeling that computer programming is the stick that's holding the entire STEM tent up---if not for programming as a consolation prize you'd have a whole lot of physics and chemical engineers making lattes at starbucks---and further that web development is the stick that's holding the programming tent up.

I just used to say I am a computer vision expert, because in the ton of things I can do, this is a relevant domain.

Recently, advances in deep learning made half of the computer vision field obsolete. I just read some cutting edge DL papers, linked that to the things I know, and now I am a deep learning integrator.

I was taught in engineering school that my craft is learning and problems solving. I sell it as knowledge and expertise but the truth is that I am constantly learning in the domain I sell as my specialty, which is what everyone who is decent at anything actually does.

I'm strongly convinced that the less (nerd) sexy a field is, the more money there is in it for a good programmer.

The crappy programmer working conditions in the gaming industry is one example supporting this theory.

I swear, I repeat this comment in almost every news article posted about how "We need more STEM graduates" and "The STEM job market is super hot right now".

Yeah, programming is. I know so many graduates of a BS in math, physics, chemistry, biology, ecology that just couldn't find satisfactory employment. They either got a second, mostly unrelated degree (in management or something more industrial) or are working at a mostly unrelated job.

Even in traditional engineering disciplines, while it's easier to get at least OK employment the demand just doesn't seem that strong compared to CS. I have many friends that graduated with civil, mechanical, or chemical engineering degrees (in at least one case, an MS) who are vastly overqualified for their lab tech or drafter positions.

I have a strong background in mech engineering and robotics. Yet, for the two years I worked in that domain, I never had a single recruiter contact me out of the blue. Now, my mostly amateur computer skills somehow landed me a "tech" (read: IT) job. In the 2 months since I've changed my current title on linkedin, I've had 3 recruiters contact me.

I think this goes back to being an expert in a "domain". Being able to apply programming to that domain is far more valuable.

* I have a bachelors in electrical engineering from a top ranked school.

The future will be a new snazzy term. Same job, different title.

Software development is not engineering.

That is part of the reason for the high pay. There is always risk associated with specialization. You can't become an expert without specializing in something, but if you specialize in the wrong thing your effort may not be rewarded.

That might be the reason people demand higher pay, but it wouldn't be the reason why companies pay the higher pay. They pay it because there's a scarcity of people, and/or because they get some multipled value back. No company cares if I've specialized in the 'wrong thing' - they just won't hire me.

It's the classic example of complaining that there are no jobs, while the industry complains that there aren't enough talented people. I get a few recruiters pinging me weekly and I'm not looking to move jobs - their story is always that there is a huge demand for good people.

I think the CV job market is unlikely to get much better, at least in terms of numbers of positions available. On the other hand, it's a stable job market that isn't going anywhere. The pay is already above average and it's not likely to go down because of the experience required. There's no shortage of applications and it's not dependent on a particular language, toolset or hardware. Virtually every big factory in the world employs some kind of machine vision system, for instance. And pretty much every computer vision deployment has to be modified for the application.

There are much easier ways to make money though. If you want to be a wealthy programmer, get on the web/app development train and accept that you might need to pivot every couple of years.

It's a little ironic to hear talk like this, since around here I hear a lot of "sorry your coal mining job is going away, but you need to get with the times and train for something relevant". Same thing applies here. If you pick a programming specialization that eventually falls out of favor, buck up and learn a new one. Maybe that'll mean a pay cut for a bit as you ramp up, but that's just how it works.

It's a different story, I guess, if you go into a completely different type of programming from what you're used to (say Web apps to embedded programming), but I don't think that's necessarily easy.

Important difference.

For example, at one extreme, all tech lasts exactly three years; at one of several other extremes, 50% of tech is eternal and the rest lasts exactly 1.5 years.

My philosophy is that if PHP keeps the lights on, I better really know what it is, where it's going, what are it's limitations, because it would be pretty scary not to.

Plus once you learn a language or a database well, the next one is easier. The trick is knowing when it's time for the next one.

Don't mistake what I'm saying. I'm using the word "own" rhetorically. Obviously there will be no point in your career where you are likely to be the world's leading expert on computer vision. What you're aiming for is to be the leading expert that is available to employers within a reasonable amount of time at the level of compensation you're hoping for.

It's a spectrum.

Obviously, if you invest heavily in a discipline and it is decisively obsoleted, that's a setback. I'm just saying it's not an insurmountable setback, and I'll add here that it's still unlikely to leave you behind the pure generalists; in the process of building expertise and accomplishment in cryptography or OS kernels or whatever, you're likely to become a pretty far above-average software developer as well.

But the few people who are really hiring people who "own" CV want PHDs with a relevant thesis and you're not going to get one of those working weeknights after the kids go to bed.

Meanwhile people pursuing PHDs have no idea if their area of research is going to be hot in industry when they're done.

Granted, a lucky few people who follow the autodidactical route may find themselves authors of a really popular OSS project. Or they may be able to luck or maneuver themselves into a position at their current employer working in a capacity that future employers will see as "relevant industry experience." Obviously this is hardly a sure thing and if they plan it wrong or just get unlucky they're not going to have a nice outcome.

There are so, so many businesses out there that could benefit from CV, but they don't realize it. Maybe they're spending a ton of money on off the shelf OCR software that isn't great for their needs. Maybe they're spending a few hundred thousand dollars a year manually organizing and classifying documents when they could automate it.

These companies won't be hiring someone to own CV for them, because they don't know they need it. They might not even know what computer vision is. And they won't care about whether you have a PhD or a relevant thesis. They'll care about whether can can demonstrate that you can solve their problems and save them a pile on money.

Granted, finding companies with these types of problems is perhaps not something that a typical LOB programmer knows how to approach. And if they see themselves as just a LOB programmer, it might stay like this.

If they make an effort to get to know people and network outside of the usual tech circles, they might just find it possible to position themselves as solvers of specific types of problems - problems to which CV happens to be the best solution.

I know that's not a path that'll work for everyone. But it's one path that leads from 'LOB Programmer' to 'Someone who makes lots of money doing development with computer vision'.

As a counterexample, though, most serious work in cryptography (for instance) is done by grad students, but the best jobs in crypto are not automatically going to grad students.

Either way: if your goal is to maximize lifetime earnings, I think dedicating your career to "programming" is a bad call.

My point isn't that becoming a subject matter expert isn't a good way to supercharge your earnings for a few years. I agree with you there.

Clearly, a guy with lots of experience with and deep knowledge of the Oracle database could do pretty well for himself 10 years ago. A person with lots of experience with and deep knowledge of OpenStack could do the same five years ago.

My point is that it's not a good, safe or stable way to ride out the last half of a 30+ year long career.

My further point is that demand for lots of these specialists doesn't appear to be particularly elastic, and therefore "become a subject matter expert" is not a universally applicable bit of career advice for every LOB engineer worried about ageism: if everyone successfully took your advice there would be a whole bunch of unemployed crypto experts.

It's not my claim that simply by moving to a specialized subfield of programming that you'll instantly quadruple your salary and future-proof your career.

Obviously, you're going to start in some domain speciality as a commoditized practitioner and, with effort, move yourself to more elite ranks of that subfield.

My point is that it is better to work on that problem --- of being an elite in a specific domain --- than it is to be an elite at the general problem of building reliable software.

(It's "Burp", by the way.)

A guy with lots of experience and deep knowledge of databases in general, though, would do pretty well for himself both 10 years ago, and today. Even better if he worked on some database himself. Really, that's what owning a domain means: you don't want 10 years of experience as a _user_ of some technology, you want that experience as a _builder_ of said technology.

Are you sure about that? I mean sure, if we're talking someone who wants a deep learning research project to improve the metric for recognizing human faces from 99.7% to 99.78%, then we're talking about PHDs.

But there are plenty of "simpler" problems that one can work on, and plenty of more engineering-oriented problems that one can work on. Lots of companies just need to apply semi-standard techniques to problems that are specific to their business, and nothing more complicated or research-y.

(Being a PL design & implementation expert --- not "having very good taste in PLs"! --- seems like a defensible position in the market, except perhaps that there are a lot of people who want to work on compilers and you're competing with a healthy pipeline of them.)

In "flyover country" and the midsize college town I quite enjoy living in, indeed currently returns only a handful of BI-related postings for search terms like data analyst. Web developer returns tens of postings.

I'm not sure every programmer should start with trying to specialize in a domain. But definitely, at some point, you're reaching diminishing returns for getting better at programming.

Put another way: Getting better at the craft of programming allows you to write programs faster and better. Specializing in new domains allows you to do things you couldn't otherwise. This is the realization that made me decide to stop learning new programming languages, and instead spend my time learning new domains - I realized that learning Haskell, while incredibly fun and rewarding to my abilities as a programmer, will not let me make fundamentally different things than with Python. Learning e.g. Deep Learning, however, would.

Btw - even learning totally other skills - e.g. learning 3d modeling helps me a lot in gaining deeper knowledge of 3d than I would otherwise have - even if it's not 3d programming per se, it's still relevant. And learning new Maths is not as directly applicable or as valuable as learning new software domains, but can open up new avenues you wouldn't otherwise have, that learning "yet more programming languages" or similar won't. (It's still more valuable to work directly on relevant things, of course, but sometimes it's fun to broaden your scope in relevant ways.)

I've never used Python, but I like Haskell for the kinds of problems where I'm trying to do something complicated and a little confusing, and I want the compiler to let me know if I've asked it to do something that doesn't make sense. That sort of thing can save a lot of time in the long run, and I usually feel good that the resulting software is reasonably robust. I expect a good Python programmer could write an equivalent program, it's just not the way I like to work.

Libraries are of course often a deciding factor, and so are performance requirements.

It takes some esoteric innovative features to make a difference, but that will also cut both ways; it'll make it harder to hire for and scale, too.

I'm a pretty capable "generalist software engineer", but what keeps me employed is expertise in virtualization and high-performance virtual networking. Prior to that, it was expertise in distributed systems and a knack for debugging distributed failures. The history here is relevant: later in the thread Thomas points out that you can switch domains. My time spent in distributed systems with multi-millisecond quorum periods is more or less directly applicable to debugging synchronization issues at CPU clock speeds. The tools used to observe the issue are different, but the reasoning process for untangling the set of plausible partial orderings is the same.

Specialize in something valuable. Continuously evaluate the next most valuable skill to acquire based on where you are and where you want to be.

There's a pretty common trend in GameDev -> Embedded Systems | High-Speed Trading.

The skillsets are very similar while the domains are quite different.

Not everyone's a climber, and being in "a dead-end job" isn't really a bad thing if you're not ambitious.

I'd just like to spread the message that it is absolutely OK to plateau. You don't need to be a renowned domain expert, you don't need to go into management, you don't need to start your own company... if you're happy where you are, don't sweat it.

Not saying this will definitely happen, but it's a risk, and you don't need to be a ladder-climber to protect against it.

I think most people would probably do better if they just stopped allowing their expenses to grow with their income, and saved and invested more, both in equities and in forms of passive income (like rental real estate). That way, not only are you insulated from shifts in the industry around your primary employment, but you can also probably retire early.

To me, the real perk of working in tech is not that there are so many jobs that I can find one that pays incredibly well; it's that I can find one that pays nicely but aside from that has some other perks.

A lot of friends and workmates have told me that I could be working in a better paying place. After looking into quite a few job offers, my conclusion is that for now I'll stay in my 8-to-4 job that pays me twice as much as the average in my area (average in the sense of all the population, not just tech jobs, obviously). I used to have a high-paying, high-stress job; I don't want to go back to that, it's not worth the money.

I must add that I'm EU-based. I understand that in the US, with much less of a safety net, maybe optimizing for money is a more attractive idea. I can't really say for sure.

For example: I've spent a large chunk of my free time over the last few months learning how to typeset signs in fansubs and make them look good, something that has no economic utility whatsoever, but makes me really happy when I typeset something that looks good. Yeah, sure, I could have spent that time furthering my career by developing a marketable tech skill, writing tools for my company on my own time to impress management, or writing an open-source piece of software to pad my GitHub portfolio, but I'd rather do something fun for myself than do any of those.

The problem in software development that current way how company financing is set up is that you do not need domain expert to make it.

In other words, it is nearly impossible to be hired as domain expert because very small number of startups needs one: just do some "growth hacking", get to YC, and raise money. Maybe founders need to domain expert to get to YC but they you will kick him or her out as soon as they get "YC stamp".

And this is reason why there is no database experts in all these new database startups, there is no security experts in security startups, nobody can figure out to make even half decent Dropbox clone, etc. The list goes on.

And there is also ageism: all "domain experts" are 30 something.

Some people get to this point and never step back on the gas, because it seems like things are going to be great forever. Once people get too comfortable, it's only a matter of time until it bites them.

IMO it's important to continually reinvent yourself throughout your career, to keep things interesting, but also to always put you in the best position to take whatever the next step is. If you wait until it's time to take that next step before figuring out where you want to go, it's too late.

But I don't agree that having constant side projects and learning the new cool language/framework du jour is necessarily valuable.

I think that there's just too many technologies out there, moving too fast, to be proficient in a significant fraction of them, even if you invest all your time in learning them.

I think there's more value in learning how to do engineering well in one language than learning how to do basic stuff in 20 of them. Because the skills and knowledge of going deeper transfer much better than knowing syntax, etc - stuff you can always pick up for the next job once you know what it is.

Is it a rule, though? I hope not. I'm a 40-year-old generalist, and so far I haven't had problems finding work. Sure, I'm not going to get a half-mil offer from anyone, but that was never the case at any age.

i've been wondering if i should pick up something entirely different on the side (e.g. machine learning for broad applicability, though that does not excite me at all), or to instead diversify from my current niche but learn to write tools across a broader variety of languages and ecosystems. it's scary sometimes how the entire programming ecosystem can change overnight and leave once-valuable skills in the dust.

Some fields might be locked up by postgrads (crypto engineering is not one of them, and I doubt language tooling is either). You should check before you invest too much in it. But I would advise against being spooked by academic credentials. Good places to work care more about conversance than credentials, and you get to draft off of all the research work the academics publish before moving into industry to compete with you.

I've been in this industry since copper and telco was hot shit.. I went from doing Telco programming > IT > Web Development > scalable enterprise applications.

Why bother stressing over something you have no control over? Do what you love and the money follows.

i do have some hope that i've gotten into my current niche (static type inference for dynamic languages) reasonably early in its life cycle, but if i'm wrong i don't want to have not kept up with the larger world at least to some extent.

(to be precise, i'm not so much worried about being able to transition my skills to something else, as about not being given a chance to do so unless i can already demonstrate the new skillset people are looking for.)

I vehemently disagree with this. Kludging together an unmaintainable codebase that barely meets the spec might be easy. Aiming for a notably higher level quality beyond that is NOT an easy thing at all.

Obviously, the nature of this discussion depends on the complexity of the task at hand. There are many profitable ventures with low levels of complexity in the software implementation, and your comment may hold true for such scenarios.

However, there also many ventures that require significantly complex software to meet their goals, and will require skilled developers to have any hope of not collapsing under the weight of shoddy implementations and impenetrable abstractions.

On one of my previous jobs one problem domain was some area of theoretical physics. There was a guy with brilliant understanding of the problem domain. He had couple of decades of experience teaching physics in the country’s best university. He could explain very hard problems in easy to understand way. The company filed multiple patents with the amazing stuff he invented.

It didn’t help the guy to write code. It wasn’t good. Not only unmaintainable, also slow and unstable (not all algorithms work equally well when mathematically-real numbers are substituted by software-real IEEE754 floats). We ended up just throwing out whatever he coded, and instead learned enough problem domain from him to be able to understand and implement what he actually was trying to do.

Developing transferrable strategic and architectural skills between verticals (client facing, or technologies) is a key aspect that I see being missed with programmers.

No framework will make or keep your career, nor will a specific language or piece of tech. Knowing how to apply technology well, in a way that doesn't need to be entirely thrown away every 2-3 years is invaluable, and as a result increases a developers value.

Mobile app development is becoming quite clear cut, one only needs to read the docs and know the APIs.

I used to know this guy who knew the ins and outs of the health club industry, and he could program a little. He made a lot of money. I think this is more in line with what tptacek is describing.

Being an expert in iOS is more than just knowing how to program in Swift/Objective-C. It encompasses a deeper understanding of mobile development and the apple ecosystem.

True senior level iOS people will understand core user interface design principles as they relate to mobile, and will be intimately aware of Apple's Human Interface Guidelines. They'll understand mobile accessibility and be deeply familiar with the myriad of tools in iOS. They'll understand internationalization and how to design an application to support various calendar systems, and text layout paradigms. They know the ins-and-outs of Apple's provisioning and certificate system and can quickly sniff out configuration issues. They understand how important testing is and how well supported it is. They know how to setup automated builds using xcodebuild, and how to support automatic unit and ui tests.

The list goes on and on. Certainly one could just be an app developer and stop there. But being a mobile domain expert in my opinion is a much more valuable albeit niche position.

It's better to be good at mobile than to be good at nothing at all, sure. But I'd be really careful about picking a specialty that amounts to "my domain of expertise is AppKit", or "my domain of expertise is Scala", or anything like that.

You could claim that software security is "just programming" for instance... But you likely wouldn't, because it requires a level of understanding that is especially deep, and niche. It doesn't really matter that a security expert likely reads a ton of code, and writes some too, it's that they understand a subset of the industry to a high enough degree that they stand out among their peers.

I propose that you can be a mobile expert, just as you could be a VR expert for example. At the end of the day it's more then just programming, it's a combination of hardware / software / tools that retains a degree of uniqueness.

Yes: you can specialize in being a really good programmer for a particular platform. I have a lot of friends who specialize in being Serious Engineers, who understand how to get interesting and important things done with lenses and how to effectively get a whole project away from null pointers and into monadic error checking and how to use type systems to prove programs mostly correct as they're being written.

That is a real specialty. It takes real skill and investment of time to get to the point of being expert with that stuff. I'm not diminishing the value of being an expert software developer.

I'm just saying that basket of specialties is unlikely to command a very high wage premium, not because it's unspecialized, but because it's hard to fashion a value proposition for it relative to your competition in the market.

There will be times during which particular platforms or languages will get hot, and it'll be good to be expert with them. But (a) those phenomenon will be more transient than other problem domains, and (b) the wage premium for being specialized in them will still probably be lower than the wage premiums for the other domains.

At any rate: as long as you're thinking about the domains you're specializing in and not a career as a "programmer" or a "builder of software", we can probably agree to disagree about the rest of the details.

I agree with this entirely. But it makes me realize that perhaps I haven't explained my position well.

I would agree that being a mobile expert is likely going to be LESS lucrative than being, say, an expert in recombinant DNA technology with a fluent C++ background and a PHD in machine learning.

The only issue I see with advising people to invest tons of time and money into niche fields, is exactly what others have pointed out in this thread - You can't really predict what's going to be valuable in 10 years.

So take your pick - Go the safe route and become an expert in a more general field like, for example, mobile. Or pick something incredibly niche, which will shrink your competitor pool and increase your relative value proposition. A classic risk/reward scenario if I've ever seen one.

I don't think this is all that safe, really. What we consider "mobile" development has really only been around for about a decade with the releases of iOS and Android. (Sure, there were mobile platforms before that, but most people didn't really care about them, and specializing in them would likely limit your options, not expand them.) In that time, mobile development has gotten nothing if not easier. So, over time, being a "mobile dev" will become less and less of an important specialization. More people will do it, and the frameworks around it (both those released by Apple/Google, and third-party things on top of it), will make it easier and easier. By that point you might be an "elite" mobile developer who can do certain things on mobile that most others cannot, but the market for that level of specialization will likely also be small.

To make matters worse, developers will disagree with each other about what the Right Answers are for a given platform or language or engineering approach.

Cryptographers (as a counterexample) also disagree with each other about the Right Answers in crypto. But serious crypto people are generally competing for jobs only against other serious crypto people, and there aren't that many of them.

Moreover, the general domain of cryptography isn't going anywhere. But look at Objective C, or Windows Mobile.

Finally, proving value as a subject matter expert on a language or platform depends on companies having hiring processes that reliably spot expertise. But, of course, hiring processes do a terrible job at that.

Management: I would argue that it's critical to garner management skills well before you turn 40. If you wait until 50, you're going to find it very difficult to move from talent-oriented jobs to management ones.

Coding: I hate to generalize, but it's very likely you'll learn so much over your career that you will become an ineffective developer. You will know how to do things well and will have a difficult time doing things just to get them done. It's fairly common for projects to need completion over correctness and quality. This is where younger developers are great. They don't know they're creating technical debt, so they have no angst over it. But you will and this is bad for the project and for you. You probably need to find a place in software development where you can mentor and lead, but reduce your involvement with actual day-to-day coding.

Challenges: I personally suffer from "it-must-be-challenging-or-I-get-bored" syndrome. The longer you write code, the harder this is to suppress and the more you look for shiny things to work on. This is bad for you because it's bad for your employer. If you don't suffer from this, you're amazing and any employer would love to keep you until you're dead.

And then you will learn to be pragmatic and solve technical debt only when there is enough time for it or when it brings a clear benefit in terms of business value or development speed.

I can tell this from my own experience. As a developer you typically progress along a path; in the beginning you just don't know how to do things 'well' so you're introducing technical debt without knowing it. Then you'll learn about clean code, design patterns and what not, and you think you have to apply this knowledge everywhere. Until you learn that there are times to be pragmatic as well.

This pattern is not unique to programming, it's universal. See for instance https://en.wikipedia.org/wiki/Shuhari

I disagree: it is when you are young that:

* you spend and lose your time reinventing the wheel, either because you don't know the wheel you want already exists, or because you are sure you can do a better wheel (and after an extra 3 months it ends up being square);

* lose time overdesigning things because you want to apply all your lessons and your new readings, despite the fact that they do not map to the problem you need to solve.

So I have to ask - how do you do the management portion of that? Getting into it, I mean, more than just developing the skills or interest.

I've been trying to get into the management side of things but get stymied over and over, and typically people who express disinterest (and no particular aptitude) keep getting chosen to do it. This has had a tendency to wind up with most of the people involved (except the person who gave the promotion) quitting, and it's really frustrating to watch it play out again and again.

I suppose in one case I did get promoted to lead, but I was lead of nothing, because literally everyone else had quit.

The point is I want to move - badly - in that direction, and see lots of opportunity to do lots of things there, but keep getting stymied. How can I get past that?

The person who was selected as lead left a month later, since they weren't that interested in doing it anyway. The powers that be still didn't let me lead the team, though by that point attrition had gotten so high, it kind of didn't make sense. (There wasn't really a team to lead).

The team before that was a similar deal (chosen lead quit not too long after) but I got made a lead... of a team with two people on it (including me). The company went basically bankrupt, and having only 6 months experience with 1 report didn't impress people.

I don't think being a trans woman helps.

I really do try; I come up with new initiatives, I follow through on them, I give talks to educate the team, but in the end, I'm always waiting some number of years for the next magical re-org, which may or may not go my way.

I don't know if I can handle this one getting worse.

On the other hand, if you want to hear how to make it past 40 in software, this is probably an excellent place to ask!

1) Don’t include irrelevant experience on your resume. Nobody cares that you were writing php websites in 1997. Try not to put anything on linked in or you’re resume that would indicate your age unless you’re one of the top people in your field and your experience makes you stand out.

2) Keep up with new languages. Don’t be the guy that only knows perl when everyone else is using python. If you aren’t learning rust and go today, you’re going to be left behind five years from now. And once everyone is on go and rust, you should be learning the next thing.

3) Stay curious. I know you have a family and kids and other commitments, but you have to stay interested in the world. Keep up with business news, and science news and stay connected with pop culture as much as possible. If you’re applying for a startup with a bunch of 20 or 30 something’s you, you need to be able to meet them where they are.

4) Don’t get complacent. You’re always a bad quarter away from getting laid off, and that becomes more true the older and more higher paid you are. Keep your resume updated. If recruiters aren’t beating down your door, you need to ask yourself why. Because if people aren’t trying to hire you, your employer probably isn’t excited to keep paying you either. I was a junior guy on a team with all sysadmins 5 years ago. They were all the same age as me, but with many more years experience all at the same company, doing the same thing and really resistant to changing. I came in and really dove into the deep end with devops, despite having little programming or sysadmin experience (I had a networking background). Within 5 years I was a senior developer, making more money than any of the rest of the people on the team, and eventually got poached by a recruiter offering 40% more money. They’re all still there barely holding on to their jobs.

Rule of thumb, your business should be viable at 50% billed time...

Every year I take an unpaid break for over a month around the holiday season. I love it but it always is a bit scary to be away from customers at the same time.

Reasonably well. I made more money with my last job as employee, which was paid above the average of the market. However I own my timetable now and I work mostly from home. That is worth some money too and it improves the quality of life, which is hard to quantify but it's very important. I'll never be an employee again unless I absolutely have no alternatives.

It's definitely the kind of company you want to work at if you're middle-aged.

List this firm please, it might help someone.

But I don't think that's exclusively a software engineering issue. If I tried to become an electrician at 40, my guess is I'd encounter some bias, though probably less than in software.

One other thing: by "BigCorps", I'm referring to things like banks, Wal-Mart and so forth, not technology companies like eg Google.

Yeah, I'd much rather work at a traditional conservative BigCorp than a Silicon Valley company that never grew up from startup mentality.

If you do want to stay I tech, I'd recommend looking at the B2B telecom sector. It's far, far more conservative then any other part of the tech industry. They're the only tech companies that I've seen ban T-shirts in the office.

They don't immediately adopt new technologies, but frankly, nowadays I see that as more as a feature than a bug (although once in a blue moon I wish the delay in finally adopting them, when they have been successfully proven themselves, wasn't so long).

The most glaringly conservative aspect of my current job is its very rigid adherence to process. Again I must say that, having worked in places where it wasn't the case, I'm so glad that process is followed strictly.

The big problem with this job is that I've acquired a ton of domain knowledge that probably won't be useful in another job. This means that I need to keep other tech skills (algorithms, programming languages...) much more finely honed. On the other hand, I've acquired top notch documentation skills.

EDIT: I also can confirm that there is plenty of >40yo people here. Definitely a good place to be when you reach that age, although I'm only in my eearly thirties. I've found also a high level of diversity in general, which is very, very good.

I just got hired by one in Texas that reflects that impression, which I had before I ever interviewed there.

"I don't think Java is all that bad, and I can enjoy well-done object-oriented programming."

This is probably the most accurate opinion of Java the language I've seen, one that isn't tarnished by what anyone has seen in any proprietary codebase.

I would rather program in Java the programming language than Javascript any day of the year, even if I dislike the vast majority of popular Java frameworks like Spring, Hibernate, etc.

The important principle is that you should devote your learning time to things that are more likely to survive. A good way to do this is to pick something that has been around for a long time. Knowing how to write an optimized linux kernel driver is far more long-term-valuable than, say, a Javascript framework. Knowing how to do quantitative marketing is even more valuable than that.

The absolute worst thing you can do is to chase the new shiny every year. If you do that, you will never be more experienced than the most junior member of your team.

But, they did acknowledge it. And they're now making design decisions to facilitate the web as an application platform, rather than intentionally trying to make application development as difficult as possible to dissuade it. So now we've got WebAssembly and tomorrow or the day after we will have any language anyone wants to use being used. In that arena, Javascript will get pantsed and laughed out of the room. It will probably happen with pretty amazing speed, as there are legions of developers who have been holding their breath for this for 20 years.

In this discussion, when we talk about value, I think it makes sense to look at value in the sense of how valuable a skill is to the longevity of your career.

In that sense, JavaScript has some upsides - it's everywhere, and will likely continue to be everywhere. There will be lots of demand for JavaScript development.

But because JavaScript is everywhere, tons of people know it, and tons of people are learning it. So although there will be lots of demand for JS development, if you're a JS developer, there will also be a ton of people offering a skillset that is broadly similar to yours.

As you mentioned, the demand for something like Linux driver developers is tiny in comparison to the demand for JS developers. But the talent pool is relatively tiny, too. So it might be easier for you to differentiate yourself because when an employer is looking for someone with your skillset, they're not going to have to wade through hundreds of resumes from people who look pretty qualified.

In general, I think it's most valuable to specialize in solving a certain type of problem, where programming just happens to usually be the best way of solving it. It's often easier to sell yourself as a solver of specific kinds of problems than it is to sell yourself as a generalist with experience in JS, HTML, CSS, etc.

Given how much JS development thrashes, it's a pretty reasonable bet that whatever you're learning this year will be out of fashion next year, and irrelevant in five years. That's the high-order bit, when you're thinking about your career.

Even for something as "narrow" as linux kernel development, I can pretty much guarantee that someone will want hire you in 20 years, so long as you are competent. I can't make that guarantee for most technologies.

I really wish it were possible to make reference to JS in a less-than-glowing light without being downvoted, but alas. Substitute any other brand-new technology for "Javascript framework" if you're having difficulty seeing the argument.

But would I bet on Javascript over (for example) C? No way. Any new developer would be wise to learn C, even if they completely ignored Javascript. And I don't need any technical details about the language to make that call.

Work on understanding the business needs and not just business requirements for your feature.

Learn how to foster team growth, not just your own personal growth.

Figure out processes to help the team and not just building your feature.

Don't be intimidated by younger engineers who are trying to climb the ladder. Help them succeed.

You don't have to be as actively sought after. You should be staying at positions longer - 5 years, maybe even 10. (Note well, however: By this point, you probably have seen several toxic environments. If you're in one, don't wait - get out. Life is too short to put up with it.)

I have a file where I keep track of headhunters that I think are worth their salt. I'll use it if and when I feel like it's time to move on.

For the record, I'm 55.

(I'm 40 and my current role is with a small company where I implement solutions rather than have a title)

Bingo.

Security is one of the few cross-discipline, cross-domain specialities where it is possible to be a reasonably good domain expert and still have a good coverage across other domains. The fundamentals don't change. (And I say this as someone who's been immersed in the field for 25 years, so of course I'm biased.)

There are few other domains that can offer the same level of constant demand.

The beauty - and the depressing aspect - of security is that maybe 10% of security is about software. The remaining 90% is all about what is between people's earlobes. To become good at security, you'll need to learn how to explain extremely difficult and often subtle concepts. And you'll have to do that for both technical and non-technical crowd. That's a fantastic and continuous trial by fire. It's also lots of fun!

Bonus: because everything is a tradeoff, you really can't avoid the engineering approach. Teaching the concepts and reasons for tradeoffs to less senior developers will be part of the job specification. Fun.

> language/framework of the week

To quote something I have often stated in our interviews - there are only four programming language families. Everything else is syntax.

1: Imperative - C, Fortran, Pascal, ...

2: Object-oriented - C++, Java, Python, Ruby, (maybe Delphi's Object-Pascal), ...

3: Functional - OCaml, Erlang, Haskell, F#, ...

4: Declarative - Makefiles, QML, SQL, ....

To be perfectly honest, I don't know which bucket I should use for Prolog. It's supposedly logical, declarative and functional at the same time. I've never managed to understand it, despite trying.

And for the record: perl in basic form is imperative. With the introduction of "bless" keyword it crosses over to object-oriented domain but following the syntax is not necessarily straightforward. [I've spent a non-insignificant number of days auditing OO-perl. It's not a pleasant experience.]

If I wanted to jam languages into 4 categories, it would probably be the Algol, Lisp, and ML families, plus All Those Other Languages. :)

Declarative vs imperative is more interesting: what vs how, building descriptions of problems rather than chains of calculations or lists of steps. I don't think functional style is strongly related to declarative, except in the very low level sense that a functional program doesn't necessarily have a sequential evaluation semantics. But that's increasingly true of seemingly imperative languages also.

* Imperative languages describe how to perform the solution.

* Functional languages describe the solution.

* Logic languages describe the problem.

I'm not sure I actually agree with this categorisation, though.

Understanding customer needs and translating that into product definitions is something that will likely never go out of demand, and is needed in industries outside tech. And if demand for distsys goes out of style I'll just learn something else. I've already kind of done that, having cut my teeth on embedded systems, followed by a short stint in mobile before getting to where I am now.

Judging by what I see around me, I don't see the strategy being any less effective in 10 or more years.

More seriously, having had a look around my cohort, there aren't that many people who've left programming altogether, and those that have have done so for personal reasons. Generally people have moved "upwards" and acquired management track positions. Small companies are good for this - because it's so flat you can easily get a high-ranking job title which you can then leverage into the next job.

Look "up". Look at the older and more senior people in your organisation. Maybe even directly ask them about careers. Recognise that if nobody around you is over 30, you're either in a very unusual place like an SV startup or you've wandered into Logan's Run.

Physically, I age linearly n.

Mentally, I age logarithmically 17 + ln(n).

Think of it like being on a first date: your idealized self. You're real, but like 120% real.

So far in this thread:

- continue to learn / evolve

- go into management(well, someone will mention it)

- Go into: consulting / start your own business / remote work

I'm not too far from 40 myself. Any advice?

This is a huge advantage compared to some recent graduate that has no idea, knows nobody, and is still learning the geography of the industry.

Don't stop learning. Don't stop making contacts, friends, and other connections. At some point you won't need a resume to get a job, you'll just need to know who to call.

It's not so much about hustling as it is developing meaningful professional relationships with people. You don't need to be a huge extrovert to make it work, you just need to engage with people. Solve problems together. Help each other out. If you get someone out of a jam they'll remember it, and when it comes time for a reference maybe they'll be there to back you up and vouch that you're the right material.

It's pretty easy to go about doing your job without really paying attention to anyone else on your team or at your company.

But if the fact is that a large percentage of folks doing programming a 29 won't be doing it at 45 and aren't going to have a good exit plan (if they made a high salary in that time), then in a sense what's being said is:

"Programming is a dead-end job for those under forty" and about forty is the end-point for them.

I was self-motivated to constantly learn, and had no trouble doing it... when I was young. It was the right profession for me then, when I had the interest and passion.

After a while, though, much of it starts to seem the same. The towering vistas that were once full of mystery, adventure, and discovery turned in to endless plateaus of rinse and repeat learning of technical minutia and buzzword tech of the day. I also developed lots of new interests, and started to want to have an actual life outside of work.

So then I very consciously decided not to strive to excel in my field anymore, because it would just take way too much of my time, which I'd rather spend doing other things. Then, before too long, I burnt out, and took a long break, eventually coming back to the field because I burnt through all my savings and needed money. This happened a bunch of times, with ever longer breaks in between.

Every time, I was able to brush up on the technology knowledge and skills that I needed to get a job, but I was never as excited about it as I was when I was young, and actually started to dread working with it, as I found it mind-numbingly boring.

I should have definitely completely switched careers after my first major burnout, but I didn't, and I've come back to the field again and again instead. This has definitely been a mistake, but here I am. I'm good enough at what I do to get work, and to even impress my managers... while I still haven't burnt out this time around and am still capable of putting in the overtime to get a lot done. But it's just a matter of time until I burn out again, and this pattern of not working for extended periods of time looks horrible on my resume, I haven't learned nearly as much as I would have had I stayed employed the whole time, and my career is nowhere near as advanced as that of people who can hack full-time employment long-term.

I don't think my case is typical, as most people seem to stay employed continuously in the long run. But I can't, and I feel I'm way too old for a career change now... and, anyway, I suspect whatever it is that I'd switch careers to would get boring before long and I'd burn out again. My interests are far too varied and I can't stick to doing any one thing for long before getting bored.

This is not to mention all of the endless corporate bullshit one has to put up with at work. Some people are really career-oriented and can deal with it. I'm not.

I took my current job with the goal of transitioning into a leadership role, either product or management. I was walking into a situation where I knew people already here and was hoping to leverage that. Those people left a few months after I started, and now I'm kind of stuck on an island. I've approached my current boss but he's completely uninterested in promoting any sort of career development.

Bottom line is I'm burnt out, depressed, and bored out of my mind. The idea of learning Yet Another Web Framework fills me with dread (I'm currently doing Node/React stuff and hating it), not because I don't think I can learn the tech, but because it's no longer fulfilling in any kind of personal or professional sense.

So, I really don't know where I'm going, or what I'm going to be when I grow up.

A lot of times I feel like there is not career track after you hit "Senior Software Engineer", especially outside of super specialty tech. It feels like the only real track is management, and most places don't want to promote or change the management structure at all.

It's honestly very hard to get excited about going from Senior Engineer to Staff or Principal or whatever the text title is. Nothing will change in terms of the job. Pay is pretty well pegged to what you started at with single-digit percentage increases every year or so.

Skill wise? Learning new frameworks is just not as exciting as it used to be. Even then - the reality is that whether you're the most skilled dev in the world or a mediocre dev with only a 9 week bootcamp of experience, you're going to not understand the new environment you're dropped into when you start. It's full of weird quirks and historical oddities. It'll take time to understand those and get productive in whatever the particular stack is.

All of which feels like... every time you start a new job, you're starting over. With a little more insight and vision, but fundamentally, doing the same thing over and over.

I really think this time I'm out for good. I'm approaching that age where it's hard to get programming jobs anyway. I've got some side businesses doing OK; I'm working on ramping them up, and trying to get some teaching gigs to fill the gap in the meantime. And if all that fails I'm considering getting back into the lawn care business like I did when I was a student.

I used to be very passionate about programming: I started in 4th grade, started my first software business in college, and was always doing side projects.

My strategy for my career is to try and position myself into a position of enough authority to decide priorities around software engineering, and what my team is working on. Then I can delegate all of the boilerplate to the younger engineers, and spend more time collaborating on much more interesting and difficult problems.

I look around at my bigN and I see all these 20something people who just love what they're working on and are passionate about it, and I get it. I was the same way at that age.

I just don't care anymore, tbh. I want to work on something fun, and things that are fun don't usually provide a paycheck. So I grind away, and the years waste away, and I don't know what to do about it. I'm smart enough to get by without investing a lot of effort, but I'm really just wasting my life.

Programmers to programmers: You must be a super agile ninja capable of teaching yourself everything at a moment's notice.

Businesses to programmers: Yeah, we still need people doing Java 6 and VB6. We're also going to disregard all of your security and technical debt concerns. We're also going to hire managers who suddenly change a bunch of tech, causing the rest of the team to re-train themselves, harming their career.

I still don't get where this need comes from. The world still needs LOB developers. The uber-ninjas haven't solved that problem yet. It isn't going to maximize your lifetime earnings, but you're not likely to retire under $100k either.

Programmers are extra-ordinarily hard on themselves and other programmers in industries where businesses still just don't give a fuck because they are making so much.

I really wish I knew why you guys did this to us.

I'd be interested in a demographic breakdown of the people who say this. I'd be willing to bet that most of them are in their twenties, live in SF/SV or Seattle, and/or work at startups or insanely demanding trendsetting companies (e.g. Google, Amazon, Tesla, Apple). In other words, these claims are made by people who care about being "cool".

I don't think you'll hear this much from people who live in less trendy areas and work at less trendy companies. Older people and people who work at conservative companies in conservative areas of conservative states (Hi, I work at a B2B telecom in Plano, Texas, and I'm in my 30s) probably aren't going to be making those kinds of claims.

If you stop caring about being "cool", you'll find plenty of work that'll sustain you until you retire.

I imagine there's also a good helping of: "Hey, the MVP works and I won't be here in years 2-10 maintaining it, so everything I can see indicates I successfully learned X on my own in a month."

In 2000, a 40 year old was born in 1960, when the home PC was nearly 20 years off.

A programmer who is 40 today was born in 1977, and they could learn to program while they were in diapers.

These are very different experiences, and the bar will move over time.

That being said, if you've been in the occupation long enough, you figured out that its a continuous learning occupation. The thing is, the fundamentals I learned in the 80's and 90's still do me in good stead to this day. I don't write in assembler or even C anymore, but concepts they taught are still deeply ingrained.

I've got another few years in me before I can retire, and when I do, I'll continue writing code for fun. Simply because I like it.

(Oh ya, first computer was 3.5Kb (3583 bytes!) VIC 20. The first computer I ever SAW was a neighbours PET 4040 he brought home from school over the weekend. I bought the VIC-20 the next day.

The "fundamentals" predate you and I by quite a few decades. Alonzo Church, Turing, Gentzen, Liskov... their work really paved the way for us all. I suspect the lambda calculus will be as useful 30 years from now as it is today. As long as I'm working in a language with first-class functions as values I think I'll be okay.

It's funny that many people still hold the belief that even mathematics is a young person's game. There are plenty of examples of mathematicians making significant contributions after the age of 30.

For me I think the life of a programmer begins at thirty.

I'm sure some companies have an age bias, but I think it will be less and less as the generation who grew up with computers gets older.

?SYNTAX ERROR

Computers and software use, maybe; for software development it hasn't happened (it seemed to be heading that way in the mid-1980s, backed off starting around the beginning of the 1990s, and seems recently to have turned back around at least in terms of what lots of people are saying. We’ll see...)

oh, those 1st world countries...

That said, if you're a software developer and you're also good at communicating and managing people, seriously consider moving into management. While I think the stories of the '10x' developer are true, I also think a good manager can double or quadruple the effectiveness of their entire team. That has a huge impact both on the careers of the people being managed, and at the company.

Another way of thinking about this: Managing people really well is really hard. Most managers are not the best managers. Average managers often end up doing things that reduce the output of their group in the interest of things not going horribly wrong. The Pareto distribution rears its ugly head, once again.

At least as a software developer, you're only breaking code. But you start affecting people's lives, emotional well being, and career paths when you're a manager, and I find it rare where a manager understands this.

A lot of times early companies will go through the motions of, "needing" a VP of Engineering, or CTO, or whatever. In reality their process does not need that, and those roles are either meaningless titles at best or cause unnecessary process to crop up and hinder productivity.

This created conflict exactly as you'd expect and team morale fell apart, projects slipped, etc. Of course, management takes no responsibility for this, instead diffusing blame to employees via suck-it-up type platitudes (couched in "nicer" language but with that essential meaning).

A good manager is really, really hard to find. Good developers are easy to find (relative to good managers). So, while I don't want to get into management, I also recommend it to anyone who might have potential in that regard.

This, I found, is too much for me. I have no remorse if I demotivate my managers; and I can keep my mouth shut and not say anything, to avoid demotivating my junior-dev colleagues. But as a manager, "keeping my mouth shut" is not an option.

But what’s in it for the developer? If the developers is happy and well-compensated bad has no managerial/executive ambitions/fantasies, why ruin a good thing (with a gamble, at that)?