I've struggled with helping people out of this rut.
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.
Maybe it's just my delivery, but in many contexts I've found people who react to "why" questions as confrontational. So much so that of the 6 W's [sic] I think "why" is the line of inquiry most requiring of diplomacy.
That's a great point. I think it's very much dependant on the audience as well as delivery. One would hope that people you work with are receptive to curiousity, however it's not a given.
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. 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.
Yes, those are all problems with asking why and usually show up in a bad environment. Even with all that said, it's the most important question. Your list is a great example as to why having a toxic work environment will kill innovation; because people are afraid to ask and understand, "why."
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.
It's interesting to see this sort of perspective. I would like to see more of it.
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.
I'm in your same age bucket, and 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.
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 know very few people who actually put in lots of hours and who do productive work. It's just that at first, you have to put in more time to find what you're good at. In many non-US cultures, overwork is a symptom of bad time management and incompetence.
I agree that putting in more hours consistently toward an active project seldomly turns out well in the long term, but someone that can put in more hours doing side projects using technology/frameworks that they aren't currently using on their job that allows them to stay current/cutting edge that will make them more competitive.
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.
Well, same here, after all I'm on HN during the weekend (half-working, planning a conf, while supervising my kid & friend).. There are all sorts of people, but if we're going to generalize, I think the general expectation should be to aim for efficiency and avoid spiralling in overwork. (and I wish I had better time management determination ;-)
When I started getting burned out at work, I made a rule for myself. The general rule is no work outside of work. For me that means I am allowed to write code but it can't be currently work related code. I've been much happier and productive at work since I made that rule.
Overwork is a symptom of bad time management even in US cultures, we just don't recognize it. The HN community would likely agree that most startups fail. Over work, building products that fail or will be cancelled, is a sad waste of human potential. Sometimes extra work is required, but more often it is energy wasted.
> 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.
When people advise to work smarter than harder, it's often a nod to the fact that longer hours generally produce negative results. [0]
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]
a great old coder I've worked with for many years often says - I might not know the solution - but I know what it isn't - that knowledge/perspective mixed with younger coders who will do some heavy lifting is a very powerful configuration
if you don't understand the benefits having some 40 or 50+ year old devs on a team brings - watch some Jim Weirich videos
> 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.
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.
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.
The 40 hour work week was introduced because workers demanded it (in the US I'm not sure about other countries). The first strike in North America was workers demanding a shorter work day.
I'm a mid-30s senior engineer as well. The type of problems I solve now are completely different than the problems I solved in my early 20s. Back then I spent considerable time grinding out dozens of very similar things. These days I figure out how to handle a problem and then some person in India grinds out applying that solution all over the place. Grinding out cookie cutter code takes less effort. I could do that more, but I can't really use my brain more. It wears out too quickly.
>>> I wonder if that's not just rationalization for simply not wanting to work longer hours [...]
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).
"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."
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?
It's probably far, far worse than that. How do you count things like when someone suggests using a database/structure/system that is very poorly suited and spends 3 months or more before giving up versus someone that can figure out ahead of time it won't work? Or when someone suggests an approach that is error prone and continually introduces faults, yet had a slightly lower startup time? Or when a system is designed and needs 20x the hardware? Or requires literally 1000x the processing?
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.
I believe it's entirely possible. Remember the feeling you get when you're pairing with someone who's hunt-and-pecking curly braces on their keyboard? Or searching for GUI sub menues for the simplest operations that would be instantly done with a keyboard shortcut?
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.
It need not be on a consistent basis. I recall one bad decision on the part of a manager that caused me to work eight months of 60-80 hour weeks and nearly burned me out. It took some hindsight for me to understand that, and since he didn't have to suffer over it I'm pretty sure he would make the same decision today if he hadn't been promoted to a higher technical position where he can do more damage.
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."
On the opposite, software development is broad in amount and scope given to one person. That leaves many important decisions to be taken, many of which are slow or dead ends.
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
My 2-cents here I would say that working smarter directly related to developing your leadership skills. You can do a lot more by helping lead a group of technical people than you could ever do/code by yourself.
Very true, but if you're in your late 30s, mentoring and leading other developers is mostly likely part of your job description. You are in a position to make broader multiplying impact than a junior developer with only 2-3 year under belt.
I worked once for a boss that didn't believe coding beyond eight hours was productive. He said that after eight hours the number of bugs went way up. There's a cost to all those bugs that negates the extra hours and he claimed to have the proof of it.
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.
There are twenty three people in the world for every one person in the US (as an example, since companies still tend to he nationally co-located). Working smarter matters unless it becomes possible to work 552 hour days. It matters a lot.
I agree with your point but every time I hear "work smarter, not harder" I can't help but think of a very lazy guy I once knew who said that all the time.
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.
Here you go, the secret to relevance throughout your career: "I’ve spent a lifetime being curious about people and things, which, I guess, means I’m well-read and well connected."
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?"
Given how jobs seem to be dying, self employment may be the wave of the future. It was also something the founders of the U.S. thought was critical as a foundation for a truly free and empowered society. I think this is correct. When I had a corporate job, I worried a lot that they would trip across my online activities and fire me for them for some damn reason. It seriously curtailed my online activities for a time.
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.
There's a problem, of course. The economy has centuries of history of filtering out all competition and leading to monopolies/monopolistic competition. There are significant pressures in the 'free' economy toward centralization of power. Those pressures include over half of the US political landscape. Small business can't save itself let alone the rest of us.
If there are so many people falling through modern society's cracks, then let us figure out how to have them be able to guide themselves to others in similar fashion to help them influence a better solution into being?
That is always possible. I suppose to be really scientific about it I should got through my LinkedIn connections (which I generally curate to only people who I have actually worked with in one way or another) and put beside their name my impression on whether or not I felt they embraced their curiosity, and then to go through all of their profiles, for the ones that were current, and rank their status as unwillingly retired, under employed, employed at scale, or willingly retired. Then go back and see what correlation there was between that and what I had evaluated their natural curiosity level to be.
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.
I think a lot of us younger engineers would love to see the results of that type of analysis, as biased and incomplete as it inevitably would be.
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."
I would say that non-technical competencies are not optional and they will help your career one way or another. Maybe a better question to ask ourselves is how do I continue to add value in the environment I'm in? I doubt the answer to that remains constant throughout a long career.
You'll probably come up against the management vs. technical fork in the road before 40. Which you choose depends on your particular strengths and skills, but no shame in either choice.
I have thought a bit how to respond to this comment. From the folks I've "grown up" with, the ones who got stuck either specialized in something that became less relevant, or failed to branch out beyond things that can be learned in a few months. I think it might be useful to unpack both sides of that.
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...
You can say this may be survivorship bias. But I at least haven't seen the data that says this is survivorship bias. I haven't seen really solid numbers about how unemployed software engineers are at 50. All I've got are vague and anecdotally-substantiated allegations of age bias in Silicon Valley, which may be localized in the startup arena, and also Silicon Valley is not the entire industry.
I saw lots of people commenting about it on job sites in many places that arent Silicon Valley. Others had to train their young or H1-B replacements as their last duty. There's definitely more data out there than Silicon Valley complaints.
Almost all generational names are bs. Maybe the swath of children born directly after WW2. Other than that it's just noise.
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.
Yeah, hello? This is the most atypical model possible for older tech workers. A hugely successful hospitality CEO joins a tech startup disrupting the global hospitality industry. How is that experience instructive for anyone except Chip Conley? Emotional intelligence in Mr. Conley's world apparently doesn't require any sense of irony. How hospitable.
My typical co-workers have always been 20-30 years older. The ones that stand out and have been the most productive teaming across generations have taken Chip's approach. The older engineers that focus on "how to technically implement a feature" miss out on (and often suffocate) the potential creativity of younger engineers.
There's often lot of technology and industrial engineering in what we tend to think of as "low tech" industries. An engineering professor once claimed a pie company had been the most high tech place he'd consulted.
It depends on what they're curious about. An incurious person who only learns new stuff when it's forced on them will eventually lose relevance. Their knowledge base is literally defined in terms of their environment and the forces that it exerts on them. They are like coastal rock formations shaped over the years by the tides- they don't shape themselves, they are shaped.
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.
> An incurious person who only learns new stuff when it's forced on them will eventually lose relevance.
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.
> C# hasn't changed much in decades. Neither has C++.
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.
I'm no advocate of rapid change for its own sake. I mostly do POSIX systems programming, and the churn of web development frameworks does not appeal to me at all.
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.
"Many young people can read the face of their iPhone better than the face of the person sitting next to them. I’m not saying young people don’t understand emotions. Our digital world is full of emojis, and the term “emo” didn’t exist back in my schoolyard days. But emojis don’t create interpersonal, face-to-face fluency."
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.
I often try to ask 'why' and 'what if' questions. Maybe I just suck at talking to people but they often become defensive and think i'm trying to question their solutions when i'm really trying to understand how their solution works (i'm young).
I'm 42 now, still highly employable, although not at all companies. And that's fine. They want someone who can churn out cheap but perhaps not so good code, more power to them. That's not what I'm interested in, anyway.
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.
Half of us are average coders. I'd still like a job at 50. This isn't an issue in other professions. Doctors don't become stale with age. Lawyers typically become partners.
That you write "top notch code" isn't really a selling point for most organizations. Management tends to just want to get things done ASAP.
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.
Good coding is not just code but design as well, and has a huge effect on outcomes even if many business people don't appreciate that. Some do however, and I believe the niche is much bigger than "just NASA."
This just feels irrelevant to me. Ageism is directed towards older individual contributors, not higher level executives whose job is mostly strategy. (And unofficially, providing meaning and perspective to the younger workers)
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.
One thing that people don't seem to talk about is that with age, usually comes a broad network of colleagues and people that you know in an industry. Never underestimate the power of a network.
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.
Constant curiosity and learning are two of the things I love about software development... Most people gain and hone knowledge and experience in a particular sector or industry, and usually not very broad. With software development you hone your own craft, with a breadth of knowledge, experience, tools and techniques. You will be exposed to project management knowledge and techniques as well. But beyond all of this, in a career you will have the ability to work with any number of industries and areas of business. From eLearning materials for aircraft engines to business security in banking. It's an incredible opportunity.
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.
This guy is both non-technical--which I correctly assumed, given that his essay was published in the HBR--as well as a former executive. His life experience is of little relevance to the average 40-something (or is it 30-something, now?) software engineer stifled by ageism.
91 comments
[ 4.1 ms ] story [ 159 ms ] thread> 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'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.
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.
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...
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.
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.
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.
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.
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.
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.
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.