I'm better now than I ever have been. I was trash in my Jr years. Being discriminated against due to age would be a grievous error on the part of any potential employer.
I agree with you, but imagine being a discriminatory, but rational asshole.
Of course you're not going to hire a woman if you could hire a man - they might get pregnant and be away from work for a long time.
Of course you're not going hire an older employee that knows their worth over a recent graduate that isn't familiar with the salary they should earn. You can rip them off much more easily.
People can be cunts but still act with some rational motivation. That's why we have protected categories, to make sure that that isn't a strategy worth pursuing.
A lot of software companies don't care about having good programmers, they want people to do their bidding and be as cheap as possible. Younger people are nicer to look at too.
Such an important point. At so many places, effectively producing good software is low down on the priority list. In which case, a lot of the "rational actor" analysis around hiring totally misses the point.
A lot of programmers who are 35+ can struggle to find further opportunities as the more senior you are the less available those opportunities are and the more expensive you are. Lots of companies only want young people who are naive and have limited distractions outside of work. So, really, programming as a field is front loaded and the longer you stay in the business over 35 then the luckier you have been. But make sure you have an effective exit strategy to support yourself and your family when the boss doesn't like folk older than him.
Big part of why programming is front loaded is that it's an incredibly new field. The entire field hasn't existed for more than 70 years. And that was if you count "Niche academic field that a few dozen mathematicians knew about" as the start.
It didn't become like a job job until what, the mid 1960's? That's 60 years ago.
And the number of programmers is doubling every ~5 years. Of course it's front-loaded with young people! The people who have been doing this for the field's entire time of mass popularity (1980's onwards imo) haven't even had time to get proper old yet.
But also: The more experienced you are, the more your biggest value isn't in banging keys on the keyboard. A company would much rather leverage your thoughts and opinions and that may look a lot more like technical leadership than programming. Even though it's still engineering.
Hmmm as a 53 year old programmer I've had the exact opposite experience. Because of the large diversity of my skills I have more offers for work than ever before.
You’re the odd one out, perhaps due to your own abilities and other special qualities. For the average programmer ageism applies though. And the largest majority of devs is in the average region
I think it depends on your adaptability.
I know few devs over 50, but the ones I do are like the dev you reply to - they are some of the most adaptable, T shaped skills. Deep domain knowledge & experience in a couple areas and broad experience in many techs.
Another factor to consider is post-peak-comp. You may find yourself in roles when you are older that pay less than they used to. This may very well be fine because you no longer have a down payment or kids college to save for, and if you didn't keep upgrading homes.. your mortgage payments 10-20 years into owning should a smaller and smaller percent of your income. If you are no longer chasing comp, you have a broader selection of roles and can be more selective.
> For the average programmer ageism applies though
It's easy to blame ageism, and ageism is real. There are a lot of people who really resent older people and believe flat-out untrue myths about cognition, value of experience and work ethic. That said, every time a friend shares a beer with me and tells me the woes of trying to get a job when older, I hear this:
I can't get a job that pays me like I'm senior, but requires the skills of someone half my age.
The solution is to break out of that box, and either be ok with lower pay, or go for jobs that leverage the value of your experience.
> perhaps due to your own abilities and other special qualities
I'm sure if you looked at yourself, or maybe had someone look with you, that you'd find you have quite a bit to offer when it comes to ability, and especially special qualities. As you get older it's hard to understand what is special because you've seen a lot, and it all seems average.
That just isn't true in my case. I started my career in the late 90s and was the young kid at the office. So on my network is full of older developers.
Very few of them have been pushed out of the field. Yes many moved up, but the majority still code. The ones who had not moved into management are either retired (Over 65), retired early (Rich, big payday) or dead.
I keep hearing about ageism, but never encountered it. At 54, I've just landed my last job a year or two ago and age wasn't an issue. As in all things tech, I think if you have the skills that are in demand, good jobs are not too hard to find.
So the question becomes “why would a 50 year old be an average programmer?”
I am very much the “average programmer”, but I learned a long time ago how to focus on “adding business value”, talking to customers (internal and external), writing, presenting, explaining concepts to non-technical people and even once a decade ago talking to investors and potential acquirers when a startup I was working for when they wanted to talk to the “technical folks”
Not the person you are replying to. But I did it by focusing on learning soft skills and project management skills - even though I am not a project manager.
I focused on small companies before my current job where the director/CTO was looking for people who could demonstrate a history of being “smart and get things done”.
I avoided the leetCode grind by preparing for a couple of years to target the cloud consulting department of the two of the major cloud providers or if necessary one of their partners. I knew that a combination of software development, infrastructure, cloud, and soft skills would give me a competitive advantage.
I studied my ass off! I did 300 LC questions and could finish LC mediums pretty easily and I found that most companies concentrated on easy and medium.
So honest question. I presume you spent months on those LC questions.
Do you feel that they were beneficial in terms of making you a better developer, or did you simply learn a bunch of solutions to puzzles that have no bearing on real world development?
> Because of the large diversity of my skills I have more offers for work than ever before.
"offers for work" or "job offers"? "Traditional" w2 full time go-through-an-hr-dept organizations possibly have more of an ageist issue than other scenarios. Freelance/consulting seems to still offer more flexibility on the age front, but it's more of a gut sense from speaking with those in my network.
I find the “I won’t take less than $X or else I’ll stay unemployed” to be kind of weird as a career planning strategy. If there is an under-supply of senior talent, everyone accepts and expects that the clearing salary for those roles will go up. Yet, if there’s an over-supply, many people seem unable to extrapolate from the previous.
Many hiring teams will look at an experienced person as “too experienced” and won’t even offer the job to an otherwise good candidate. They justify it by saying things like “this position is too junior for them and they’ll just leave when they get bored/find a better position”, etc.
That’s another apparent sub-optimization. “We’ve been looking for a while and we’d rather keep looking than make a level-Y offer to this good candidate.”
If the candidate says “I’m only taking this to avoid starving but will quit as soon as I find any other job”, then sure, don’t make the offer. If they don’t give any signs either way, assume they’ll stay for 18-48 months as is common and decide accordingly.
The older I get, the more I think it is not the company itself but middle-managers.
Managers with an authoritarian streak will have trouble handling experienced developers that objects to non-optimal designs and processes.
It is much easier for such a manager to handle young naïve developers that gladly accept to work 5 times as many hours as a good design needs.
Software don't work well with an "do as I say, no matter how stupid it is" approach. I think that is why Silicon Valley (and Europe) has much greater success writing software than asia/India.
I manage a couple of developers that are in their late 40s. It's great. I just say, "hey, can you handle this complex, ill-defined task?" and they get it done right, the first time. No real management necessary.
An older, grizzled, battle-hardened engineer is one of a manager's best assets.
I keep hearing this. I’m 48 and between the time I was 34 and 46, bumping around in your standard enterprise corp dev jobs, I found jobs relatively quickly - the shortest time was 4 days from starting to look to having a job (corp dev at the time a F10 non tech company), the longest being two weeks. Every time besides the first, I was juggling multiple opportunities and had three offers. I change jobs 5 times during that time period.
In hindsight, until the last two in 2016 and 2018 they were just journeyman CRUD jobs with the last two being hands on dev lead and de facto “cloud architect” respectively.
I just got my first job in $BigTech at 46 two years ago. It’s not officially a “software engineering job”. But for all intents and purposes I’m doing the same type of work I did at the last couple of jobs - gathering requirements, presentations, development, and a shit ton of yaml, HCL, PowerPoint slides, and diagrams.
I’m sure at 48, I could contact my network of former coworkers, managers, recruiters and someone would give me a job even if it were just a standard .Net journeyman developer again.
If you’re still randomly submitting your resume to an ATS trying to prove yourself to companies by reversing binary trees on whiteboards while juggling bowling balls and riding a unicycle on a tightrope, you’re doing it wrong at 40+ years old.
> If you’re still randomly submitting your resume to an ATS trying to prove yourself to companies by reversing binary trees on whiteboards while juggling bowling balls and riding a unicycle on a tightrope, you’re doing it wrong at 40+ years old.
I did that at 45 and landed an interesting job at FAANG (and I'm not the only one). I think it's a bit contradictory to think old programmers are still as capable and sharp as 25 years old, and at the same time insisting to be judged on different standards.
I didn’t randomly submit my resume to get into a FAANG at 45. When the recruiter reached out to me about an SWE position (that I wasn’t interested in). I kept talking to her and she directed me to a related remote job that I was interested in (cloud consulting - enterprise app dev/cloud architect).
> the recruiter reached out to me about an SWE position (that I wasn’t interested in)
Then it's your preference not to be a programmer. My point was that it's also possible to be a SWE for those who still dig programming at our age. But you have to play by the rules. That being said, I don't think I'll last in such a position until retirement.
I spend everyday “programming” doing the same type of work I did before joining - mostly back end APIs, ETL, occasional front end work if I have to etc.
I just knew I wouldn’t enjoy being a small part of a large team coming from small companies where I could work up and down the life cycle from pre-sales, to requirement gathering, to implementation, to DevOps [sic], UAT and training.
I’m still part of a huge organization in the grand scheme of things. But my projects range from me the sole tech person doing everything to my working with a team where I lead or implement one “work stream” depending on the size of the project.
I think the point may be that, yes still as capable etc., but also with a ton more life-cycle experience in real-world development. So for someone hiring that values that experience, maybe they ask a bit more about that, and do less whiteboard work to validate that you really did go to CS school.
With a string resume, a hiring manager might think "They probably know what a binary tree is because it they didn't, they would not have made it this far."
Actually, three jobs ago back in 2015, I had two interviews. The first hiring manager asked me to do a merge sort on the whiteboard. The second company’s new director told me what problems he was having and that they were on an acquisition spree and what their plans were. He asked me how I would go about helping them.
Both interviews were about half a day, I got offers from both the company that asked me to do a merge sort paid slightly more. I accepted the second job.
Real business folks have real world problems to solve. They don’t care whether you can reverse a binary tree.
As an aside, one of the more junior people that I would be leading asked me how I would parse addresses while the director was in the room. I said I wouldn’t. I would license third party CASS software and explained all of the corner cases and then went into my speech about a company shouldn’t concentrate “on anything that doesn’t make the beer taste better”
> Real business folks have real world problems to solve. They don’t care whether you can reverse a binary tree.
I suppose it's all about the role you're applying for. There are "real business" where engineers are hired to solve technical challenges. Being able to solve simple algorithmic problems is a legitimate prerequisite for this type of role.
It’s not the role you are applying for. I’ve seen plenty of times where interviews were DS&A and the work was yet another line of business CRUD app. The job I turned down definitely was.
And let’s not pretend that all developers at BigTech are solving “hard problems”. I do have access to code for one of the major cloud providers.
I interview a lot of people and I ask all of them to write code (standard for our company). There's plenty of people that can talk about all sorts of stuff but can't code. Who do you hire to write software? Also do you want to work somewhere where software engineers can't write software? Do you want to work somewhere where the people doing the planning can't write software?
I keep hearing this like there are millions of experience developers that have spent an entire career fooling company after company without being able to code well enough to do your typical line of business CRUD app and let’s not fool ourselves. That’s all most of the 2.7 million developers are doing as far as coding.
I’m not saying the jobs are simple just that the complexity is figuring out what to write, how to organize it, how to deploy it, etc.
And before the gatekeeping starts, I programmed in assembly on four processors as a hobby by the time I graduated in 1996 and my third job around 2007 was to maintain a complete proprietary tool chain (compiler, VM (language VM), IDE) for Windows mobile. I spent my first decade plus out of college bit twiddling in C.
We do a lot of stuff that's not one line CRUD. I've no interest in people that can only do that. And let's not fool ourselves, even in orgs where they do the most vanilla stick blocks together software work there's a few people that do most of the work and lots of others that do very little. The other part of this is that there aren't that many good people looking for a job, most of them have one most of the time and when they switch it's usually through their network of connections.
You're obviously the kind of person I'd want to hire ;) Why would you mind writing some code in an interview? I don't ask anything that requires memorizing your data structures and algorithms textbook. All I'm looking for is people that can "think in code" which in the population of job seekers isn't as common as you'd think.
Don’t get me wrong. Back when I was C bit twiddling from 1999-2008, we had nothing but a compiler and no libraries besides the ones we wrote since our code had to compile across x86 PCs and a couple of mainframes. I had to implement most of the data structures myself.
I’ve had one coding interview in 25 years between 8 jobs. That one was in 2012. They had a Visual Studio IDE with skeleton code abs failing unit test and I had to make the unit tests pass as a pair programming exercise. I thought that was a very practical type of coding interview that I copied when I had to filter a bunch of contractors when I was a dev lead.
But now, if I leave my job at BigTech as a “cloud architect specializing in application modernization” - basically enterprise app dev/DevOps [sic], training, etc., before I retire, it will be at some startup looking for a more strategic role, even though I would be hands on.
It’s automatically a red flag about the job that I prefer if I’m not being asked about strategy and given a coding interview.
We do both but writing some code is a requirement. After you do that we talk (with the more senior people) about their approaches to solving bigger problems.
I very much think this is limited to the startup / work fast and break things style of companies. Always work available for sr. people at large established companies, especially fortune 500. Specifically companies where tech is not the core business product, many of them are attempting to modernize their systems. They pay pretty well too; not Google / Amazon level but on a pure salary basis many probably pay comparable to Microsoft without the shares of course. They do have a good 401k match though. A good salary for 95% of tech people.
I am early 40's and have had no issue finding work and am currently interviewing others to come work with my group in a solution architect / tech lead style role and they are all my age. I have never interviewed for a job and not gotten an offer, regardless of age; with that said I'm not interviewing at startups or places I feel really wouldn't allow me a family life. I get the offers not because I'm incredible, I'm not, but because I know my lane and skill set and stick to it.
It was even easier for me to find work at smaller companies the older I got. There were always companies that really needed someone who could help them mature their processes, who they could put out in front of customers, who knew how to work with sales, who they could send off-site and talk to their customers tech departments (B2B) etc.
It got to the point where my “interviews” were more just sitting down with directors/CTOs and talking like adults about how I would help them solve their real world business problems. I haven’t done a coding interview in over a decade even though I have been hands on all that time - across five jobs
After some frustrating experiences applying and interviewing for jobs at the kind of startup-sized companies where I’ve spent my entire career, and fearing that my age might be a factor (I’m about to turn 40), I applied on a job at a Fortune 500 and had an offer a few days later.
The pay, benefits, and work/life balance are excellent, to the point that I have some regret over not exploring this avenue sooner.
Oh, and now I’m younger than most of my coworkers again. I don’t think ageism is a thing here.
Several reasons for ageism sometimes missed. This from someone whose been discriminated against, who has hired, who now owns a company & who was also a recruiter.
__I don't agree with this__ just laying the reasons out for clarity sake:
- Hiring managers don't consider themselves ageist, but opt for younger employees whom they think make a better cultural fit. You can blame the 'work is my social life' culture that emerged in the 2000's and that persists today.
- Hiring managers don't want to be ageist, but they've had or heard of bad experiences where disgruntled or non-performing employees abuse the EEOC process for financial gain and retribution. Very well intentioned rules, designed to protect certain cohorts of employees, doing the exact opposite as is often the case with Gov regs.
- Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees.
- Money. The perception that older employees cost more in wages and benefits, without much thought to efficiency gains that accompanies gray hair.
I was age discriminated against by a well known SAAS provider, who used a 2014 interview process to extract a detailed roadmap and ideas for product growth from me, and then ghosted me. I've watched as they've (badly) implemented the specific of my roadmap the past few years, and I chuckle. 100% my fault for giving up too much value in the interview process, but it was tough time and I thought I really needed that job.
> Hiring managers don't consider themselves ageist, but
> Hiring managers don't want to be ageist, but
I classify this into the "I'm not a racist, but..." bucket.
> Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees
This is the textbook definition of what ageism is.
Conclusion? They are ageists, plain as that. They may not consider themselves to be, or want to be, but they still are, because ageist is as ageist does, and it matters jack what appearances they want to keep or what they think or who they perceive in a mirror.
I won't address "performance capacity" directly since it's too broad and vague, but it is plausible that there is diminished learning as we age. Think about learning new spoken languages. There's evidence to back the idea up in that context [0]. At the same time a 40 year old will likely have a higher proficiency at their language(s) than a 20 year old. This analogy exaggerates the idea (the trade-off) but I don't see why it wouldn't apply to programming languages as well. And this isn't ageism.
You're ignoring that most "new" language problems have significant overlap with things already experienced, and there's only a minor translation issue, rather than a learning new things from scratch issue.
Is this ageism implied for SV and like companies, or all of them in general (implied US-based anyway)?
I can't speak in either instance at this time, but I'd like to think ageism isn't nearly as widespread as it seems when discussed on here when it comes to technology-based work. E.g., Small town in Nebraska with one or two software houses versus SF.
Add 13 years, and I could have written this. I must admit I cringed a bit when the author said 40 was old. I still love what I do, and I have no desire to live the manager life of all day meetings.
I think more people would choose the IC path of there were more authority and autonomy in it.
I’ve gone the management route because I like making larger product decisions (or at least being involved in them). ICs at any level rarely get that level kind of input.
I low key blame the onslaught of product management for software as the problem. It’s pulled all the fun product stuff out of engineers hands. :(
I wonder where the genesis is of this idea that programming is young person's game akin to physical sports where speed, explosiveness and endurance matter.
It seems to me that it's an intellectual activity where one should go on for very long honing their skills and becoming better and better at it with age.
Maybe the industry sidelines the older more experienced technical folks at a cost, and that's why there seems to be a reinvention of the wheel several times in the software industry.
I'm curious if there are other technical fields that are similar to programming with regards to ageism.
Wishful thinking maybe, but open-source may help in this regard. As more and more of software is being added to the commons, those who've been there and done that can have a greater influence in driving progress.
Not only that but the younger are more maleable and gullible in some aspects but also have the better capacity (and willingness) to adapt to the tower of babel du jour.
Is it the hiring manager's objective to hire easily controllable apes that can type, or human beings that can grasp the product and business goals, shape the culture, translate technical jargon into easily understandable concepts for the uninitiated and make the employer a shit load of money by architecting and programming their vision?
Young people aren’t apes who can type, they’re bright young people whose inexperience lends them the qualities I mentioned in my previous comment. In many cases they perform quite well (but not efficiently IMO)
In my mind, young male have a lot of hormones that make them compete and it shows. There seems to be clear behavioral change in the average programmer as they age. Later in life (oftentimes with family), they do not have biological set-up to code 14 hours a day whole year as they did before.
Obviously, outcoding everybody else is sometimes considered as a value and other times it is not. Shrug.
I did, multiple times for extended periods, and it was insane, yeah. Games and movies. I prefer to not do that anymore, so in that sense I’m doing less work as I age and choose to avoid insane overtime in favor of maxing out at mild overtime. I think I’m coding better now though, more productive, partly by being more choosy, partly from more experience, partly from making more rational decisions when not low on sleep and exhausted from overwork and missing friends and family. It is sometimes a problem in the industry that you can’t tell how productive someone is by how much time they spend typing code.
I"m not sure that the common idea is that younger programmers are more skilled, but rather that they are more in demand. Could be for a variety of reasons, for example:
- cheaper
- less jaded
- easier to "manage"
- more willing to do the boring work that the older devs don't want to do
I think you're right. I also think that what tends to bore an experienced dev may be less likely to bore a junior dev, just because it's newer to them.
Chess is a primarily mental competition, but players at the top of the world tend to hit their peak at around 35 years old. Players can continue playing at an exceptionally high level until the end of their life, but on average there is a gradual downward slide from that peak. Magnus Carlsen, the current world champ and arguably strongest player of all time, has decided to simply stop defending his title (held since 2013) at the age of 31.
I think something that tech and chess may have in common as well is the ever-shifting grounds. Electrical engineering of today is not dramatically different than electrical engineering of yesterday. But programming (depending on the domain) is quite different today than yesterday. This is going to result in an age bias because at some point you start to simply become jaded learning 'Incremental, overhyped, and not strictly necessary new trendy framework/language [that nobody will be using in 10 years] #2,743.'
Keep in mind that we've seen an interesting phenomenon over the past few decades where the average peak age of professional players has been going up. This includes physical sports like baseball, football as well as things like chess, fighting games and various esports.
I think the peak age thing ends up being less due to actual aging and more due to the responsibilities of life taking time away from practice.
The reason Magnus is not defending his title has nothing to do with some decline in ability. Last game versus Nepomniachtchi he won quite convincingly 7.5 to 3.5.
>“I feel I don’t have a lot to gain, I don’t particularly like [the championship matches], and although I’m sure a match would be interesting for historical reasons and all of that, I don’t have any inclination to play and I will simply not play the match,” he said on his sponsor’s podcast. [https://www.npr.org/2022/07/20/1112479750/magnus-carlsen-wor...]
For a man that loves winning and competing as much as Magnus I find it difficult to imagine he wouldn't be playing if he felt himself a significant favorite. His last opponent is a character with a well deserved reputation for implosion. He was playing no less worse than Magnus for 6 games, in a 12 game match. He then lost a single hard fought game and did his thing, blowing up and losing 3 of the next 5 games with abysmal (by his standards) play. That could happen again, but I think it unlikely and I'd say Magnus does as well. Nepo seems to have improved his mental game, and has been in great form as well - having just dominated a very strong field in the candidates with the highest score in modern times.
Carlsen is very strong, but his title defenses have never really reflected that - ironically with the most recent exception. In the two defenses prior, he only managed to draw the classical section and relied on tiebreaks. His defeat is all but inevitable, and I think he wanted to go out undefeated. I think the one opponent he was hoping to be able to play against was Alireza Firouzja. Alireza is young and will probably become a world champion contender at some point. But Magnus would have been able to count on Alireza collapsing under the unique pressures of a world championship match and let Magnus then go out on top having undefeated having defeated champions from 3 generations. Instead Alireza collapsed at the candidates, scoring less than 50% in spite of being the (at the time) 2nd highest rated player in the world.
Chess is not programming. We have software that can beat any human chess player. We don’t have software that can beat even a mediocre software developer.
These sort of comparisons are rarely meaningful, of the way you seek to imply: We have software that can beat any human at calculating partial differential equations. We don't have software that can beat even a mediocre cat-picture-identifier at identifying cats.
I don't think programming today is that different. I've been programming since 1982 or so and I don't think it's fundamentally that different. You have to keep learning new stuff. That's the way it's always been. That's what it means to be a programmer. But the new stuff is just the old stuff and the basics are the same.
By the way, electric engineering of today is also quite different from electric engineering of the 80's. You have to learn new tools. Maybe if you work for an electric utility it's still the same though I tend to doubt that as well.
>I never understood why some people despise the term full-stack.
More for the role: full-stack has you doing multiple roles, but is not compensated as such. You're even removing the communication overhead if the role had been split in two. It seems to me as a business move to compress roles and pay you less for double the capability in exchange for varied work. I don't think people should just accept lower comp just because they prefer varied work.
I don't agree about multiple roles, backend/frontend is just one way of splitting a system. It's not like you get twice as much done in a fullstack role, you just do half as much frontend and half as much backend (in an even split role).
But why do you think fullstack is paid less? Is this a generally accepted fact?
The reduction of the communication overhead is definitely non-trivial. Though many businesses don't seem to measure the internal performance of their systems when the programs are running on and between humans. So if it works to some vague, hand wavey degree, "fine".
By relying on the idea that back/front is "just" a way of splitting a system, one could say that SRE/Front is a way of splitting a system, or Sales/Support, or Finance/HR, and so on. We're of course talking about ways of splitting the system(s) involved.
I think the spirit of the original idea is that roles are defined by boundaries. The boundaries are definitely "made up" but they aren't arbitrary. The degree of expertise and volume of knowledge needed to operate effectively (or expertly) within a role, and the ease or difficulty of obtaining those requirements, should be acknowledged when a company describes a role they are hiring for. If the bulk of your roadmap is back-end work but you want to hire full-stack devs because its nice to have everything, this seems like sloppy practice (though totally accepted).
On the other hand there are plenty of full-stack jobs that really just mean "back-end but not going to throw a contract in our face when you have to drop into the browser debugger to solve a problem". This is the kind of full stack I am. I wouldn't be okay with being asked to work on our frontend for the next year but I'm perfectly comfortable with debugging, making recommendations, doing some front-end work if it means filling a gap when resources are constrained.
In my 20+ year career, I have met very few programmers who can actually justify the claim of being full-stack. Usually it means strong back-end that happens to have worked with some front-end framework fad, and less often vice versa. Specialists (UI/UX, database admins, CI/CD engineers, automation testers, just to name a few) are still very much needed and the trend to make everybody on the team “full-stack” doesn’t work well in practice unless everyone is a 10x developer.
I have worked on ASICs, FPGAs, compilers, routers, clusters, servers, websites and mobile apps. But I would not describe myself as a "full-stack developer". To me that implies a very specific thing - a RDBMS backend coupled to heavyweight javascript framework frontend.
It's a commonly accepted view that backend developers know databases. Until it is fixed, there are two major realms now due to Google (Angular) and Microsoft (TypeScript), backend and frontend. I was once a full stack developer but refuse to touch Angular gargabe or TypeShit.
TBH you could add Architect and DevOps if they're doing architecture/writing IaC as well. These all can be individual roles. The formula doesn't necessarily have to be salary times roles, but it should be higher than specific roles like front-end, back-end, DBA, QA, architect which can all ask for high salaries on their own. In my experience, full stack jobs often have salaries on par with the specific roles which is my beef.
The biggest personal reason generalist roles should be priced higher is the time you spent to learn multiple things well enough to get a job doing them. If you accept a role as full stack that pays the same as a backend only role, you're essentially devaluing your own time. The other perks are reducing head count and giving the business that extra flexibility and convenience. If your salary doesn't reflect that, you're giving it away for free and we know how much businesses make us pay as consumers for convenience.
It might seems strange to consider a lot of factors, but you have to remember that generalists can bring quite a lot to the table.
I think the rush of boot camp grads all calling themselves full stack engineers after 3 months of working on a rails project really weakened it’s appeal. I used to call myself full stack as I genuinely can work across the stack, but I noticed it was a bad way to market myself. Now I just tailor my resume to the position much more specifically.
I learned how to code when I was twelve. I wouldn't have if I didn't in some degree enjoy the actual act of coding, the moment to moment typing on the keyboard, composing algorithms, designing data structures and logical flows. But in the back of my mind I also always regarded coding as a means to an end. Sure I became engaged in language design battles, API design philosophy, but the magic with computers was always, for me, that you could create something from nothing, this totally metaphysical creativity, really. To some extent I see this passion transgressing to other spheres, such as management, communication, planning across departments, office politics. As an adult, I don't play video games, and artistic pursuits and ideals have also become more abstract, the particularities more sedimented, incorporated in the grand scheme of Life. On top of that, the fact is that most programming jobs are glorified plumbing. I'm reconciling with the fact that the romantic days of hacking are perhaps a thing of my passed. I don't really listen to music the way I did as a teenager, so I can't expect programming to remain the same either.
I have a similar background, but still find programming very rewarding.
Not at my day job, that is and has always been a series of mundane chores. I sadly think expecting to get paid for stimulating programming is fairly unrealistic. There is just not a lot of market for solving interesting problems or designing well-optimized code.
I find other avenues to build interesting things instead. At 35, I'm able to build things that I could never have when I was 15 or 20 or 25. I have so much more experience with what works, I'm much better at identifying which decisions matter, and which corners can be cut.
Doing interesting programming work is not unrealistic, but you need to make it a priority if you care for your day job. 3D graphics, robotics, physics simulation and AI/deep learning are still exciting to me after decades.
The magic, curiosity and joy I had also faded for me once. Like you say, much of my jobs included lots of plumbing. For work the elegant solutions that gave me joy would be seen as anti-patterns. The languages I enjoy would scuffed at as being relics. The problems I enjoy seen as useless because there are already solved in bloated over complex enterprise libraries.
When I would program for myself in the weekend I wanted to work on problems that would look good on my CV. Focus on techniques and languages that will be beneficial for my carrier. Soon also my hobby coding became a lot less enjoyable.
I then decided to seperate my hobby and carrier. In my spare time I started working on the things that fascinated me. Implementing operating systems, creating software rendered 3d engines, compilers etc. All from scratch. All in my favorite language (which is Common Lisp for me). Not caring if it would bring me money once, not worrying if anybody would use it or wanting to put it on my CV once. The only reason that is to enjoy it.
Straight away the magic I felt as a kid about computers came back in full strength. It hasn't faded since. And the funny thing... I started enjoying my enterprisy work also again. Already getting my coding passion fix in another way I could appreciate my work and the way of working for what it is.
This is why I'm starring to get interested in games programming. It is so far removed from the kind of code I do for a living that it is a lot of fun and recaptured the magic of learning to code when I was 11ish.
Same here (separate hobby from career). I needed to let myself re-discover the things that made it magical, switch from resume-building as my goal, to "what would be fun for me to do now?".
I learned to code at 12 in 1986 in 65C02 assembly language. By the time I graduated from college in 1996, I had done hobby programming in assembly in four processors. I didn’t do a single side project from 1996 to present unless it was just to learn a new to me technology for my next job.
During that time, I was a part time fitness instructor as a hobby, I trained for half marathons with friends, dabbled in real estate until around 2009 (guess how that worked out), got remarried, raised two (step) sons and now my wife and I are making plans to live a digital nomad life flying across the US. Our free time will be spent sightseeing and learning Spanish well enough to have a different experience when we stay in Mexico for a few weeks later this year.
I've moved out of coding every day at work because I've gotten 'too senior' but my goal is to move jobs to get back into it and probably spend at least the next 5 years coding. What I do now is so high level that I can't see myself doing it for the next 25 years.
That will bring me close enough to 40. I don't really see me stopping coding then.
I don't get why you'd be too senior to code if you like it. And I was very surprised to see the article author calling himself an aging programmer already at 40. I'm fast approaching that age and I feel I'm more productive than ever.
At some point reading articles like this I was mildly worried about being employable as a programmer later in life. But not any longer. The amount of work seems to be ever increasing, and open positions get filled with middling talent at the face of persistent lack of skilled programmers. Seems like anyone with even a sprinkling of motivation and passion will not go without work for long.
> I don't get why you'd be too senior to code if you like it.
I don't get it either but at the company I am in.. everyone moves into positions where they code very little. It causes a lot of problems but that is how it is structured
I’m a third generation programmer which is a bit of an odd thing, but a bit lovely. My brother is also a programmer. The bits in this About just just being “wired “ ring so true to me. There are things that to me seem biological as to how you view punch cards, fortan, whatever video games are made in, and JavaScript
As a 61 year old programmer, that knew this is what I would be doing since my first exposure as a junior in high school, I can say his insights aren't too bad. But 20 more years on, things start to hit harder. My best advice is to learn to coach, even if you aren't in a coaching role. Find that young 10x team member and teach them the subtleties of the abstractions that make a difference. Don't be offended when they rewrite your code to their way of thinking so long as it did not obfuscate the lesson, that's how they will learn.
I feel like this guy could be me. As someone at about the same stage, almost every there here completely resonates. Except the "Aging" part, I expected he would be a 60+ year old programmer.
It's interesting that one can take away radically different things from a technical career.
For instance, at around the same age, I much prefer pair programming ; try to avoid remote work ; have little time for drawn-out technical discussions ; etc.
I wonder how much of these takeaways are career-path-dependent and how much are due to innate personality traits.
I'm 47 years old, I'm a staff data engineer, and the fire in me to solve problems through programming is as strong as ever, and I expect it to last until I retire. I have zero interest in managing people, but I enjoy working with colleagues and teams to solve complex problems (through as simple solutions as possible). I learn something new everyday, and my hunger for learning is insatiable.
Note: I get contacted by recruiters constantly, at least a few times a week. Yes ageism is a thing, but you if you're really good at what you do you're much more valuable than young engineers.
But you’re also more expensive and picky about where you work and what tools you’d use. That natural ignorance and inexpensiveness lends younger devs a competitive advantage
- Nope, I don't want spend my week doing 1:1 with a team.
- 40 years old and I was never so sharp as developer as now. Focused. Precise. Fearless.
- Being the most senior developer in my team, doesn't put me in any special position other than I deliver a lot of good code, I do a lot of devops tasks, i review a lot of PR and people hear me.
- I can scale my work through my peers.
- I trust and respect the managers and architects, because I understand how hard their job is.
- They trust and respect me because they know that I could do their work (and they mine) and the roles are not ranks, but choices.
I don't fear for my job. I know that in the worst case scenario, even earning 50% of my salary would be more than the average of the population and I would still have fun with that. I can work in a niche market like Java.. or hell even Cobol :)
I could earn probably double, maybe even triple my salary and then I read your comment and realized it's true. If my salary now were halved, it'd still be more than the average US income earner. I Googled "US population average salary" and they have a nice graph.
As a side note, get ready for the pitch forks, it started going up as we approached the then potential Trump era in 2016.
Yup, I could earn the double too, if i wanted to go back to office, be manager, or simply moving to Switzerland.. but as it is, is fine. We can be idealist and say: I work here because I like it, because I like the stack, because i like the product, etc.
btw in Germany, people are already sharping their pitch forks too..
I work for a large company, and I can say that context switching is also a problem here. I guess it comes down to the organization, or maybe the individual team. But yeah, there isn't a week that goes by where a development task isn't interrupted by something.
From my experience it's the opposite, the BS and distractions to work ratio in small companies has been far better and the small company also has huge chunks of work to do.
The old industry joke: "if your succeed... you will end up in marketing".
Senior staff tend to get better at spotting the standard industry cons, but I find it amazing people often think they are somehow going to outsmart company contract/IP lawyers. Legal encumbrances are often a necessary evil, but some of the agreements fresh grads eagerly sign read like a Faustian bargain.
One finds many people tend to disbelieve anyone that contradicts their personal biases, and some get indignant when told how the churn-rate for large firms will affect them personally. It is like wishful thinking bypasses years of statistics training, and basic numeracy. Many industries simply rely or a steady stream of gullible STEM kids to keep their Youth Employment Tax credits, externalize training costs, and provide stock bumps from a symbolic layoff for year-end investor reports.
I wish the Tech industry treated people better, but "it is what it is". =)
63 year-old career programmer here. I can attest that this list is pretty much a straight line to the place where I am at, with everything just dialed up a 20 year notch (hehe!)
I do want to add one more thing to the list:
* Find a well-managed team of really nice people that know more than you do.
Every part of this requirement is important, especially for generalists like me!
Challenge yourself, learn new stuff, not how to make your 500th ERP in rust instead of Java, but program 3D applications, Virtual Instruments, or move to hardware, embedded programming, IOT,...
As demonstrated by Adobe's Figma acquisition, there is plenty of opportunities in the authoring/graphic tools. So maybe you'll make the next Figma.
I am in a similar position oIf the author and I agree with most points
> I have no idea about how effective pair programming is. My desire to discover it is zero.
I used to think like that, but then, recently, I started doing pair programming with a colleague from time to time using vscode live sharing feature, and I find it amazing. Not really for the pure implementation work, but rather for the more architecture or design of things like API or data structures. I found that we are really productive spending about one hour or less together in the editor and brainstorming live the ideas.
I don't speak for my company, but in my opinion they still get more value from me, net, as a non-manager than they would as a manager. I also think some of the most valuable work I do is not in the code I write or the systems I build myself, but rather in the guidance I can give junior developers on the things they build, and the way they approach their careers. If I get can someone in her 20's or 30's to adopt a useful technique or perspective it took me much longer to acquire, everyone wins. As Andy Jassy says, "there is no compression algorithm for experience". But there is opportunity to learn from someone else's uncompressed experience so that yours going forward is that much better.
Because people are more than just the skills they have that happen to apply to their current job function. And because management requires a skill set that -- like many others -- can be attained by someone who is willing to work to attain it.
I think of it in terms of leverage. If I knew for sure that my becoming a manager would let me be a force multiplier for my team, that they would all be enough better to more than compensate for losing me as an individual contributor, I would consider making the switch. Having been a developer myself, I would have insight into what gets in their way, and I could use my managerial powers For Good™ to get those things out of their way. At least that would be my intent. I've had excellent managers who had been good developers who chose this path.
Having said all that, one of my first managers early in my career was a high-functioning developer who was moved to a leadership role because that was the default expectation. He was a terrible manager; he played favorites and treated his responsibility as authority to be wielded against those he didn't like. I was fortunate that he liked me, but he stifled the early careers of some of my friends who were at least as good at the job as I was. So there is something to be said for not having developer-to-manager as a default expectation.
Recent research suggests no positive correlation between individual performance and manager performance in the same line of work. If a company insists on moving ICs to managers, even though this is irrational, the best thing they can do is retrain their lowest performing ICs into people management roles.
51 grey beard here. Let me complain about the younguns. So much of what's out there today is, or is based on "solutions" created to solve problems that don't really exist. Rather than try to understand something so many engineers created "frameworks" to implement what was already there. Like 90% of current web stacks are just that. But new engineers are trained on that stuff and think it's the only way. That frustrates the hell out of me.
I sort of know what you are saying. Being dealing with so-called "server-side rendering" v.s. "static generated" recently, and these feel old / boring. It has been 15 years and mostly the same thing reinvented.
However, it is not a negatively thing. We may be able to setup IIS / Apache with Squid two decades ago to do similar things. The bar to do it now is much lower, and the tooling to help achieve that is much better overall (there are some not-so-great: Figma is a great design tool, but it doesn't translate to code directly unlike Dreamweaver / Borland VCL / Visual Basic, but I heard Framer is doing good on that front). That is part of the reason why there are so much more participation of labor in this industry: it is more graphical and easier to do (even terminal tools, largely do the similar things, are much more graphical nowadays!).
Seeing all the JavaScript kiddies rediscover the speed and UX benefits of not using massive front-end JavaScript libraries to display simple web pages in the last few months has been alternatively hilarious and frustrating to me.
I feel it never really was about denying how effective plain web pages are but rather that faced with the choice of a wonderful DX with just JS, and a more difficult day to day with a mix of both, we picked the first. Sometimes at the expense of the end user, yaddi yaddi yadda, etc.
Good solutions for the "have your cake and eat it" scenario with exceptionally good DX are just now reaching some maturity.
My company has a tech stack consisting of all the latest and greatest devops/tooling/cloud services, and an old timer like me wonders if that could have been just implemented as one C++ binary running somewhere.
I share this frustration, but I think the root cause of the frustration is the difference between what I feel should be important, and what actually is important to people.
Getting great reliable software delivered quickly, which is easy to maintain and change, should be the goal, I feel. But if that’s the case, why do people invent problems to find solutions to, why do people spend multiple days a week in Scrum meetings, etc.?
But looking at everyone involved and their actual incentives:
- For a consultant, the objective is to maximize the billable hours.
- For the employee, to get modern skills on their CV.
- For the junior programmer, there is a more level playing field with the seniors when tech is used that’s new and nobody knows, vs. tech the seniors know well and they don’t.
- For the manager or owner of a product company, they want less stress having to make decisions and as long as the product makes money who cares if the software could be delivered 50% or 70% faster?
The psychological aspect of consultants and even employees trying to play a game with billable hours aside, a lot of developers of all ages genuinely feel using frameworks to do the exact same thing one can achieve with far less hubbub is a good thing, and they have trouble defending it. It's a cargo cult by all standards.
Many of us are living this now. If it's not the chasing of new frameworks, it is old frameworks no longer being actively supported, or key features never being developed. Then it turns out something like vanilla HTML + JS can do the job just fine, but you need to update everything to vanilla to make it uniform.
I think the issue is the batteries included approach taken nowadays.
Many developers nowadays seem to expect to be able to just wire things together without actual writing much algorithmic code. And the solutions have catered to that.
Those of us that are older lament the idea of using frameworks to increase our productivity, but still being more than glorified middle-men.
Why reinvent the wheel? I’ve seen “architects” who didn’t think they needed Entity Framework and went about solving the same problems (mostly around change tracking) very badly. Give me a widely supported framework any day over a badly written unsupported in house solution.
Sometime frameworks are a real help, sometime using it is just making thing bloated and it's hard-linking the future to someone who have the knowledge of the framework.
I would much rather “hard link” the future to a publicly available documented framework than one that a single person who thought their problem was a special snowflake wrote.
Which is why I've been paid good money to both maintain and bring up to speed old RoR applications that were so out of date you had to manually patch the C libraries just to get it working.
This attitude is common, that these frameworks are not, themselves, dependencies to be managed and protected from.
In medium and large organizations, manager pay and influence is mostly related to the number of employees managed and the size of their budget. Managers maximizing these two variables explains a lot of behavior that seems unreasonable to employees.
As a consultant, I try to reduce my billable hours as much as possible, then charge an appropriate amount for the value I have created, not the time spent, and this leaves me more time for more clients or leisure.
I can't speak to the prevalence of this mentality, but it rings true for my consultancy. The idea of maximizing hours is absurd. We do everything we can to minimize hours, thus maximizing value to the client. That's how we keep our clients happy, and make room for more business.
There’s a legit issue in there, but us old’ns might have to own up to some of the problems we’ve caused (or even just failed to solve) and the legacy we’re leaving. ;) I’m mostly joking, but I honestly don’t think this is a young vs old issue, I think it’s a byproduct of happening to live through the time when the internet took over the earth right while programming exploded as a career. The amount of choice, complexity, scale, and expectation in software today is so much higher than it was 20 years ago.
Putting together a decent web app today that is competitive with what’s out there and doing it in a reasonable amount of time is something that just requires frameworks and library mashing. Even though I can fully empathize with your comment, from experience, and even though my beard is almost as grey, piling stuff I don’t understand together from yarn or npm is exactly how I start a new web app. My job recently switched from web to hardware, and the workflow changed dramatically into writing and scrutinizing every line of code, and complied instruction even. But even still in the hardware company there is an overwhelming sea of choice and complexity and an army of young and old programmers all borrowing and reusing code at all times, with everyone just treading water and understanding only the tiniest sliver of it all.
I think we have no choice but to embrace the fact that it’s no longer possible to avoid swimming in 90% code you can’t control or understand, and figure out how to better manage it and encourage people to snorkel under the surface whenever they can. I don’t think we should blame it on the kids though, they’re just trying to get by the same way we did, but in a different world than we had. The good ones will still shine through and be amazing, and the rest can learn their mistakes the long way just like we did when we were young and obstinate.
I definitely had some fears about it, and there are things I miss about web, but it was easier than I expected. I was reasonably prepared though, and it wasn’t as big a jump as my comment above might have made it sound, since I was doing C++ and video game programming before doing web dev, and my hardware job is centered around graphics and is still mostly software work.
I once had an experience where I asked a younger developer why they didn't use cookies for a solution they were using JWT's for. Their answer? They didn't know how to use cookies.
I was bemused, their solution worked just fine, it's just all the extra infra needed when compared to cookies, which would have solved the problem just fine.
I'm in my mid-40's and I would apply that observation to scrum (and software dev in general). What I tend to see are a lot of very earnest people who are legitimately trying and the behaviors often associated with scrum are what they've been taught works.
Truly understanding what goes into successful software dev takes years of work and is more craft than algorithm, so I can understand the challenges.
The only thing I hate more than the ckusterfuck of the modern front end ecosystem is coming behind an “Architect” who doesn’t think they need them and reinventing the wheel badly.
If you're talking about web applications then I tend to disagree. The SaaS paradigm and the UI living in a browser are relatively new ideas that are still maturing. I don't think there is a lot of good "what was already there" and we're just seeing the evolution of tooling for this ecosystem, not completely decoupled from the evolution of the large companies that rely on this tooling. Not sure it's worth getting frustrated about... I tend to just stay away from it because I prefer to work in areas that are less fluid. And sure, sometimes there's just Not Invented Here syndrome and let's reinvent the wheel instead of using existing wheels. Nothing new about that either, it's always been like that.
All that said, the principles of how everything works are unchanged. People that only learn to use a framework are just not good software developers. People that understand the principles can work in any framework. This has always been true and is still true. There's a shortage of people that really know their sh*t and there's always been as well. That's great... I'll never run out of work (I might run out of motivation ;) ).
At 64 years I am still going strong. I consider myself blessed that I have landed a position that allows the to be the leader (I manage a small team) and still be hands on with everything: Architecture, desgin, coding, infrastructure, cloud engineering, DevOps engineer, DBA, the list goes on. It is a Goldilocks job. The technologies that we manage and master are miriad. We are a small company and my team owns the entire space. All my years of knowledge and experience enable me to be coach, mentor, and teacher. Over the course of my 44 year career I have played every instrument in the band. I manage with a socratic method which my team enjoys. Because I have been a life long learner, I have sought out and explored new technologies with eagerness and hunger. This enables me to lead the team to adopt some of these technologies in usefull and vaulable (to the enterprise) ways. The team absolutly enjoys learning and applying new and emerging technologies. I could not have asked for more from what will probably be the last gig of my career. I don't intend to retire until 70 (assuming I am that lucky - you'll know what I mean when you get here). I am having so much fun I wish had 30 more years ahead to enjoy what comes next. I always like to say: It's good work if you can get it - not everybody can.
People who can manage and code (architect, etc.) are truly rare. I'm not quite at the same age and only play the guitar. Like the article author and where we differ, I am very skeptical of new technologies, if I can't find a use for it in my personal software projects without having to hold my nose, there's no way I will recommend it for work.
"People who can manage and code (architect, etc.) are truly rare."
It's not that difficult if you actually can make decisions quickly. It only gets difficult once you are in a bigger company where you have multiple more or less competent stakeholders and every decision get accompanied by multiple meetings.
> People who can manage and code (architect, etc.) are truly rare.
I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons... but every time I've promoted a reluctant leader it's been magical for that person and for their team. A lot of times the people that self-promote and like to be in charge should never, ever be given athority.
> I am very skeptical of new technologies
I used to think that way until I realized that in a lot of cases, we've been re-inventing the same concepts in computing since the 1960s. I think a lot of the re-invention is really being driven by hardware capabilities, languages and fashion. We're seeing it with Rust right now - let's rewrite all the things in Rust! Underneath it all, though, the payoff for using new, less capable tech, is that eventually it will pass up the old in a very meaningful way - and when it does, systems build on the old are washed away.
> > People who can manage and code (architect, etc.) are truly rare.
> I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons...
Note that you are talking about different things from OP.
OP was talking about managing, you are talking about leading. These are two very distinct skills. Sometimes you can find both in the same person, but these people are few and far between, since each of these roles is already a full time job.
> OP was talking about managing, you are talking about leading. These are two very distinct skills.
Everything I've experienced in my professional life has taught me this: managers who can't lead can't manage, and leaders who can't manage cannot lead. Never once have I worked for a manager who didn't see themselves as a leader, and never once have I met someone who called themselves a leader who wasn't management.
People who are stellar managers, have extremely high empathy and EQ, understand their engineers, prop them up, help their career, guide them toward both professional and personal growth. They also did not have a single ounce of leadership or charisma in them, very low technical chops, no vision, and not interested in providing team leadership.
I've also met stellar leaders, visionaries, who inspired, entranced teams with every single word that came out of their mouth. They provided short and long term directions, technical and product guidance, motivation. And they were absolutely terrible human managers. Could not place themselves in other people's shoes. Didn't really care about managing the career or growth of people on their teams. Were only focused on matters that did not involve any human feelings.
These kinds of people both have their places and they complement each other wonderfully.
And sometimes, you find these two very distinct, polar opposite qualities, in one single person. But like I said, this is much more the exception than the rule.
And of course, the reality is that most people lie on a spectrum between these two extremes.
You have provided a wonderfully elegant description of the two ends of this spectrum. Spectrum is a perfect term to use becasue technical leaders who become managers exist on that spectrum in very dynamic ways. Everyone is surrounded by 360 degrees of team members who have different perspectives, expectations, needs, wants, etc. No one can be all things for all people at all times. For my own experience, depending on who you ask - my peers, my leaders, my reports, they will all have varying opinions of how I land on that spectrum and what it means to them. And if you ask this month and ask again next month their perspective may change both positively and negatively. You have to keep trying and growing and learning. You also have to be agile and flexible. Let go of the past and focus on the future. Assume best intentions about everyone. There is no perfect. Its all about the journey.
Leading and managing are two separate skills there are plenty of tech leads who neither have to nor want to deal with managing people, 1x1’s, worrying about others career development, etc.
A leader can lead initiatives just via building relationship and having expertise without role power or any reports.
> but every time I've promoted a reluctant leader it's been magical for that person and for their team.
I was hired at my last job by the then new CTO to lead the “cloud application modernization” effort as they were pivoting to providing access to micro services to large health care companies.
After being somewhat successful at it, he offered to make me a team lead (been there done that). I told him in no uncertain terms that I would quit first. We had a great working relationship.
I now do basically the same thing in the consulting department at BigTech as a middle level hands on consultant.
I asked a year end could my position be considered a “terminal position” or would I need to work toward a promotion. My manager asked me why. Again I was very honest. I needed to know because I would be looking for another job before seeking a promotion. He said it could be a terminal position,
> we've been re-inventing the same concepts in computing since the 1960s. I think a lot of the re-invention is really being driven by hardware capabilities, languages and fashion. We're seeing it with Rust right now
I often hear the argument that there is nothing really new in programming and that everything was already done in some way or other back in the 1960s.
I completely disagree with this and find it harmful. There is genuine innovation and new research happening in computer science all the time. The example you gave, the Rust language, is based on linear type theory that was first developed in the 1990s. Nothing like it existed in the 1960s and that is why it offers real improvement to software development.
Today, software development is slow, buggy, expensive and late. We owe it to ourselves to continue to research and search out ways to improve our craft. And this is happening. Newer programming languages and tools DO incorporate innovations from recent computer science research and are better for it. We should celebrate this rather than cynically pretend that all computer science research halted in 1969.
Socratic approach has something to do with asking questions instead of giving directions. I guess, instead of saying "You're an idiot if you think this works in concurrent setting...", one should say: "What do you think would happen if we run this concurrently? Are you an idiot?" :)
Very little of what we do as developers or software engineers is transactional. This is very creative work we do. So I don't take status about anything that they are doing. Rather I discuss all aspects of the problem they are trying to solve. Or ask questions about how they approach solving those those problems. I usually enter the conversation with the same verbal queue: "indulge me while think out loud about this....". We discuss concepts like technical debt or design patterns or junky data in our database and how to improve data quality. I also deliberately avoid creating artificial time boundaries. Everyone knows I prioritize quality and stability. (faster, better, cheaper - it's always better)
This post and its comments warm my soul. At 33 and a decade in, I’ve only recently started to worry about what the tech world in general is telling me:
That I have to become a manager.
That I won’t always code until I retire.
That I won’t be welcome in the workforce in my later years.
All of those things frighten me! I love programming, and I want to be doing it in my 60s, happily. Glad to see that people are.
Do not worry. Your every day startup may not (because their teenager culture), but the enterprises of the world love you. I am now crossing in my mid forties, being a paper dragon (architect) I still outperform the waste majority of developers in our groups. I have their respect and they have mine.
However, idle you never can be. Because being of age and not being able to run with the pack is bad. Luckily, it is not the framework of the day but more the soft skills which make the difference.
374 comments
[ 2.3 ms ] story [ 317 ms ] threadIf you expect to retire at 60 (likely 65 these days) and you start working at 20: 40 is smack dab in the middle of your career.
I think that notion gets lost when we talk about ageism in tech and then people talk about 40-somethings.
but those are still of small group, it's like a normal distribution, I read somewhere age wise there are only about 1.5% that are above 50s.
Of course you're not going to hire a woman if you could hire a man - they might get pregnant and be away from work for a long time.
Of course you're not going hire an older employee that knows their worth over a recent graduate that isn't familiar with the salary they should earn. You can rip them off much more easily.
People can be cunts but still act with some rational motivation. That's why we have protected categories, to make sure that that isn't a strategy worth pursuing.
that's the real problem, self and situational-awareness.
i like the points in this thread. perhaps aging is just a natural bad actor filter. options narrow as we wise up.
this is the one thing you said I disagree with, unless you mean dealing with it by eliminating it.
It didn't become like a job job until what, the mid 1960's? That's 60 years ago.
And the number of programmers is doubling every ~5 years. Of course it's front-loaded with young people! The people who have been doing this for the field's entire time of mass popularity (1980's onwards imo) haven't even had time to get proper old yet.
But also: The more experienced you are, the more your biggest value isn't in banging keys on the keyboard. A company would much rather leverage your thoughts and opinions and that may look a lot more like technical leadership than programming. Even though it's still engineering.
Only an asshole cares how old somebody is. Reminder also, ageism isn't just a bummer, it's illegal.
Most people aren't going to take legal action, but imo if you're discriminated against you have somewhat of an obligation to do so.
Another factor to consider is post-peak-comp. You may find yourself in roles when you are older that pay less than they used to. This may very well be fine because you no longer have a down payment or kids college to save for, and if you didn't keep upgrading homes.. your mortgage payments 10-20 years into owning should a smaller and smaller percent of your income. If you are no longer chasing comp, you have a broader selection of roles and can be more selective.
It's easy to blame ageism, and ageism is real. There are a lot of people who really resent older people and believe flat-out untrue myths about cognition, value of experience and work ethic. That said, every time a friend shares a beer with me and tells me the woes of trying to get a job when older, I hear this:
I can't get a job that pays me like I'm senior, but requires the skills of someone half my age.
The solution is to break out of that box, and either be ok with lower pay, or go for jobs that leverage the value of your experience.
> perhaps due to your own abilities and other special qualities
I'm sure if you looked at yourself, or maybe had someone look with you, that you'd find you have quite a bit to offer when it comes to ability, and especially special qualities. As you get older it's hard to understand what is special because you've seen a lot, and it all seems average.
Very few of them have been pushed out of the field. Yes many moved up, but the majority still code. The ones who had not moved into management are either retired (Over 65), retired early (Rich, big payday) or dead.
I am very much the “average programmer”, but I learned a long time ago how to focus on “adding business value”, talking to customers (internal and external), writing, presenting, explaining concepts to non-technical people and even once a decade ago talking to investors and potential acquirers when a startup I was working for when they wanted to talk to the “technical folks”
I focused on small companies before my current job where the director/CTO was looking for people who could demonstrate a history of being “smart and get things done”.
I avoided the leetCode grind by preparing for a couple of years to target the cloud consulting department of the two of the major cloud providers or if necessary one of their partners. I knew that a combination of software development, infrastructure, cloud, and soft skills would give me a competitive advantage.
Do you feel that they were beneficial in terms of making you a better developer, or did you simply learn a bunch of solutions to puzzles that have no bearing on real world development?
"offers for work" or "job offers"? "Traditional" w2 full time go-through-an-hr-dept organizations possibly have more of an ageist issue than other scenarios. Freelance/consulting seems to still offer more flexibility on the age front, but it's more of a gut sense from speaking with those in my network.
If the candidate says “I’m only taking this to avoid starving but will quit as soon as I find any other job”, then sure, don’t make the offer. If they don’t give any signs either way, assume they’ll stay for 18-48 months as is common and decide accordingly.
The older I get, the more I think it is not the company itself but middle-managers.
Managers with an authoritarian streak will have trouble handling experienced developers that objects to non-optimal designs and processes.
It is much easier for such a manager to handle young naïve developers that gladly accept to work 5 times as many hours as a good design needs.
Software don't work well with an "do as I say, no matter how stupid it is" approach. I think that is why Silicon Valley (and Europe) has much greater success writing software than asia/India.
An older, grizzled, battle-hardened engineer is one of a manager's best assets.
In hindsight, until the last two in 2016 and 2018 they were just journeyman CRUD jobs with the last two being hands on dev lead and de facto “cloud architect” respectively.
I just got my first job in $BigTech at 46 two years ago. It’s not officially a “software engineering job”. But for all intents and purposes I’m doing the same type of work I did at the last couple of jobs - gathering requirements, presentations, development, and a shit ton of yaml, HCL, PowerPoint slides, and diagrams.
I’m sure at 48, I could contact my network of former coworkers, managers, recruiters and someone would give me a job even if it were just a standard .Net journeyman developer again.
If you’re still randomly submitting your resume to an ATS trying to prove yourself to companies by reversing binary trees on whiteboards while juggling bowling balls and riding a unicycle on a tightrope, you’re doing it wrong at 40+ years old.
I did that at 45 and landed an interesting job at FAANG (and I'm not the only one). I think it's a bit contradictory to think old programmers are still as capable and sharp as 25 years old, and at the same time insisting to be judged on different standards.
Then it's your preference not to be a programmer. My point was that it's also possible to be a SWE for those who still dig programming at our age. But you have to play by the rules. That being said, I don't think I'll last in such a position until retirement.
I just knew I wouldn’t enjoy being a small part of a large team coming from small companies where I could work up and down the life cycle from pre-sales, to requirement gathering, to implementation, to DevOps [sic], UAT and training.
I’m still part of a huge organization in the grand scheme of things. But my projects range from me the sole tech person doing everything to my working with a team where I lead or implement one “work stream” depending on the size of the project.
With a string resume, a hiring manager might think "They probably know what a binary tree is because it they didn't, they would not have made it this far."
Both interviews were about half a day, I got offers from both the company that asked me to do a merge sort paid slightly more. I accepted the second job.
Real business folks have real world problems to solve. They don’t care whether you can reverse a binary tree.
As an aside, one of the more junior people that I would be leading asked me how I would parse addresses while the director was in the room. I said I wouldn’t. I would license third party CASS software and explained all of the corner cases and then went into my speech about a company shouldn’t concentrate “on anything that doesn’t make the beer taste better”
I suppose it's all about the role you're applying for. There are "real business" where engineers are hired to solve technical challenges. Being able to solve simple algorithmic problems is a legitimate prerequisite for this type of role.
And let’s not pretend that all developers at BigTech are solving “hard problems”. I do have access to code for one of the major cloud providers.
I’m not saying the jobs are simple just that the complexity is figuring out what to write, how to organize it, how to deploy it, etc.
And before the gatekeeping starts, I programmed in assembly on four processors as a hobby by the time I graduated in 1996 and my third job around 2007 was to maintain a complete proprietary tool chain (compiler, VM (language VM), IDE) for Windows mobile. I spent my first decade plus out of college bit twiddling in C.
You're obviously the kind of person I'd want to hire ;) Why would you mind writing some code in an interview? I don't ask anything that requires memorizing your data structures and algorithms textbook. All I'm looking for is people that can "think in code" which in the population of job seekers isn't as common as you'd think.
I’ve had one coding interview in 25 years between 8 jobs. That one was in 2012. They had a Visual Studio IDE with skeleton code abs failing unit test and I had to make the unit tests pass as a pair programming exercise. I thought that was a very practical type of coding interview that I copied when I had to filter a bunch of contractors when I was a dev lead.
But now, if I leave my job at BigTech as a “cloud architect specializing in application modernization” - basically enterprise app dev/DevOps [sic], training, etc., before I retire, it will be at some startup looking for a more strategic role, even though I would be hands on.
It’s automatically a red flag about the job that I prefer if I’m not being asked about strategy and given a coding interview.
I am early 40's and have had no issue finding work and am currently interviewing others to come work with my group in a solution architect / tech lead style role and they are all my age. I have never interviewed for a job and not gotten an offer, regardless of age; with that said I'm not interviewing at startups or places I feel really wouldn't allow me a family life. I get the offers not because I'm incredible, I'm not, but because I know my lane and skill set and stick to it.
It got to the point where my “interviews” were more just sitting down with directors/CTOs and talking like adults about how I would help them solve their real world business problems. I haven’t done a coding interview in over a decade even though I have been hands on all that time - across five jobs
After some frustrating experiences applying and interviewing for jobs at the kind of startup-sized companies where I’ve spent my entire career, and fearing that my age might be a factor (I’m about to turn 40), I applied on a job at a Fortune 500 and had an offer a few days later.
The pay, benefits, and work/life balance are excellent, to the point that I have some regret over not exploring this avenue sooner.
Oh, and now I’m younger than most of my coworkers again. I don’t think ageism is a thing here.
Several reasons for ageism sometimes missed. This from someone whose been discriminated against, who has hired, who now owns a company & who was also a recruiter.
__I don't agree with this__ just laying the reasons out for clarity sake:
- Hiring managers don't consider themselves ageist, but opt for younger employees whom they think make a better cultural fit. You can blame the 'work is my social life' culture that emerged in the 2000's and that persists today.
- Hiring managers don't want to be ageist, but they've had or heard of bad experiences where disgruntled or non-performing employees abuse the EEOC process for financial gain and retribution. Very well intentioned rules, designed to protect certain cohorts of employees, doing the exact opposite as is often the case with Gov regs.
- Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees.
- Money. The perception that older employees cost more in wages and benefits, without much thought to efficiency gains that accompanies gray hair.
I was age discriminated against by a well known SAAS provider, who used a 2014 interview process to extract a detailed roadmap and ideas for product growth from me, and then ghosted me. I've watched as they've (badly) implemented the specific of my roadmap the past few years, and I chuckle. 100% my fault for giving up too much value in the interview process, but it was tough time and I thought I really needed that job.
> Hiring managers don't want to be ageist, but
I classify this into the "I'm not a racist, but..." bucket.
> Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees
This is the textbook definition of what ageism is.
Conclusion? They are ageists, plain as that. They may not consider themselves to be, or want to be, but they still are, because ageist is as ageist does, and it matters jack what appearances they want to keep or what they think or who they perceive in a mirror.
[0] https://www.scientificamerican.com/article/at-what-age-does-....
I can't speak in either instance at this time, but I'd like to think ageism isn't nearly as widespread as it seems when discussed on here when it comes to technology-based work. E.g., Small town in Nebraska with one or two software houses versus SF.
I think with software jobs paying what they do, retiring at 50 would be pretty easy.
Not all software engineers are paid ludicrous money though, and even in places that they are paid well the cost of living can be atrocious.
I’ve gone the management route because I like making larger product decisions (or at least being involved in them). ICs at any level rarely get that level kind of input.
I low key blame the onslaught of product management for software as the problem. It’s pulled all the fun product stuff out of engineers hands. :(
It seems to me that it's an intellectual activity where one should go on for very long honing their skills and becoming better and better at it with age.
Maybe the industry sidelines the older more experienced technical folks at a cost, and that's why there seems to be a reinvention of the wheel several times in the software industry.
I'm curious if there are other technical fields that are similar to programming with regards to ageism.
Wishful thinking maybe, but open-source may help in this regard. As more and more of software is being added to the commons, those who've been there and done that can have a greater influence in driving progress.
> better capacity (and willingness) to adapt to the tower of babel du jour
this all sounds like you're describing people who can type and do what they are told.
and: we're all apes who can type.
edit: age is irrelevant. my point isn't that older people are better hires. hire for skill.
Obviously, outcoding everybody else is sometimes considered as a value and other times it is not. Shrug.
- cheaper
- less jaded
- easier to "manage"
- more willing to do the boring work that the older devs don't want to do
- more likely to be on call or work extra hours
- less likely to retire next year
No body wants to do the boring work. I think more experienced devs realize that a boring assignment isn't personal, its just business.
I think something that tech and chess may have in common as well is the ever-shifting grounds. Electrical engineering of today is not dramatically different than electrical engineering of yesterday. But programming (depending on the domain) is quite different today than yesterday. This is going to result in an age bias because at some point you start to simply become jaded learning 'Incremental, overhyped, and not strictly necessary new trendy framework/language [that nobody will be using in 10 years] #2,743.'
Chess is not a good analogy. It is a singular context. The real advantages that being over 35 and programming brings are:
- You are able to juggle much larger and different contexts at the same time - You have immense foresight that enables you to architect larger things
I think the peak age thing ends up being less due to actual aging and more due to the responsibilities of life taking time away from practice.
>“I feel I don’t have a lot to gain, I don’t particularly like [the championship matches], and although I’m sure a match would be interesting for historical reasons and all of that, I don’t have any inclination to play and I will simply not play the match,” he said on his sponsor’s podcast. [https://www.npr.org/2022/07/20/1112479750/magnus-carlsen-wor...]
Carlsen is very strong, but his title defenses have never really reflected that - ironically with the most recent exception. In the two defenses prior, he only managed to draw the classical section and relied on tiebreaks. His defeat is all but inevitable, and I think he wanted to go out undefeated. I think the one opponent he was hoping to be able to play against was Alireza Firouzja. Alireza is young and will probably become a world champion contender at some point. But Magnus would have been able to count on Alireza collapsing under the unique pressures of a world championship match and let Magnus then go out on top having undefeated having defeated champions from 3 generations. Instead Alireza collapsed at the candidates, scoring less than 50% in spite of being the (at the time) 2nd highest rated player in the world.
By the way, electric engineering of today is also quite different from electric engineering of the 80's. You have to learn new tools. Maybe if you work for an electric utility it's still the same though I tend to doubt that as well.
More for the role: full-stack has you doing multiple roles, but is not compensated as such. You're even removing the communication overhead if the role had been split in two. It seems to me as a business move to compress roles and pay you less for double the capability in exchange for varied work. I don't think people should just accept lower comp just because they prefer varied work.
But why do you think fullstack is paid less? Is this a generally accepted fact?
By relying on the idea that back/front is "just" a way of splitting a system, one could say that SRE/Front is a way of splitting a system, or Sales/Support, or Finance/HR, and so on. We're of course talking about ways of splitting the system(s) involved.
I think the spirit of the original idea is that roles are defined by boundaries. The boundaries are definitely "made up" but they aren't arbitrary. The degree of expertise and volume of knowledge needed to operate effectively (or expertly) within a role, and the ease or difficulty of obtaining those requirements, should be acknowledged when a company describes a role they are hiring for. If the bulk of your roadmap is back-end work but you want to hire full-stack devs because its nice to have everything, this seems like sloppy practice (though totally accepted).
On the other hand there are plenty of full-stack jobs that really just mean "back-end but not going to throw a contract in our face when you have to drop into the browser debugger to solve a problem". This is the kind of full stack I am. I wouldn't be okay with being asked to work on our frontend for the next year but I'm perfectly comfortable with debugging, making recommendations, doing some front-end work if it means filling a gap when resources are constrained.
Of course, they can't test their own code manually. That's two roles: developer and QA!
So a backend developer is at least 3 roles of work. Are you making 3x the salary you should be?
The biggest personal reason generalist roles should be priced higher is the time you spent to learn multiple things well enough to get a job doing them. If you accept a role as full stack that pays the same as a backend only role, you're essentially devaluing your own time. The other perks are reducing head count and giving the business that extra flexibility and convenience. If your salary doesn't reflect that, you're giving it away for free and we know how much businesses make us pay as consumers for convenience.
It might seems strange to consider a lot of factors, but you have to remember that generalists can bring quite a lot to the table.
Not at my day job, that is and has always been a series of mundane chores. I sadly think expecting to get paid for stimulating programming is fairly unrealistic. There is just not a lot of market for solving interesting problems or designing well-optimized code.
I find other avenues to build interesting things instead. At 35, I'm able to build things that I could never have when I was 15 or 20 or 25. I have so much more experience with what works, I'm much better at identifying which decisions matter, and which corners can be cut.
Works for me in ML.
When I would program for myself in the weekend I wanted to work on problems that would look good on my CV. Focus on techniques and languages that will be beneficial for my carrier. Soon also my hobby coding became a lot less enjoyable.
I then decided to seperate my hobby and carrier. In my spare time I started working on the things that fascinated me. Implementing operating systems, creating software rendered 3d engines, compilers etc. All from scratch. All in my favorite language (which is Common Lisp for me). Not caring if it would bring me money once, not worrying if anybody would use it or wanting to put it on my CV once. The only reason that is to enjoy it.
Straight away the magic I felt as a kid about computers came back in full strength. It hasn't faded since. And the funny thing... I started enjoying my enterprisy work also again. Already getting my coding passion fix in another way I could appreciate my work and the way of working for what it is.
During that time, I was a part time fitness instructor as a hobby, I trained for half marathons with friends, dabbled in real estate until around 2009 (guess how that worked out), got remarried, raised two (step) sons and now my wife and I are making plans to live a digital nomad life flying across the US. Our free time will be spent sightseeing and learning Spanish well enough to have a different experience when we stay in Mexico for a few weeks later this year.
That will bring me close enough to 40. I don't really see me stopping coding then.
At some point reading articles like this I was mildly worried about being employable as a programmer later in life. But not any longer. The amount of work seems to be ever increasing, and open positions get filled with middling talent at the face of persistent lack of skilled programmers. Seems like anyone with even a sprinkling of motivation and passion will not go without work for long.
I don't get it either but at the company I am in.. everyone moves into positions where they code very little. It causes a lot of problems but that is how it is structured
I had a brief stint as a manager, ended up doing more coding than my team. That was the moment I decided to step back into coding again.
For me, coding is puzzle solving or playing with Lego. It is therapeutic. If someone can continue to pay me to play, why not!
Yup.
For instance, at around the same age, I much prefer pair programming ; try to avoid remote work ; have little time for drawn-out technical discussions ; etc.
I wonder how much of these takeaways are career-path-dependent and how much are due to innate personality traits.
Note: I get contacted by recruiters constantly, at least a few times a week. Yes ageism is a thing, but you if you're really good at what you do you're much more valuable than young engineers.
- Nope, I don't want spend my week doing 1:1 with a team.
- 40 years old and I was never so sharp as developer as now. Focused. Precise. Fearless.
- Being the most senior developer in my team, doesn't put me in any special position other than I deliver a lot of good code, I do a lot of devops tasks, i review a lot of PR and people hear me.
- I can scale my work through my peers.
- I trust and respect the managers and architects, because I understand how hard their job is.
- They trust and respect me because they know that I could do their work (and they mine) and the roles are not ranks, but choices.
I don't fear for my job. I know that in the worst case scenario, even earning 50% of my salary would be more than the average of the population and I would still have fun with that. I can work in a niche market like Java.. or hell even Cobol :)
As a side note, get ready for the pitch forks, it started going up as we approached the then potential Trump era in 2016.
btw in Germany, people are already sharping their pitch forks too..
So large companies only?
Senior staff tend to get better at spotting the standard industry cons, but I find it amazing people often think they are somehow going to outsmart company contract/IP lawyers. Legal encumbrances are often a necessary evil, but some of the agreements fresh grads eagerly sign read like a Faustian bargain.
One finds many people tend to disbelieve anyone that contradicts their personal biases, and some get indignant when told how the churn-rate for large firms will affect them personally. It is like wishful thinking bypasses years of statistics training, and basic numeracy. Many industries simply rely or a steady stream of gullible STEM kids to keep their Youth Employment Tax credits, externalize training costs, and provide stock bumps from a symbolic layoff for year-end investor reports.
I wish the Tech industry treated people better, but "it is what it is". =)
I do want to add one more thing to the list:
* Find a well-managed team of really nice people that know more than you do.
Every part of this requirement is important, especially for generalists like me!
If you find this, life becomes lemonade.
As demonstrated by Adobe's Figma acquisition, there is plenty of opportunities in the authoring/graphic tools. So maybe you'll make the next Figma.
> I have no idea about how effective pair programming is. My desire to discover it is zero.
I used to think like that, but then, recently, I started doing pair programming with a colleague from time to time using vscode live sharing feature, and I find it amazing. Not really for the pure implementation work, but rather for the more architecture or design of things like API or data structures. I found that we are really productive spending about one hour or less together in the editor and brainstorming live the ideas.
I think of it in terms of leverage. If I knew for sure that my becoming a manager would let me be a force multiplier for my team, that they would all be enough better to more than compensate for losing me as an individual contributor, I would consider making the switch. Having been a developer myself, I would have insight into what gets in their way, and I could use my managerial powers For Good™ to get those things out of their way. At least that would be my intent. I've had excellent managers who had been good developers who chose this path.
Having said all that, one of my first managers early in my career was a high-functioning developer who was moved to a leadership role because that was the default expectation. He was a terrible manager; he played favorites and treated his responsibility as authority to be wielded against those he didn't like. I was fortunate that he liked me, but he stifled the early careers of some of my friends who were at least as good at the job as I was. So there is something to be said for not having developer-to-manager as a default expectation.
However, it is not a negatively thing. We may be able to setup IIS / Apache with Squid two decades ago to do similar things. The bar to do it now is much lower, and the tooling to help achieve that is much better overall (there are some not-so-great: Figma is a great design tool, but it doesn't translate to code directly unlike Dreamweaver / Borland VCL / Visual Basic, but I heard Framer is doing good on that front). That is part of the reason why there are so much more participation of labor in this industry: it is more graphical and easier to do (even terminal tools, largely do the similar things, are much more graphical nowadays!).
I feel it never really was about denying how effective plain web pages are but rather that faced with the choice of a wonderful DX with just JS, and a more difficult day to day with a mix of both, we picked the first. Sometimes at the expense of the end user, yaddi yaddi yadda, etc.
Good solutions for the "have your cake and eat it" scenario with exceptionally good DX are just now reaching some maturity.
Getting great reliable software delivered quickly, which is easy to maintain and change, should be the goal, I feel. But if that’s the case, why do people invent problems to find solutions to, why do people spend multiple days a week in Scrum meetings, etc.?
But looking at everyone involved and their actual incentives:
- For a consultant, the objective is to maximize the billable hours.
- For the employee, to get modern skills on their CV.
- For the junior programmer, there is a more level playing field with the seniors when tech is used that’s new and nobody knows, vs. tech the seniors know well and they don’t.
- For the manager or owner of a product company, they want less stress having to make decisions and as long as the product makes money who cares if the software could be delivered 50% or 70% faster?
Many of us are living this now. If it's not the chasing of new frameworks, it is old frameworks no longer being actively supported, or key features never being developed. Then it turns out something like vanilla HTML + JS can do the job just fine, but you need to update everything to vanilla to make it uniform.
Many developers nowadays seem to expect to be able to just wire things together without actual writing much algorithmic code. And the solutions have catered to that.
Those of us that are older lament the idea of using frameworks to increase our productivity, but still being more than glorified middle-men.
This attitude is common, that these frameworks are not, themselves, dependencies to be managed and protected from.
Is this not the typical mentality?
Putting together a decent web app today that is competitive with what’s out there and doing it in a reasonable amount of time is something that just requires frameworks and library mashing. Even though I can fully empathize with your comment, from experience, and even though my beard is almost as grey, piling stuff I don’t understand together from yarn or npm is exactly how I start a new web app. My job recently switched from web to hardware, and the workflow changed dramatically into writing and scrutinizing every line of code, and complied instruction even. But even still in the hardware company there is an overwhelming sea of choice and complexity and an army of young and old programmers all borrowing and reusing code at all times, with everyone just treading water and understanding only the tiniest sliver of it all.
I think we have no choice but to embrace the fact that it’s no longer possible to avoid swimming in 90% code you can’t control or understand, and figure out how to better manage it and encourage people to snorkel under the surface whenever they can. I don’t think we should blame it on the kids though, they’re just trying to get by the same way we did, but in a different world than we had. The good ones will still shine through and be amazing, and the rest can learn their mistakes the long way just like we did when we were young and obstinate.
I once had an experience where I asked a younger developer why they didn't use cookies for a solution they were using JWT's for. Their answer? They didn't know how to use cookies.
I was bemused, their solution worked just fine, it's just all the extra infra needed when compared to cookies, which would have solved the problem just fine.
I'm in my mid-40's and I would apply that observation to scrum (and software dev in general). What I tend to see are a lot of very earnest people who are legitimately trying and the behaviors often associated with scrum are what they've been taught works.
Truly understanding what goes into successful software dev takes years of work and is more craft than algorithm, so I can understand the challenges.
If you're talking about web applications then I tend to disagree. The SaaS paradigm and the UI living in a browser are relatively new ideas that are still maturing. I don't think there is a lot of good "what was already there" and we're just seeing the evolution of tooling for this ecosystem, not completely decoupled from the evolution of the large companies that rely on this tooling. Not sure it's worth getting frustrated about... I tend to just stay away from it because I prefer to work in areas that are less fluid. And sure, sometimes there's just Not Invented Here syndrome and let's reinvent the wheel instead of using existing wheels. Nothing new about that either, it's always been like that.
All that said, the principles of how everything works are unchanged. People that only learn to use a framework are just not good software developers. People that understand the principles can work in any framework. This has always been true and is still true. There's a shortage of people that really know their sh*t and there's always been as well. That's great... I'll never run out of work (I might run out of motivation ;) ).
It's not that difficult if you actually can make decisions quickly. It only gets difficult once you are in a bigger company where you have multiple more or less competent stakeholders and every decision get accompanied by multiple meetings.
I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons... but every time I've promoted a reluctant leader it's been magical for that person and for their team. A lot of times the people that self-promote and like to be in charge should never, ever be given athority.
> I am very skeptical of new technologies
I used to think that way until I realized that in a lot of cases, we've been re-inventing the same concepts in computing since the 1960s. I think a lot of the re-invention is really being driven by hardware capabilities, languages and fashion. We're seeing it with Rust right now - let's rewrite all the things in Rust! Underneath it all, though, the payoff for using new, less capable tech, is that eventually it will pass up the old in a very meaningful way - and when it does, systems build on the old are washed away.
> I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons...
Note that you are talking about different things from OP.
OP was talking about managing, you are talking about leading. These are two very distinct skills. Sometimes you can find both in the same person, but these people are few and far between, since each of these roles is already a full time job.
Everything I've experienced in my professional life has taught me this: managers who can't lead can't manage, and leaders who can't manage cannot lead. Never once have I worked for a manager who didn't see themselves as a leader, and never once have I met someone who called themselves a leader who wasn't management.
People who are stellar managers, have extremely high empathy and EQ, understand their engineers, prop them up, help their career, guide them toward both professional and personal growth. They also did not have a single ounce of leadership or charisma in them, very low technical chops, no vision, and not interested in providing team leadership.
I've also met stellar leaders, visionaries, who inspired, entranced teams with every single word that came out of their mouth. They provided short and long term directions, technical and product guidance, motivation. And they were absolutely terrible human managers. Could not place themselves in other people's shoes. Didn't really care about managing the career or growth of people on their teams. Were only focused on matters that did not involve any human feelings.
These kinds of people both have their places and they complement each other wonderfully.
And sometimes, you find these two very distinct, polar opposite qualities, in one single person. But like I said, this is much more the exception than the rule.
And of course, the reality is that most people lie on a spectrum between these two extremes.
A leader can lead initiatives just via building relationship and having expertise without role power or any reports.
I was hired at my last job by the then new CTO to lead the “cloud application modernization” effort as they were pivoting to providing access to micro services to large health care companies.
After being somewhat successful at it, he offered to make me a team lead (been there done that). I told him in no uncertain terms that I would quit first. We had a great working relationship.
I now do basically the same thing in the consulting department at BigTech as a middle level hands on consultant.
I asked a year end could my position be considered a “terminal position” or would I need to work toward a promotion. My manager asked me why. Again I was very honest. I needed to know because I would be looking for another job before seeking a promotion. He said it could be a terminal position,
I prefer leading projects over leading people.
I often hear the argument that there is nothing really new in programming and that everything was already done in some way or other back in the 1960s.
I completely disagree with this and find it harmful. There is genuine innovation and new research happening in computer science all the time. The example you gave, the Rust language, is based on linear type theory that was first developed in the 1990s. Nothing like it existed in the 1960s and that is why it offers real improvement to software development.
Today, software development is slow, buggy, expensive and late. We owe it to ourselves to continue to research and search out ways to improve our craft. And this is happening. Newer programming languages and tools DO incorporate innovations from recent computer science research and are better for it. We should celebrate this rather than cynically pretend that all computer science research halted in 1969.
That I have to become a manager. That I won’t always code until I retire. That I won’t be welcome in the workforce in my later years.
All of those things frighten me! I love programming, and I want to be doing it in my 60s, happily. Glad to see that people are.
However, idle you never can be. Because being of age and not being able to run with the pack is bad. Luckily, it is not the framework of the day but more the soft skills which make the difference.