I Joined Airbnb at 52, Here’s What I Learned About Age, Wisdom, and Tech Industry
hbr.org
hbr.org
In my own experience being naturally curious has led me down interesting paths to meet interesting people and learn amazing things. As a parent I tried (and apparently succeeded) in nurturing the natural curiosity in my children, never shutting down a legitimate[1] 'why' question with a curt answer.
If you have forgotten how to be curious it can be hard to rekindle but I think it is more a habit than a permanent change to one's brain. If you practice I like to believe it is possible to rehabilitate curiosity (even if I don't have any research to back that up.)
[1] It helps to distinguish the difference between when your child doesn't understand the answer and when they simply don't like the answer. And the best way to do that is to toss it back to them as "What part of the answer didn't make sense to you?"
This guy was never a developer. He was a founder and CEO with a successful exit.
He was hired as a former founder and CEO, by a business working in the same space in which he was a founder and CEO.
It's an interesting story, but unfortunately its relevance to the career trajectory of the average tech old-timer is somewhere close to zero.
I think you see a high correlation between being a founder and having really strong opinions because these people can afford their opinions, both literally and figuratively. They don't have to live in fear that their opinions might leave them unable to provide for themselves and their families.
If the takeaway is "If you want his confidence, then become an entrepreneur," I am very okay with that. There is zero reason we can't create a country of lots of small businesses and consultants. The reality is small businesses provide more jobs and job growth in the U.S. than megacorps do anyway.
And thinking through that thought exercise it makes me wonder if anyone at Microsoft has tried to do that sort of analysis of the data set. You might be able to proxy curiosity by looking at how many different kinds of jobs people take or how many different skills they accrue.
My career planning will be significantly different under the assumption "as long as I feed my curiosity and stay up to date, I have a reasonable expectation of continuing a primarily technical career until retirement age" vs "it's vital that I've built up some non-technical core competencies by the age of 40, because I may need to depend on them to drive my career at that point."
If value means helping the marketing team at apple to sell more useless (but admitedly super-technological) phones, then count me out :-)
Specialization is fairly easy, people who were getting "top dollar" as large systems enterprise architects (big SMP machines like Sun and SGI used to make) had a skill that is not useful to the newer enterprises that are outsourcing their infrastructure to SaaS/PaaS/IaaS type companies. That continued to be great until it wasn't, and then it really wasn't. When someone looks at their resume they see someone they have to retrain to the new way of doing things.
The second are folks who were always building things with technologies that were fairly recent, but at the end of the day they could train someone to produce as much code as they could in a few months. That is a good skill to have but you have to realize that your experience is perhaps worth a 2x or maybe 3x multiple on a starting salary, period. And once it gets there, that is where you are. The rapid influx of new developers put a pretty hard market cap on people who "just coded."
Both of these generally have the effect of limiting how much you can expect to get in terms of compensation. And if you live your life expecting your compensation to just go up and to the right, at some point your personal expense (or burn) rate is going to exceed your earning potential, and that is where things get difficult.
As you get older the number of things outside of work that impinge on your working hours gets larger. Perhaps you have family, perhaps you're parents start ailing and need more elder care, perhaps you start ailing and you need more medical care, perhaps you're on your second or third marriage, or perhaps you just like to go camping or sailing or fly gliders on the weekends. The point is, the longer you live, the more your life develops some flavor and nuance and when you felt it was fine to work all day and night and the occasional weekend or holiday, now you really understand the need to keep from burning out.
I think there will always be technical work available at some price, the important bit will be making sure that the price is something that is enough to meet your needs. You can do that by keeping your lifestyle at 60 - 80% of your take home pay. And then if you're pay is cut by 20 - 30% you're not out on the street, your just not saving any money any more. If you do this long enough without a major bump in the road (such as a major medical expense) then at some point you can lose 100% of your income and still be okay in terms of being able to meet your obligations.
To address the two sub-optimal outcomes above you can do two things, one is to work not just on learning new things but on your ability to learn new things. Everyone has a different style of learning, and you have to find yours and figure out how to exploit it. I tend to be someone who learns more deeply by doing rather than by reading. So I when I want to learn about some topic I try to invest time in doing it so that I can understand the challenges and then the forces that make those things challenges in the first place. Everything seems "easy" when you don't really know how it is done, so by doing it you find out why it isn't easy, and for me, that is where the learning is. I know a guy who just loves MOOCs. He's done physics classes and esoteric mathematics classes and loves to work all of the homework problems two or three different ways. I personally have a really hard time on that road :-).
The second is you have to be open to new things in the first place. Having spent a big chunk of time mired in the RPC wars I spend a lot of time debating and understanding different ways to communicate between machines over a network and models to use when doing so. As a result, I reflexively flinch every time someone has a new wonderful way to send messages that solves all the problems of the world. I know, as they will eventually know, that the problem space is like a balloon and you squeeze one place and some other part blows up. So I am tempted to ignore it, knowing how the story comes out in the end. However, by teaching myself to 'score' it differently, I can learn a new network messaging stack with the intent of learning what the people making it were shooting for. And rather than lament their walking into some of the same traps that people have walked into for decades, I try to find how it improves on the things that it is good at with the expectation that those good ideas can be applied across a wide variety of systems. But if you shut yourself out from those things with the famous 'Been there, done that, got the t-shirt' sort of excuse you may miss out on the things on the other side of re-inventing the wheel one more time. So by working on your ability to learn quickly you can mow though the new models and ideas and get on to the good stuff, it is less demotivating.
As for soft skills, I've spent most of my career definitely not wanting to be a manager and then getting stuck in more managerial roles than I would have preferred. Google taught me a surprising amount about management because of their unusual split of responsibilities at the time. It wasn't something I sought to learn (see the being open paragraph :-) because I was afraid to be removed from the ability to get my hands dirty as they say. Switching back to a smaller company where I could try both was really helpful in that regard.
Another good thing to ignore is decade based commentary. We haven't seen it much since the 1990's because 2000's and 10's are a bit cumbersome. But believe me once we hit 2020 it's going to be on like Donkey Kong and won't let up until 2100 with "Are you a 20s girl?" and "10 things to look forward to with the 20s" and on and on.
One believes the situations to be somewhat different.
A more curious older engineer with a wider skillset and knowledge of current technologies is going to have an easier time getting a job than one with a very specific and perhaps less current skillset.
I mean, it's not a guarantee, there are lots of other factors that contribute to one's employability (interpersonal skills, for example). But it just seems obvious that someone with more skills (and more current skills) is going to be more employable than someone with fewer skills, and perhaps less up-to-date skills.
There's always one of these comments when this topic comes up. It's simply not true. There are lots of people still working Cobol jobs out there and there's lots of demand for more. C# hasn't changed much in decades. Neither has C++. The only part of tech that moves at breakneck pace is web development and serious engineers consider that to be a cruel joke. And that's coming from a senior web developer with 15 years of web dev experience.
Having done C++ back in the days before the STL & Boost were a thing and having done C# back in the C# 2/.NET 2.0 era and recently trying to come back up to speed on C# 6 and .NET 4.6.x, I have to say that that is an ... incredibly surprising assertion to make.
However, I still want to at least aspire to learn new stuff and stay informed about what other people in my field are doing. Every technology has an expiration date, and as I get older and more ensconced at work, I've been getting paranoid about getting too comfortable. Specifically, I'm paranoid that I know relatively little about web development, period. I am not some twentysomething hipster web guy, I'm a weird middle-aged Unix guy.
Although I've rarely pushed myself to learn about something because I felt like I had to- I'm just interested in software and have always enjoyed learning about it. I don't have to force myself to do it, and I probably wouldn't be productive if I did. The only thing that really matters is doing whatever makes you happy. If it has pragmatic side effects, great, but if it doesn't make you happy then it's not worth doing.
It even seems to provide proof that being an older IC makes you irrelevant because the success story is not a coder. The lesson is that as you age it's either up or out. You either learn higher level skills or slowly fade into irrelevance as your ideological baggage acts as an achor distancing you from keeping pace with the now constant supply of young grads. (Now that coding is "cool")
At the very very abstract level, companies are divided into people seeking meaning and those that provide it. Upper level executives provide meaning in work for the ICs. For the middle level executives they provide meaning in the "company".
As you age, you're expected to be more wise and knowledgeable. Staying as an IC is a black mark of sorts that you've plateaued at some point. You either need to move into a meaning providing (or meaning enforcing) role, or stay as an IC but provide meaning in the form of technical wisdom. Otherwise, all else being equal, you stand out amongst the younger workforce.
Previous rewarding specialization does not mean future rewarding specialization. The world can shift in a way so that your skills and ideologies and perspectives are useless. The ageism prevalent in silicon valley is that it's unkind to equally skilled low level people with one lerson being older.
If your an older person and your skills are actually in great demand but low suppl(strategy and meaning making)y, the ageism doesn't apply.
I'm not 52, but I'm in my late 30s and as an engineer who works at startups, I find myself unable/uninterested in doing the things I did in the past. For example, I find myself having to work smarter rather than just putting in more hours than everyone else (which is what I did in my 20s).
It's also important to bring my perspective from 15+ years in the industry while at the same time coming into each job with a fresh set of eyes (he touches on this in the article). Just because I've seen a lot doesn't mean that there isn't still a lot to learn.
You can't always work smarter day in day out, and expect to beat someone who is both smarter and willing to put in more hours.
I knew plenty of younger developers who spent nights/weekends doing proofs of concepts they could show at work.
It did make them look better more competitive than other people who just put in the hours.
I spend a lot of time doing side projects just to stay competitive.
> when I hear comments like "work smarter rather than just
> putting in more hours", I wonder if that's not just
> rationalization for simply not wanting to work longer hours
> because people in that age group generally have other life
> obligations, and eventually become overpaid and
> uncompetitive status.
Working smarter generally means planning before writing code, thinking about how one's work will integrate into the larger system and how to make that code reliable, maintainable, and extensible.
It also means picking your battles and directing effort where it will count.
With experience coders learn that endlessly coding generates errors and shortsightedness. Sure, there is a small percentage of coders who can code error-free for much longer than most, but most coders will be most productive when keeping to a regular 40-hour work week. And even super coders are susceptible to burnout. [1]
[0] http://www.igda.org/?page=crunchsixlessons
[1] http://www.alistapart.com/articles/burnout/
EDIT: format link list.
if you don't understand the benefits having some 40 or 50+ year old devs on a team brings - watch some Jim Weirich videos
I have a largely different opinion on this, working smarter just means doing the right thing instead of the wrong thing. I realize that is vague and I think the reality is vague here. Investing the time to write 'reliable, maintainable, and extensible' code is the right thing to do when it's the right thing to do, it's the wrong thing to do when the it's the wrong thing to do. Being older shouldn't mean that you always write 'reliable, maintainable, and extensible' code, it should mean that you realize when it's warranted and when it is not. My experience is that this isn't the case, 'older' coders (and I safety quote older because I'm not convinced that age is the true differentiator) tend toward 'reliable, maintainable, and extensible' at all costs. That just isn't the right answer all the time. I'd venture a guess that some of the stigma that exists about 'old coders' is related to this.
- do the thing - do the right thing - do the right thing the right way
As others have pointed out, working longer hours is actually counterproductive. The 40 hour work week and paid vacations were not introduced out of kindness, they were introduced because employers found out that they actually improved overall productivity.
However, particularly in highly cognitively demanding fields, even 40 hours is likely too much, actual productive work is more around 20-25h per week at best. If you try to do more, you will accomplish less.
> eventually become overpaid and uncompetitive status.
Yes. If you continue to do the same things in the same way, you will definitely be uncompetitive. As you grow and grow older, you should be accumulating at least knowledge and hopefully a little bit of wisdom.
As the old joke goes: "One chalk mark $1; Knowing where to put it $49,999."
Meaning you have to find ways to leverage your hopefully increasing abilities to shift into jobs/roles where you provide more value. Like bringing architectural oversight to teams/projects, mentoring, answering questions. If I can prevent a more junior developer from spending a day or two chasing down a blind alley by giving a couple of minutes of advice, that's pretty valuable. And scalable, because I can give a few minutes of advice to a whole bunch of developers over a given workday.
Or if I manage to introduce an architecture that reduces code by say 50% while at the same time making the code simpler, I've just doubled the team's productivity, with likely more compounded savings in the future.
https://www.wikiwand.com/en/1835_Philadelphia_general_strike
No it's not. As someone who's had 10 jobs by the time I was 25. I can attest that.
You can be 10 times more productive by picking a solution that achieves the same for 10 times less effort. And that's what you should do all the time.
Whenever you take wrong decisions (let's call that "the design phase"), you have to compensate by doing 10 times the work down the line.
That's where the experiences come in. Whatever you have in mind. Already seen it. Already done it.
In practise, that means I could play ping pong 4 days a week and still be more productive than most people, because they will do work that require a week to be done, while I will do work that require only the last day, to achieve the same result.
The downside is that it's getting boring and irritating to see other people trying to tackle the job in a way known to be wrong (which they can't realize because they don't have the experience).
Unless you are surrounded by sea of incompetent workers, I find it hard to believe that one can be 4 times more productive than most people, on consistent basis.
Has enterprise software development become so narrow in amount & scope of assignment given to one person, that quantifying your productivity relative to others is actually possible?
While in some very constrained, straightforward coding challenges it might be hard to find orders of magnitude improvement, a lot of designing software has a huge range of solutions. It might be the case that a single org doesn't get to compare.
Or people typing in "google" into google's search box? Or how it feels watching someone copy&paste data in Excel instead of using a simple formula?
That's what's happens on a software architecture level as well.
That's not unusual in my experience. I've gone down the wrong path a few times, but I'd like to think I've suffered enough to think twice now. Let's call that suffering "experience."
My Monday's afternoon: Read hacker news all day and eat ice cream. Thinking about what to poc next (of course, that counts as work).
Coworker Monday's afternoon: Tried to migrate a thing in place to get the new improvements. Didn't make a backup. The update failed and fucked the system. Stayed until 8pm to un fuck it. (Then we'll have to continue restoring it fully tomorrow).
See. He's worked full time and overtime already + many hours lost (for both of us) because we had to fix shit in emergency + many hours lost by other people who are impacted.
That's a ton of overwork and negative productivity. I could eat ice cream for half the week and still be significantly more productive than that.
P.S. This example is for toying around with production systems, it's easy to understand and evaluate. We can do examples with bad design decisions that destroy the project and are 100 times worse :D
I learned a lot from him and never doubted him on this fact. Unfortunately I've also worked for younger bosses who have yet to make that connection.
He not only didn't work harder he worked very non smart also.
He used the phrase so often I can't help but associate it with his excuse making years later.
A 50 year old engineer sitting alone in a remote location on the other side of the world is going to find employment and opportunities much harder to come by than a 50 year old engineer who has lived and worked in Silicon Valley for decades. (Ask me how I know... ;-) )
Just the power of a warm referral, or someone in a meeting to say "Oh, I know so-and-so is really great with database security - I worked with him about 10 years ago...We should get him on board for this project..." can work wonders for a career.
But I know what I'm worth. I know that my code is top notch. I know that my standards are above most things out there, and it shows.
I've released almost half a million lines of code for free as open source projects. I've gotten emails from people in the most remarkable industries, asking questions about something I'd written decades ago (for example, http://ftp.lip6.fr/pub/linux/sunsite/system/network/daemons/...). I've posted the more useful of them to my github account, and that's the first place potential employers look to see if I'm worth my fee. And I am.
Age only becomes a problem if you stop drilling down into the technologies people use and REALLY understand them, and what lies underneath. Otherwise you really aren't worth any more than the guys coming out of college with no experience.
Now, if you're in a field that REQUIRES well written code (mission critical systems etc.) then being able to do so is of course a merit. But using good coding skills as an argument for higher salary at your average tech company just doesn't make sense.
> I asked a lot of "why" and "what if" questions, forsaking the "what" and "how" questions on which most senior leaders focus
On the tech side, people come to me with solutions they want to see live, and spend 10x the time there than describing the root problem.
Equally important is asking "why not" to alternative scenarios, as it fleshed out the scope of the root problem, often vetting the initial solution or finding a better one.
In those cases I tend to give a little bit of background as to why I want to know why. It helps show the person that you trust them, but you're curious anyway. Eg. "I think I missed some of the prior meetings on this, why is this the best option?" It adds a little bit of humility that prevents it from sounding confrontational. Sometimes I'll ask something that gets to the bottom of why without asking it directly. Asking "Did we test the other options before choosing this one?" Can help someone to elaborate their why and making yourself an active participant rather than listener only.
1. "Why" is the most important question you can ask, and understand the answer to.
2. If someone is defensive to being asked why, it's because they can't answer it well.
3. If you can't answer it well, you haven't thought it through enough.
1. Sometimes "why" can lead to analysis paralysis and procrastination. Sometimes "how" is better -- as in how do we best move on to a solution?
2. It depends on how the "why" is asked. If the asker is confrontational and implies the burden of proof is on the receiver, then the defensiveness might be warranted. In other words, sometimes people ask "why" because they are being contrarian dicks with axes to grind.
3. Sometimes you need time to think it through but the "why" asker expects your answer immediately and if you don't have one yet, uses this line of reasoning to conclude you must not have a good answer at all. It can be hard to have presence of mind in a situation like this and realize this fallacy is being thrusted upon you. Not a very fair setup.
1. The "how" is often formed by the "why," as in "why are we writing this software?" What problem are we solving? If you can't answer this well, the "how" is irrelevant. Don't get me wrong, the "how" is important too, but the "how" is dependent on the why.
2. I agree some people are dicks about it. The best way to counter that is have a good answer to the "why," then ask the person if they have anything to add. If they are just doing it to be a prick, they usually don't have an answer, or come up with something stupid. If they have actually been thinking about it, they might contribute something you haven't thought of, and you'll just have to deal with their abrasiveness to get it.
3. You absolutely need to think about your "why." If you don't have a complete answer, then say so, but add that you are still "chewing on it." It is intimidating, that's why you should always have a good answer.
I am really tired of statements like these.
Just kidding; I'm tired of hearing these things too.
Sure, but is it wrong?
Even if it isn't, I don't think there is any evidence to suggest that its actually true.
The bit about emojis in particular however seems completely out of touch.
I also learned that my best tactic was to reconceive my bewilderment as curiosity,
and give free rein to it. I asked a lot of “why” and “what if” questions,
forsaking the “what” and “how” questions on which most senior leaders focus.
[...]
My beginner’s mind helped us see our blind spots a little better, as it
was free of expert habits. We think of “why” and “what if” as little kid
questions, but they don’t have to be.The one thing I have learned, is I'm not very interested in pursuing traditional management roles... I've dipped my toes in and hated it. But being able to work with some amazing people, be challenged by very opposing views and ideas and the opportunity to constantly learn from all angles is incredible.
The work itself is often rather mundane, but what you get out of it isn't just the process of making something work.
What a classically "Baby Boomer" statement. Confusing age with wisdom.
Yeah as a white male boomer you grew up in an insanely prosperous era with basically everything stacked in your favor.
Like if you'd didn't come out of that on top, WTF was wrong with you?
Edit: Now that I've finished reading, this also stands out:
>Wisdom is about pattern recognition. And the older you are, the more patterns you’ve seen.
LOL, coming from an older person, this seems awfully convenient.