We need young programmers; We need old programmers
blog.ploeh.dk
blog.ploeh.dk
The length of a string determines how quickly it vibrates (assuming tension is the same). Shorter strings vibrate faster than long strings. If you're in a noisy environment and you want to make sense of all of the chaotic sounds around you, one way to do it would be to take a bunch of strings of different lengths (say a piano) and see which ones resonate more than others. The gentle ringing of those piano strings, some louder than others, tells you which frequencies are more dominant in the surrounding acoustic environment, because they cause their matching strings to resonate more.
As I get older (I'm in my forties), I feel like a lengthening string. When I was a twenty-something programmer, I could tell you how things had changed over a year or two, but trends or cycles on longer timescales than that were hidden to me. Now I know what a decade or two feels like and can see and intuitively sense cycles of that scale. At the same time, shorter trends are harder for me to pick up on now. It feels like noise or beneath my notice.
Having people of different ages in your organization is incredibly value because they all resonate at different time scales like this and help you pick up chronological patterns at frequencies you'd otherwise miss.
A failure mode I see of some older developers is assuming there's nothing new under the sun and nothing worth learning, which I don't think is the case. I think it just gets harder for us to see those short term trends.
Another analogy I've heard (I think it was from Ward Cunningham) is that technology comes in waves. You don't need to catch every wave - trying to do so will tire you out. A good surfer learns to be choosy about the waves they catch and that comes with experience.
Not every change is cyclic, so you risk being unable to respond quickly to fast permanent changes if you don't acknowledge a change until a sufficient amount of time has passed.
I won't downvote you but based on observations over the last decade it wouldn't surprise me at all if someone else does.
I've got a couple of similar aging analogies/models (also in my forties) that tend to come to mind when I'm confronted with these sorts of topics, namely physical speed.
When we're young, we move slowly, crawling, then walking and running. The things we notice and care about tend to be smaller and more detailed. Walking home in elementary school, I knew every crack in the sidewalk, every brick in the retaining wall, every tree limb, every slope of every yard.
Then came the bike, and greater speed, then the car. More frequently in adulthood are the planes. Now I barely notice the fine details of what I pass by, but my awareness of city-scale things, both at home and abroad, has filled in...the streets, rivers, buildings, and the development that spans miles and miles that were far beyond my grasp when I moved slower. It's a bigger, more complete picture, but I can't zoom into it.
I often miss the slowness of my youth. I remember vividly being enraptured by the mundane details of my backyard, the roots of big pine trees, lush grassy spots, the cracked patio. So many tiny, "up close" details that were so interesting to look at, and run GI Joes and matchbox cars over for hours.
Building software is the same. Most of my giddy memories of discovery and productivity were in the "slow" phase of my career, when my tasks and responsibilities were fewer and closer to the ground, so to speak. The code itself. Now that I can travel faster, I have a larger number of more impactful responsibilities, but I don't feel that closeness or giddiness. I'm rarely enamored by the solutions that I churn out.
I have a real life example of the five monkeys story. A company I used to work for had a pile of legacy systems in php4, mysql 5.0 and a frontend working only on IE8, no ci/cd, no tests. Almost instantly I was lead to beleive this system is a black hole that can't be saved due to the technical difficulties plus management issues. The head of IT was there for almost 20 years watching tons of developers contribute to this mess and failing to take meaningful action to address the problem. Thus he had insane clarity of all the problems, but also was pesimistic about any possitive outcome. With his experience on these systems and my determination (probably stemming from my youth) we managed to upgrade php to 5.6 (almost compatible with 7), mysql 5.5 and most of the front end could work on latest chrome in a year (+ a great deal of performance optimizations). We both left that place having layed out a solid foundation for the people who were left behind to continue this modernization endavour (which I've learned was carried on)
Ok, we should judge people by what they can and do contribute to the team. The billion-dollar question is, HOW? Humans are extremely skilled optimizers - give them an objective metric and they'll game it for maximum benefit; make it subjective and it can be better or worse - but in either case, you'll no longer have any agreement on "what they contribute to the team".
* Documentation - Can they write?
* Potential - Can they provide original solutions to problems? Do they need hand holding?
* Initiative - Do they need a signal from a starting gun or are they self-entertained with word products for the team?
These are all identifiable maxims.
What I _am_ saying is that it's an art not a science - very hard to teach, impossible to scale.
Take your example with "Documentation" - if you measure anything objective (words written, number of functions/features that have associated documentation) and tie it with the performance evaluation, those metrics will soon become meaningless.
In the example of documentation a better metric might be a composite value of
(i) how many wiki articles a developer has written, weighed 0.33 and
(ii) how useful on a numerical scale his/her peers rate the documentation produced, weighed 0.67.
This is just an example but it's a composite of perceptual and objective, with the perceptual being a lot more important (and to prevent gaming the system by writting lots of useless articles).
When I worked at Microsoft one of the teams I was adjacent to had a metric on number of new apps in the Windows Phone app store. So the teams went out and got a bunch of college students to build shitty apps in bootcamp style working groups. Suddenly the number of apps isn't good enough, so they added review metrics. Now those teams add a "let's all rate each other's apps" portion to the bootcamp taking you even further away from the results you're trying to obtain.
I hate doing performance reviews, and I especially didn't like when at a former employer I was asked to stack rank programmers. I feel like it's a task that's so difficult to get right, I can't even think of a wrong way to do it that's useful.
No, it certainly doesn't mean that "your performance was [7.23541 8.1241 34.412515 .52632 995.154]". It means "you did good/ you did very good/ you need improvement", with some details like "<these things> you really handled well and I appreciate it; maybe you can work a bit on <this area> though". I definitely agree one shouldn't stack-rank people - especially in a good team (it's entirely possible, desirable even, that everybody did a great job)
The second is that different types of people prefer different styles of working and sometimes forget there is another side (multiple "other sides", really). A team needs to be a mix of capabilities and personalities to be successful - a team of 100 identical individuals would likely fail, even if all them are Peter Norvig). So, you need people that are "senior" in the sense that "knows the business well enough to provide different perspectives" (and for those "shows initiative" is critical) but you also need specialists where "senior" means "knows technology X really really well". Say, a DBA - can keep your database up, can write efficient queries to retrieve information that you want; but doesn't know sh*t about what information would be interesting to retrieve. Or whether it's a good idea to keep some information X in the database, considering the various business, legal, social, cost perspectives.
> Do my managers know what they're doing?
Here's the thing: I believe nobody _really_ does. Sure, some know more than others, but in absolute terms, we're all basically guessing. That's why people insist on engineers that "show initiative" - not because they're always right, but in an environment where we don't _really_ know what we're doing, people yelling different perspectives are valuable.
However, as mentioned above - not all senior engineers want or are inclined to show this kind of initiative; and it's unfair to penalize those kinds of engineers, because we _need_ the different types of personalities.
[1] FWIW I believe the reality is , always, that you need to (A) work on a successful project; and (B) be generally liked by your colleagues and maybe managers. For very senior titles, also (C) have a large network of connections within the company - i.e. work on many things, or on one thing but a thing that is used by many teams/ really popular)
Objective metrics are good if you think you can measure accurately for all individuals at the macro level. You may not need that (I mean, really _need_ it for your business to function, unless you're in the metric-tracking business).
If your teams have distinct and articulate enough outputs, you can retribute each team according to its specific outputs. At the macro level, you don't need to have more details (but you still may ask).
Let the team manage its own distribution of the retribution - and so on (so you do need trained managers to do it appropriately at each level).
Agreed
> They should be judged by their skills, the same way the young ones are being judged.
Disagree, but this is my subjective opinion. Old people in general are not able to keep up with young people for many reasons. My personal stance is we shouldn't compare them as equals, but rather try to get the most out of everyone. The baseline for judging someone (to be hired or to stay in a job) should depend on the effort they put in. Actual performance should be taken into account when deciding on promotions and bonuses. This would create an environment safe for old people to keep their jobs until they retire, but also fair to people of any age to get higher salaries and roles based on their skills.
However, my solution does not judge people differently based on age. It judges everyone in a way that allows old people to fairly compete with young people on the basis of effort put in rather than pure skills/performance output.
Blindly saying 'ok you are technically better, but your also old and I want young people' is what you are arguing.
That is bad discrimination.
Then they retire. Someone else takes over, and they do exactly the same work in $small_percentage of the time.
So no - effort is not a good metric. Why would you be paying someone who can't do the job - or at least can't do the job well, with enough spare capacity to deal with more complex work requirements?
Of course this is a parable, but I suspect a lot of people have seen something similar happen at work at least once.
Fairly compete in...making an effort? Would you like to get operated on by a surgeon that lacks the skill necessary to perform his job but tries damn hard? Would you want to go to a concert where the string section has been working real hard on learning the material but can't read sheet music and are tone deaf? Would you want to ride the bus where the driver has been practicing all his life but can't quite drive well enough to meet a reasonable standard based on skill? Do you want to follow a basketball tournament where the winner is determined by their effort rather than their score? Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
My most favorable take on your idea is that you simply can't have thought it through.
Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing. It's this attitude that leads to age discrimination in the first place, not that old people somehow can't produce quality work.
Instead of fucking up the workplace by introducing perverse incentives, consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
Breaking news, this is already happening. Actually, pure performance-based judgement drives incapable people to hide their inability to perform the task at hand leading to bad results (instead of facing the reality in a safe environment that would help them get better at what they do).
> Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
This sentence assumes the majority of workers are incapable try-hards which is plain false. A few less-skilled try-hards aren't going to ruin any service. Again, this is already the case in the world we live in.
> Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing.
I clearly stated two layers of judgement. A baseline for effort and a second layer for career progression based on lerformance, both age-agnostic. Never proposed a system discriminating against age. Get over it please.
> consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
Ok so I proposed a system that would ensure someone has a job as long as they are not a lazy-a$$ (but probably wouldn't be able to climb up the career ladder if they don't have the skills), always age-agnostic, but that is somehow not a socialized effort to provide security? Ok.
It seems to me maybe you've got the hero mentality. That sacrifice == hours spent grinding == commitment to the job. "Effort" to you is a measurement of love.
That totally described me in my 20's and 30's. One day, after acquiring the necessary skills, I woke up and learned that it didn't make sense to grind like that anymore. Also, long hours is bad for the mental health.
I switched to "work smarter, not harder" mode and learned about TDD and Agile. I got better at my craft and earned respect from my peers for encouraging them to get better too.
Finally, I had a really eye-opening experience with an older developer a few years ago. He was a contractor and owned a gym. He always took off at 3pm to go train his folks and work his other business without asking/telling anyone. He was gruff and a little bit intimidating physically. He even had terrible typing skills: he typed with two fingers like a kid! Not sure if that was a dexterity handicap or if he just never learned to type, probably the former, but it still pissed me off because he was SOOO SLOW!
It surprised me a bit when he rolled off that he lasted his whole contract and didn't wash out sooner. It surprised me at the time he had such deep networks in the company: VP's knew him and worked with him years earlier and they had lively random conversations. It surprises me now that his contributions to the codebase have endured - he just got a lot done in less lines of code. I think fondly now at the conversations we had, not just on coding, but on parenting, politics, physical health and strength training, military service, and just ... diverse, weird thoughts from my parent's generation.
Think of yourself and your beloved company as The Borg. Your job is to incorporate the technical distinctiveness of aliens into your collective. If people you run across are turds, and you have a culture of hard-charging success, they'll wash out pretty quickly. Just let go of effort and efficiency as metrics - beancounters can concern themselves with that. Focus on winning over the long term.
I have learned that putting in more hours does not result in the benefits one would hope for very early on.
Thanks for your comment though, it made me understand why everyone is super freaking pissed about my comment. Have I understood that earlier I would have edited it to avoid all this mess
In thios group we have a programmer in his early 40s, who has been programming for years, that I would still consider a "junior" programmer. He can usually perform a task but needs more guidance and checking than the other members if the team, most of which have been there time.
On the other side we also had a developer work there a few years back that was in his late 50s and wrote some of the worse looking code I've ever seen. Fortunatly he didn't last long and none of his code is running in production.
The 50-something who had been in the same role 37 years, who was laid off and when hired into a new company, just couldn't adapt. The 40-something who's fine to do maintenance and the odd enhancement, but you wouldn't trust to do a major refactor or a large chunk of green-field.
Some people just aren't as able, find themselves a comfort zone and stick to it.
So even experience doesn't necessarily mean experience :)
(This isn't to say such people aren't useful, that's a different measure.)
If you're old, then the spectrum of possible experience is much broader. You could range from being totally inexperienced to being extremely experienced.
Also, as I get older, I realize that talent plays a significant part (which is independent of age). But there is a huge problem that almost all companies don't know how to identify technical talent; they focus on the wrong attributes like ability to perform under pressure and ability to recall details. Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly; that is the real valuable talent.
So, from my non-tech perspective, that's just every single job at every single employer. Any position I've had that has been in charge of hiring people - I am acutely aware that I can teach the position. I can teach the technical aspects and detail knowledge of how to do a job. What I can't teach is the ability to prioritize, critically think, and communicate appropriately. Those are real talents.
I guess what I'm saying is - tech companies are garbage at evaluating for those things, because (I would argue) all/nearly all companies are garbage at evaluating for those things. It doesn't matter if it's a tech company, garbage company, or insurance company - they're all (again, my experience) equally garbage at finding those skills in people through their standard interview processes.
If you figure out how to implement a standard interview process to evaluate for the three things you list, you will be the world's first trillionaire.
For example, I work with a firmware developer in his 50’s, and he is so efficient it is scary. He’s basically seen it all by now, and he has deeply ingrained work habits which let him solve problems extremely quickly.
That’s not to say that every developer with X years of experience will automatically be great in that way, but if you can find someone who has years of experience producing exactly the type of work you need, this should be viewed as a huge advantage.
It’s like if you are looking to hire a carpenter to built a piece of custom furniture: you can and should consider general qualities like strength, manual dexterity and attention to detail. But if you can find someone with years of muscle memory building exactly that type of furniture, they are almost guaranteed to get the best result.
Not the same year 10 times but 10 discrete, non-overlapping years.
Ideally I preferred learning the technology for a few years then steeping back and reaping the benefits and do stuff with it. But, there is a fear that not keeping up leads to obsolescence on the job market so we're in this constant cycle of learning new things with diminishing returns
The main skill for senior/staff swe is not in knowing or not knowing some technology, but rather
1. Picking things up quickly
2. Understanding/recognizing generalizable patterns and best practices in any tech.
Almost no job requires some extreme expert level knowledge of language/framework minutiae (obviously you do need some experience in particular tech). Almost every non-greenfield job has a ton of custom tech that has to be learned. Almost every green-field job needs someone with immense breadth.
Having been exposed to very many things people get to naturally see recurring patterns/best practices. When they see a new tech they are able to understand why choices were made. When new tech needs to be made they can draw from broad experience in what others did best. I really think this is most of the eng value of staff swe.
It's even worse in front-end, because that means their skills are that of a 2 year junior 10 years ago, they don't have any of the skills with new frameworks and techniques. If you want sloppy bootstrap laden html/css and jQuery, they're your person though.
Unfortunately, there's no one size fits all worksheet for those soft skills that HR can hand out to interviewers, so everyone gets lazy and falls back to the whiteboard BS.
This isn't what I'm talking about - I'm talking domain specific skill. If you're a frontend developer for instance, you should understand the new language features of JavaScript that came out in 2015-2016 and be able to use them. You should know how to use flexbox for CSS instead of floats for layout (IMO)
If you're a senior developer still writing code every day, you have to keep up with that stuff. You're ultimately responsible for the codebase in a way that junior/mid devs are not and if you don't understand large aspects of how it works you can't be effective.
It doesn't help that people who stagnate like this usually weren't very good at/engaged with their jobs to begin with. They're usually senior in name only, where their managers know not to actually assign them stuff that matters.
Do new languages, new language features, new frameworks, new methodologies necessarily add business value? Or are they sometimes just being used because they are new and shiny? Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill. One distinguishing attribute I'd expect from a "senior" developer is the ability to quickly evaluate new technologies, choose and focus on what actually provides business value and have the discipline to ignore the rest. It is possible to be a top performing, highly productive developer today by very effectively using 10 year old technologies.
Sometimes they do, sometimes they don't. But the tech stack will eventually come to include these new things whether you like it or not. And even if somehow you're able to stop that from happening, eventually it will become very difficult to hire junior developers with experience in old frameworks and eventually those frameworks stop getting supported and community contributions since so many other shops drop it.
The two things I listed specifically are actual fundamental changes to CSS and JavaScript, not fly by night frameworks and they both do add a lot of value.
>Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill.
I actually do sympathize with this way of thinking, and I used to agree with it. But I've come to understand how misguided it really is. Every well paying knowledge worker profession requires updating your skills from time to time. Doctors have to learn new guidelines for treatment and different ways to do surgeries/procedures. Lawyers have to brush up on developments in case law etc...
Programming already has an extreme advantage over a lot of these professions. There's no licensing board, you don't even need a degree if you can pass the interview. It's silly to think that we should also be immune to honing our craft and changing with the times.
If you're a software engineer, you should have the expectation that you're going to need to do a little bit of career development every year. I don't mean spending 10+ hours a week on it, but to use the examples above... I realized in like 2016 that I didn't know Flexbox and that was pretty much the new standard for how layout was going to happen in CSS. So I made myself learn it. And not only does that update my skills, Flexbox is actually way better to lay elements out on a page with than the old way. It's made building html/css views out much quicker.
I've seen nigh unmaintainable web apps that were entirely laid out in really overwrought nested flexboxes, when using utterly basic HTML elements like <p> and <h3> and <dl> with a bit of CSS would have rendered faster, been developed faster, worked in older browsers, and worked better with accessibility tech.
So really, flexbox is just another new old thing, and what matters is the concept of constraint-based layout as one tool out of many. If it's the first new thing you encounter in your career, it's worth learning it because it's there, but remember that it's just another spoke on an ever-turning wheel.
I've noticed this is changing (spearheaded by FAANG & other top tech companies it seems) - there are frontend specific tracks that test more JavaScript knowledge than leetcode puzzles.
But as usual, if there is a cutting edge, there are many more laggards, and I'd say many companies are still doing leetcode DS&A for frontend too.
It's really impossible to generalize about most aspects of this career in my opinion. There are no hard rules about anything, even hiring.
I think about this in relation to the "skill gap" in programming a lot. There are people who work in very senior positions in software development who couldn't do a LeetCode easy or a FizzBuzz. They don't read articles about how to get better at programming or about concepts like DRY etc... but maybe they do the very specific thing their employer wants well enough, that combined with their long tenure and relationships with other people they are pretty much lifers.
That's why I laugh when I see articles on Hacker News articles where it says if you don't do X Y or Z you're not a "real" programmer. Meanwhile a huge swath of people employed as programmers haven't even heard of a lot of this stuff, much less actually used it.
Half my team is in London (big bank), as is my manager, and I know they leetcode candidates there too - and we're not even a tech company or elite financial firm, just a boring big conservative bank.
If you're looking for a job in this day and age, I think it's safer to assume you're going to get leetcoded and be prepared. Rather than try to find the rarer and rarer company that doesn't leetcode you.
Can you give me an example of a task that I couldn't have done with ten year old tech?
Will it automatically be better because I am using this years chosen framework (or will it be more likely that there are unforeseen problems because of not using a mature technology).
That said, want to call out that experience in other fields can sometimes be tremendously valuable! (... but isn't guaranteed to be)
Your tale is great, and sounds like a great experience, but I don't think it's necessarily related to the age of the participants, and to me the key here is this -
"The head of IT was there for almost 20 years"
To me that reeks of stagnation. 20 years in the same place! This person hasn't exposed themselves to new ideas, cross pollination of techniques and skills etc etc. They've become ossified and cynical, and not because they're older, but because they haven't moved around. Anyone being somewhere more than a handful of years (5?) is a red flag to me, if you're looking for technical competency.
I'm glad, for his sake, that story ends with the guy moving on!
It's one of the toughest things about working as an employee if you're interested in more than one area. That's why I switched to freelance consulting, where I found the variety far more enjoyable.
It looks very likely I'm moving back to "permanent" employment soon for stability and access to more interesting "big" corporate projects that I found as an independent. (My valiant initiatives to struggle on intermittent income and use the free time to transform the hardware world into an open source hardware world don't seem to be needed any more; better people than me are doing a great job!)
But I have mixed feelings from a nagging doubt that I'll be stuck doing one thing all the time, until I have the temerity to leave the employer. We'll see, I do have an open mind and I'll give it enough time to find out, but it's at the back of my mind.
As an employee I wasn't able to maintain projects longer than 2-3 years even when I wanted, due to fixed term (academic) employment contracts, redundancy, projects getting terminated due to business decisions, and reassignment to different projects.
As an independent I found I've had very long term ongoing client relationships (7+ years for one, 5 years for another so far), where they call me back to maintain their products for years after shipping.
During that, it's fine and even expected that I have overlapping newer work with other clients.
So I'm expected to maintain a number of things long after shipping, and that's what I expect to be called to do if I did a good job of delivering the project in the first place.
I think my experience of maintenance and dogfooding may be the opposite of what people think of, when they think about employees vs. independents.
If you're not delivering useful, production level stuff in under 5 years, even if it's not a 'complete' big project, then something's probably very wrong, IMHO.
I stayed at one company for about 20 years. Every 2-3 years the job would radically change into something else. So I stayed for awhile. It was good for them as they could come back to me for odd decisions made and how to work around them, and for me I could work on new tech every few years. But for me on ye-ol-resume it looks like 20. My current job things are not changing like that so I will need to move on to get diff exp in something else now. The org is just not designed in the same way and it would be easy to silo yourself into a niche that melts in 10 years. You can argue with your boss to you are blue in the face about moving on and getting more challenging/different jobs. But at the end of the day they need to ship their product and they will usually not look out for you.
I agree with grandop that 5 years is prob the time limit before moving becomes very important unless (1) you are in organizational leadership (you drive vision and with success get fu money) (2) you are being continuously rapidly promoted in a large company.
Senior engineers, heads of engineering, architects, generally people who've been in one place for 20+ years, often who have been in charge of technical direction that whole time. Some of them even asked me for advice on getting out... These people tend to be respected within their organisation and have a lot of very narrow-focused domain knowledge, but because they don't move around they haven't had to think their way through any brand new challenges, or learn new techniques and systems.
It's not inevitable, but it is a pattern I've observed.
That one day will be here in a blink of an eye. Seems like only yesterday I was the wide-eyed, naive programmer fresh from uni... :)
Had a friend tell me when he was a newly minted lieutenant. All the new guys were put in a competition with their platoon to build a temporary bridge across a river. While all the others called out orders he consulted the grizzled old Sarge and asked him what he recommended. He took his advice and said lets proceed. Instead of barking orders he spent time working alongside his men doing physical labor. His team not only won they set a record for that task. As a result his platoon would walk through a wall for him.
But what if there isn't an old experienced Sarge? The organization is the worse for it and I've seen it time and time again.
The best example I can give is one developer given very little time sends something to QA their unsure about. QA lets it though because they stopped testing his code.
You could be thinking of “personal computer with Internet access”? That’s closer timing as long as you want something more open / capable than the various dialup services which were popular with personal computer users starting in the 1980s.
By 2001, it's 60% and nearly 100%. I agree with the others. You're about two decades too late in your estimate.
This was not my first personal computer, but it was the first that literally has "Personal Computer" in the name, and is more than ten years prior to your claim.
Heck some of the essays from Paul Graham date from the 90s.
Well, there might be a handful stacked in the place the thing was initially created (they've probably long moved on though).
HN happens to be heavily centered around the valley and Apple/Microsoft, bad luck. Consider that the rest of the world can easily be a decade behind the valley.
20 years? You are literally MULTIPLE decades off.
Some people might regard me as grizzled, I guess.
Maybe the wikipedia article on the Digital Revolution [0], starting on the section "1969–1989: Invention of the Internet, rise of home computers" [1], or the section "Rise in digital technology use of computers, 1980–2020" [2].
> In developed nations, computers achieved semi-ubiquity during the 1980s as they made their way into schools, homes, business, and industry.
[0] https://en.wikipedia.org/wiki/Digital_Revolution
[1] https://en.wikipedia.org/wiki/Digital_Revolution#1969%E2%80%...
[2] Rise in digital technology use of computers, 1980–2020
Apple was incorporated in 1976. What do you think they did for the first 25 years of their existence?
I'm much closer to 60 than to 50, and I played with my first "personal computer" (original Apple ][) in the late 1970s. I have over 40 years of experience with personal computers, servers, and embedded. I've been through bubbles, I've seen the pendulum swing from centralization to distributed several times. I've seen industry behemoths rise and fall.
I work hard to maintain a grizzled appearance, and I am an industry veteran. I have encountered ageism (and sexism, and racism) in the industry: it's like mould in blue cheese. It all comes down to the biggest problem in the industry, and probably outside the industry: arrogance.
This is where communication skills come in. The more one levels up their communication skills the easier situations like this are to overcome.
This was a company in finance, doing not-very-interesting things. You’ve probably never heard of it. About half the devs were above 50, and the other half straight out of bootcamp, with a few people in-between.
It worked so great. The “old ones” brought a lot of maturity, practices (TDD, tests, even XP at times) and loved mentoring the super enthusiastic grads. The grads just finished bootcamps, many of them junior on paper, but had a different career in the past. They soaked it all in and grew fast. Sure, some left after a while, but a surprisingly large number stayed because of the environment and the people.
And the company did well. The pay for the expeirenced devs was probably a bit under the market, somewhere at £50-60K. The new grads were cheap. Still, attrition was low, morale high, output consistent and quality high.
I think of this example many times. Why do so few places not try something similar? Especially at places where you don’t need to use the latest and greatest, where business is stable, and where you can get a bunch of these benefits altogether.
You do realize that most people in their 20's have many years of experience and know all of those things? Young doesn't mean inexperienced.
You don't fix age discrimination by saying that old people are better, because in most cases they aren't, instead you fix it by saying that if you have 2 persons with similar skills then you shouldn't automatically pick the less experienced younger person. If you only hire old developers when they have all of the awesome skills people tout in these threads then you will mostly hire young developers since so few developers have those skills no matter what age they are.
>Technology changes rapidly in software development.
That might be true of specific kinds of software development. People developing what used to be called "applications" (and now increasingly is once again called by the same name) are using very diffferent technologies than they were in 1985 or even 1995 and perhaps even 2005.
But if you're writing, for example, "creative" software (audio, video, graphics), the toolchains and fundamentals haven't changed much in 20-30 years. The rise of GPUs has added a wrinkle to the mix if you're doing video/graphics, but often at a layer you likely don't think much about on a day to day basis.
As a programmer of 35 years, I've got nothing to teach younger programmers who are doing webdev work in JS and/or some server-side stuff. But a younger programmer who wants to do native realtime audio has nothing to teach me, no new technologies to show me (they could easily be a better programmer, though).
Let's try to remember that "software" is bigger than webdev, and the rate of change outside of the volatile webdev sphere isn't always as dynamic as this article makes out. For some of us, GPT-N is fascinating as hell, but will make absolutely no difference to our work as programmers for the rest of our lives no matter how old we are right now.
IMO, software development fashions changes rapidly. But actual software development? The changes and improvements are glacially slow. I suspect that architecture (which is a discipline literally as old as human civilization) has changed more in the last 30 years than software development has. But that was mostly thanks to software. So there's that. :-)
I've seen it myself in a social experiment where actors were placed in a waiting room. There were 5 actors that stood up for 5 seconds every time a bell was rang at random moments. A "test subject" was added and quickly joined in. They swapped out the actors one by one and long behold - after 30 minutes 6 random strangers were standing up when the bell was rang without having the slightest clue why.
We're funny creatures :D
Just did a quick Google, here's the video: https://www.youtube.com/watch?v=MEhSk71gUCQ
Some countries that get low amounts of sunlight due to latitude eat fish for breakfast. Apparently the nutrients in fish help you biologically deal with not having enough sunlight. And this results in statistically better health outcome vs other countries at the same latitude that don't eat fish as much.
Did eating fish start because people were running double blind 30 year dietician studies? Nope, it's just what other people were doing.
Think about it this way. Some problems are really hard to actually understand. And if you screw up you'll die (so you can't exactly learn the lesson even if the lesson was obvious). Culture and social cohesion is important because other people have learned (maybe unconsciously) a fatal lesson by watching others fail to learn that lesson. It can be life or death for you to pick up on that lesson.
It's also important that people question why we do things. Because otherwise we can end up all standing up when a bell rings for no reason. But both methods are necessary. Even if we end up doing some stupid things for a while as we sort out reality.
EDIT: I'm actually mostly unaffected by peer pressure. It sounds impressive because I'm extremely unlikely to do something stupid like stand up when a bell rings. Additionally, I can go off and learn things like type theory, lambda calculus, most programming languages like it's easy.
But the catch is that type theory is only easy compared to trying to understand social interaction logically. People often all agree about something that makes absolutely no sense to me ... and they're right (well, I've looked into this a lot and technically they're not right, but it works out and they get good outcomes, which is almost always close enough ... I think what happens is when their wrongness catches up to them they switch strategies or something, but I'm not sure). It often feels like living with a bunch of aliens who have psychic powers.
So, while it's easy to setup social experiments that make peer pressure look stupid, I'm not about to discount it's incredible usefulness.
A slightly better thing to do, of course, is ask why they're doing something.
In the past the default argument was 'sorcery' or 'anathema'.
That's why we need the scientific method. Our primary impressions can be often wrong. We should not rely only on 'gut feelings' to reach our conclusions.
> In the past the default argument was 'sorcery' or 'anathema'.
I really don't like this. It looks fake because it's full of edits, skips over important bits where you'd expect doubt, and doesn't feel like its supplying the full context.
Yes, the conformity effect is real. But no, it's not as strong as EVERYONE loves to portray it. In actual studies, a good chunk of people don't abide by the effect, and it's probable that, contrary to the video, they do suspect they're being observed (by a study or more likely just some sort of process with a consequence). It's a stretch to assume that people copy things because that's what the group does, rather than thinking the group has a good reason to be doing something. The latter sounds the same, but when you think about it is a lot less interesting.
Most people, if they're the Asian girl, are just going to ask the group what they're doing.
It's on a totally different level than just crying 'fake'.
I think it is quite possible that for some behaviours humans tend to prefer to always use their own judgement, while the opposite is true for other behaviours.
We see a massive parallel experiment about this with some things that happen on Twitter or TikTok. And this goes from putting a bucket of ice over your head to the reaction to some political statement.
To have a catalogue of the cognitive biases we have as humans and which behaviours are more susceptible to this effect would be a hugely useful dataset.
0) watch 10 youtube videos on kitchen remodels
1) take a sledge hammer and remove your kitchen this weekend
2) rebuild your kitchen
Let me know how this goes.
You mix up knowledge, skills and proficiencies.
If you watch 10 youtube videos, you might gain the knowledge of building a kitchen, but you neither gained the skills of using tools, nor the proficiency of planning and building a kitchen.
Those are very distinct things, which pedagogues are aware of.
It has to do with experience because skills can only be honed through experience. It has to do with age because honing skills via experience requires time.
Yes, but it does not take a learner lots of experience to learn a skill (with some caveats, ofc). It takes the teacher experience to teach a skill, though.
> It has to do with age because honing skills via experience requires time.
I agree.
But it was not about honing skills or becoming perfect, it was about learning and "building a kitchen".
We must have different priors regarding OP's specific example. I think that "building a kitchen" would require a hell of a lot of skill, all of which needs to be honed over a decent period of time. I'm 100% confident that given an empty room, building materials, tools, and some appliances, I would do more harm than good.
I'm not saying experience is irrelevant, I'm saying you can teach somebody the skills to use tools and the proficiency to build a kitchen and he would afterwards be able to build a kitchen, even though his experience is very little.
I'm not saying it will be the best kitchen in the world, neither am I saying the teaching process will be super fast (it depends on teacher and pupil), but I am saying that it is first and foremost not about the age and experience of the trainee, who then later attempts to build the kitchen.
The time investment is necessary. It is by no means sufficient.
A kitchen remodel typically requires skills in plumbing, electric, framing carpentry, finish carpentry, drywall, painting.
None of this will be appreciated or understood by someone watching a video.
Each of these skills can take quite a while even for basic proficiency, let alone mastery to the level required to work smoothly, and quickly enough to make any money at it (or avoid divorce as your kitchen sits for months in an unusable state).
On an average ten person team, the average age is not going to get much above 30, if you are lucky. Most of those people would be considered senior.
I've been on a few projects that went against the trend and worked with a few people above 40. These projects are expensive because (properly) senior people cost money. But older does not mean wiser or better. So, the value for money is not always that obvious. Of course some people that are good only get better with age. But the reverse is true as well and there are a lot of not so great developers that will still be coding for the next few decades. That ratio good to bad programmers doesn't really change; though of course the bad ones might pick up a few useful skills eventually.
I admit that I did my share of whining. It was quite jarring for me to encounter the naked, unapologetic ageism in tech, but I have now come to accept that it's just "part of the landscape." I can't change anyone else's mind, so I don't even try, anymore.
You don't want what I have? Don't worry; You won't get it. I won't waste any of our time, trying to convince you otherwise.
My age (and commensurate experience) helps me to get stuff done. I don't pretend to have the creative flair that can dream up reusable boosters and smartphones, but I definitely have a long, long record of ship. I've been working on shipping product, for my entire adult life. I'm pretty good at working in a layered, modular fashion that can result in robust, highly-usable, scalable, localizable and accessible software that can project and reinforce branding, as well as actually provide a revenue stream, and establish a legacy. I've written software that lasts decades.
But that doesn't seem to be what the industry wants. Quick lash-ups are more valuable. I understand why. They can act as "MVPs," and iterate quickly. That's actually a really important feature, and one that us ol' fogeys don't always appreciate. When I look back on my career, I shipped a lot of dross, as well as a (far fewer) number of really good products. The quality of my work improved dramatically as I got older; mostly because I screwed up so much, earlier. I'm grateful that none of my screwups turned into the Jurassic-scale disasters we read about all the time.
"Good judgment comes from experience. Experience comes from bad judgment."
At the moment, I'm working on a social media-style system. It's fairly ambitious. I can't even imagine my younger self working on this kind of thing, but I am grateful for the long trail of work by others that give me pitfalls and patterns to use. Younger me would have ignored all that, slapped together stuff without proper design or testing, and turned out some real crap. A lot of people would have been hurt by my cruddy workmanship.
Thanks for introducing me to that quote!
> You don't want what I have? Don't worry; You won't get it. I won't waste any of our time, trying to convince you otherwise.
I'm glad you're not letting it get you down. As long as there still are opportunities to be had, you'll be fine in the end.
Don't get me wrong. I did let it get me down for a while. It was really pathetic; crying, screaming, rolling on the floor, pounding my little fists on the table.
That got me precisely nowhere, but I guess it was cathartic.
I am pretty disgusted how ageism in employment is every bit as illegal as racism and sexism, but is actually ignored, if not outright encouraged. Companies run ads all the time, pretty much saying "Boomers need not apply," and no one bats an eyelid. I've learned that when a company gives a binary tree test, I might as well just pack up and go home. They just want to tick off an "interviewed old fart, and he didn't even know basic college stuff" checkbox for HR. Younger folks spend every day, practicing for these tests. I spend every day, writing ship software (and I mean every day -seven days a week, usually ten or more hours straight. My GH Activity Graph is solid green).
But I really love designing and releasing software. I do this for love. I'm probably doing six figures' worth of coding for free, because I believe in what I'm doing, and I haven't written a social media app; which seems to be a modern rite of passage. I already wrote the backend, a couple of years ago[0]. I'm just writing a native frontend.
I'm working with younger folks. I'm very, very good at helping folks with ideas, make them real. The classic pattern is for experienced and younger folks to work together, with younger people driving the energy and creativity, and the older folks providing the infrastructure and quality. That pattern has been turned on its head; probably because people are becoming CEOs before they reach 30.
Once I accepted that no one wants to work with me, and that I won't end up destitute, it was OK for me to just work for free.
[0] https://riftvalleysoftware.com/work/open-source-projects/#ba...
In any case, it doesn't really matter. I'm planning to croak face-down on my keyboard. The mortician is gonna have to rub "QWERTY" off my cheek.
This was my first paid work: https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
This isn't really about age at all - its more about incremental change vs disruptive change and who has the power to make those kinds of changes.
The old are in positions of power/influence and are often aiming to move things forward incrementally. They are rarely willing to risk everything for the chance to make paradigm leaps. Outsiders, on the other hand, are more willing to take audacious risks and have nothing to lose.
The young are nearly always outsiders but not all outsiders are young. Interestingly, when an old person retires, they become outsiders too with less to lose than before and therefore more willing to speak truth to power. The dynamic here isn't really about age at all but about power.
We need to get better at recognizing when change requires a patch of our models and paradigms vs when it is actually more effective to perform a full rewrite and create new ones. If we were better at that, we'd perhaps be better at valuing the types of people required for those changes.
Yes, and your phrasing of that is one of the most accurate I've seen in these threads. We who are old are completely capable to make leaps... but we are not incentivized to do so. Stock options and a chance to make a couple million will inspire the young to work wonders. But those of us who have been saving our income for a few decades already have a nice nest egg, so an incremental update to our nest egg isn't so compelling. The rewards at the end must also be a paradigm leap.
And there are paradigm leaps in this life - most of us start at the point where we struggle to pay bills. Then you jump to where you are not struggling. Then you have enough to own nice things. Then you have a home that truly makes you feel at home. Then your home is paid off and you measure your nest egg by how many years you could go without a job. Then you hit the point where that number is higher than the number of years you are likely to live. And then you hit the point where you have extra money to enable you to change your lifestyle and give more money to charity and still have enough to live out your whole life.
Any job that doesn't move us to the next one of those points is not incentive to work harder and give up time with our family, etc. That is also why we have less to lose as we get older. Because each of those points also means we are less dependent on our job.
At the end of the day, the differences in behavior are real. But anyone who thinks it is due to a difference in skills hasn't yet seen the big picture. Give us compensation that drives a paradigm shift in our lives, and we can drive a paradigm shift in our work to match it.
1. There are unknown unknowns (I don’t know why Donald Rumsfeld got so much flak for saying this)
2. Developing something that gets used is far more rewarding in the long term than using the latest technology or paradigm, or coding for codings sake (It took me over a decade to realize this - it may just be me)
3. In more cases than not it doesn’t matter what the technology, language, or paradigm used to develop a system or product is. It’s more important that the people developing the system are committed to building it (and them choosing that technology often helps)
> Q: Could I follow up, Mr. Secretary, on what you just said, please? In regard to Iraq weapons of mass destruction and terrorists, is there any evidence to indicate that Iraq has attempted to or is willing to supply terrorists with weapons of mass destruction? Because there are reports that there is no evidence of a direct link between Baghdad and some of these terrorist organizations.
> Rumsfeld: Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.
> And so people who have the omniscience that they can say with high certainty that something has not happened or is not being tried, have capabilities that are -- what was the word you used, Pam, earlier?
> Q: Free associate? (laughs)
> Rumsfeld: Yeah. They can -- (chuckles) -- they can do things I can't do. (laughter)
> Q: Excuse me. But is this an unknown unknown?
> Rumsfeld: I'm not --
> Q: Because you said several unknowns, and I'm just wondering if this is an unknown unknown.
> Rumsfeld: I'm not going to say which it is.
[0] https://archive.defense.gov/Transcripts/Transcript.aspx?Tran...
He got flak for what he used it to justify. Out of context of the question to which it responds, the unknown unknowns statement wouldn't have been controversial (similarly with his “you go to war with the Army you have, not the Army you wish you had” offered in regard to a war of choice, not of imminent defense.)
With experience comes wisdom. Wisdom is a manager's worst nightmare unless they were technical in the first place.
People who are good managers almost always try to solicit as much criticism and feedback as possible. Especially from the most experienced people, since they know where the bodies are buried.
Galois: Was shot in a fabricated duel (like Lermontov and Pushkin BTW). The setup exploited certain concepts of honor and - kind of ironically - hot-tempered youthness, susceptive to this.
This article plays off a stereotype that I don't think it particularly helpful (or accurate). I've worked with experienced engineers who are all about the RDBMS, but I've also come across young engineers that don't know about anything more than RDBMSs because their university didn't teach them any more than that. I've worked with young engineers who were reluctant to go out of their comfort zone (and by that, I mean work in the JavaScript layer of the Java webapp they were working on), and I've worked with a whole team of really experienced engineers who had spent their whole career doing C/C++ who decided to build a product on Node.js.
I would agree with the point that having a diversity of backgrounds and perspective can be helpful on a software team. We need people who keep asking "why" on a team, and we need people with historical background. But to assume engineers are a particular way because they are old are young is (1) not accurate and (2) setting a large part of the population up to not meet your assumed expectations.
There is maybe 1 in 10 or 50 Young devs that had luck to work in something like good dev agency and build serveral projects to gain needed experience.
For me age doesn't matter that much because:
* You could be 50 and worked on 2-3 projects entire life * You could be 30 and worked on 25 projects or more.
> There is maybe 1 in 10 or 50 Young devs that had luck to work in something like good dev agency and build serveral projects to gain needed experience
This seems like it's implying that knowing the difference between a Queue and a Stack is a good indicator of experience.
How do you figure that as a good signal?
Queue vs stack is an extremely basic concept. They're not even unique terms to CS. You can almost guess what they are just by their names.
To be fair, I've been programming enterprise systems for 6 years now and haven't been interviewing in at least 18 months. This question threw me off. Once I googled it and read a whole two paragraphs it jarred my memory and I can speak to it. I can speak to what they do and when I would use one or the other. I can also reference real-world situations where I implemented a queue or a stack.
But lately I've been knee deep in data analytics for the last 18 months and simply haven't touched those "queue / stack" tools in a while. So I needed a "quick lookup" to refresh my memory.
Now if I was actively interviewing, this might be something I would review, as it's a fairly common interview question.
There is tendency for some people to stop progressing and change their demeanor as they age and that's what I call "old".
On the other hand if you keep being inquisitive, energized, continue learning including from your own mistakes, you are getting "experienced".
--
- What does a company pay for when they pay large sallary for an experienced engineer?
- They pay for all the mistakes he/she made at her previous job.
As you grow older, you start to truly understand that life is finite, with everything that entails: loved ones growing older, and passing away, you noticing your own body changing as well as you enter middle age, noticing how your own perspective and experience of passing of time shifts (when saying "20 years ago" isn't an abstract phrase, but an experience you lived through), and also noticing how the expectations others have of you start shifting.
That doesn't mean you can't be inquisitive, energized or wanting to continue learning from your own mistakes. I do that all the time, as I understand the importance of learning throughout life ...
... but I'm far more conscious of the value of time and how I use that time shapes me as a person.
Being experienced also means being in control over your time and your life, knowing to set boundaries and keeping a healthy balance between your priorities, and the priorities of others, which also includes the priorities of clients and employers.
Let's not forget that the "tendency for some people to stop progressing" also tends to be used as a strawman argument in order to undercut the importance of the above and push people to change their priorities in ways that may fly against their own self interest.
That's why I've grown weary about generalizing arguments that one has to "progress" without stating exactly why, within which specific context, or within which specific boundaries.
It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.
Someone who's young, just got their first job, needs the money and is insecure about their ability to get another job will not take the same risks as someone with a decade of experience, that has a network and knows they can get a new job if they need to.
Similarly someone close to retirement might have the most to lose in the few years before pension kicks in.
So it rather seems that what we need is to give people a work environment where they don't have to be afraid of speaking their mind or making mistakes.
> It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.
Wholeheartedly agree.
Notably, this is also the underlying key to accelerating a team's velocity, whether we're talking about TDD, CI, blue/green deployments, database schema rollbacks, canary releases, blameless retrospectives, Lean Startup MVPs, or many other tactics.
The basic strategy is: focus on reducing the cost of making a mistake (and learning from it) instead of on making fewer mistakes.
Because the easiest way to make fewer mistakes is always to do nothing (alternatively, "nothing interesting", or "nothing new", etc.).
Developing without fear isn't so much "move fast and break things", it's more "Move fast and have an undo button (for anything important you might break)."
Once we had rechecked everything for the n-th time, the job of mounting it all took about half an hour.
This is in stark contrast to software development with git or similar, where there's little to no fear when making radical changes, as it's easy to undo, have multiple versions in different branches for comparison etc.
That way we can deploy to production quickly and with far less worry than before we had this system. If a user runs into a blocking issue they can just re-launch a previous version and continue working.
I don't think normalization was ever about storage space.
> I don't think normalization was ever about storage space.
I'm not the GP, but...
I had to sell the "extra" work and complexity to a nontechnical stakeholder who considers themselves a power user of Access and Excel and wants every report to be a single simple query with no joins that they can write and run on their own.
BTW, the same stakeholder also wanted to shard data by month through table-naming conventions (ie. SELECT SUM(Total) June_Total FROM June_Sales) and get aggregate reports by looping through these tables.
So, yeah, the winning argument came down to money for storage (larger hard drives & bigger backups of the duplicated data) vs. having an employee run reports for him.
Project work. Client relations. Lots of "general" business / work skills.
If I meet some 50 year old dev, that's been at it professionally for 25-30 years, I will at least assume that he / she are somewhat knowledgeable in some of those areas.
If you've worked on, from start to finish, on tens of projects - you've probably seen and experienced a wide variety of things.
So, yeah, while younger and more inexperienced devs can be technically astute, it's always good to have experienced mentors that can guide you through the other stuff, not only the nitty-gritty technical details. After all, software development is much more than just punching out lines of code.
> Once, if you had lots of data, you had to store it in fully normalised form, because storage was expensive.
First time I heard that NF's were considered to save space...
Space saving is one of the primary advantages of relational databases, the other being tracking complex data relationships
Nowadays, it's not storage that is expensive, but CPU cycles, and RDBMS are processor expensive relative to NOSQLs
I advise clients to avoid RDBMS without a very specific need for complex data relationships
I do think people adopt the modern theory because of its flexibility.
If you have a team all within a certain range, they’re going to mesh. It’s less likely that someone significantly older will. I liken this to the old smokers problem. A lot of political machinations happened when people went outside to smoke together. If you didn’t smoke, you were left out of important conversations. I’m 56 and I’m already left out of a lot of discussions that younger coworkers have. There’s definitely a problem in the IT works in how it builds teams and excludes older workers.
We’re expected to be managers or executives. Not a part of implementation.
Seeing him combine his assembly language/c knowhow AND algos made me realize that with FOCUSED experience you can do amazing things.
Then again when I told him my favorite language implementation , Haskell/GHC, was using his library he asked: what is Haskell?
Focused training is everything. You can’t be good at everything but you can be great at something.
If the project had been tempered with some seniors, it could have been done in 6-9 months with 3 - 5 people. It's pretty straight forward work.
Having to excavate and rehabilitate all of the poor decisions and practices due to inexperience has taken time. It's nothing I haven't seen before, though.
If ageism in tech is real, then older programmers are being systemically undervalued by the market (probably in a huge way since I’d expect older good programmers to be be better than younger good programmers).
If I was doing a start up I might advertise roles that are for 40+ year old candidates only and see who I could attract.
Nope. Not even close to being true. Unless you think taking old tech and rebranding it is "new tech". People are reinventing old tech every day thinking they are doing something new. It is evidence of lack of knowledge of history. Nothing else.
Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving. What I provide as a senior engineer is if we're paddling across the lake, I'll keep us dry. Oh, and yeah, that'll cost you.
What I like about the article is they suggest the older folks have nothing to lose closer to retirement, and that makes them super valuable. I'd suggest that's true of the junior folks. It's the middling folks that have the most to lose, I suppose.
Why would I pull an all-nighter playing a video game? Same reason except for the well-paid part.
When they go home they're just playing Fall Guys and rewatching Blade Runner, wishing Cyberpunk 2077 was out already.
I meet that description and reading this thread I was beginning to think I was much less motivated than my peers.
If you're well funded (or if this is a new project in an existing company) I would make sure to allocate a reasonable portion of the budget for senior engineers or if I couldn't find any true senior engineers I would get the best motivated mediors and give them an enormous education budget.
My first couple of agile projects where like this - you can also bring in external consultants to help with getting up to speed.
I'm not using "a senior engineer" because it's not a given that somebody has some expected perspective simply because of the title or the time worked or even the education they had.
> Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving. What I provide as a senior engineer is if we're paddling across the lake, I'll keep us dry.
This is an extremely narrow vision of the nature of engineering and engineers. It makes sense if the problems you're dealing with are whiteboard interview problems. Real world projects are much broader in nature and context.
At a very bare minimum, the experience on solving a broad spectrum of problems, and dealing with the related context, brings:
- more solid solutions
- simpler solutions
- more fitting models
- anticipation of dead ends
- stability in the long term
- etc. etc.
I think there was talk, some time ago, on HN on this subject - if the only difference in 10 years of experience is "keeping dry across the lake", then one is a junior engineer with 10 year of experience, not a senior engineer (and/or somebody who doesn't see the difference).
I am, at almost 20 years in. I'm not only better at doing things well and safely, I can do them faster than ever because I know what's a solved problem and what's not, where to look for pre-existing solutions and how to apply them, what the pitfalls might be etc.
some young software people are very technically adept, but far from all are.
See I'm waaay better at it. Not in terms of raw problem solving ability, but because I've solved so many unique problems by now that I can start a new one half way through.
That and my skills are a lot more refined, so there are a lot of things I will do the right way out of habit which I would have had to discover through iteration 5-10 years ago.
If you're not better at what you do than you were 10 years ago, it makes me wonder what you've been doing with your time.
Paying people even if it's below market is fine. We all have to start somewhere.
Old programmers tend to say "That's how we do things here.", experienced and mind-opened ones can lead you to finally replace the classic old php 5.4 require mess that is your framework.
Sadly, there are plenty of old programmers outta here, and young ones are just trying to save their jobs because of this market.
The end result would probably be well argued strategy of incrementally adopting new ideas, testing them, and re-writing when time permits.
Furious activity is no substitute for understanding. - H. H. Williams
... via https://github.com/globalcitizen/taoup
[0] https://theconversation.com/most-successful-entrepreneurs-ar...
I wish you luck fundraising.
A number of UK banks have had disasters TSB, Santander caused by not having enough older more experienced developers.
Inexperienced people can build small orgs into business crippling holes.
People stupidly think programming is applying the most common patterns to the most popular frameworks. That is one type of programming inexperienced young people do. More typically it requires some strong domain knowledge. For instance one particular system I worked on was mostly written by one person who obviously had a lot of experience in the field. I think the younger programmers complained for many many years about the implementation, but none of them could have written it. This person had to ignore everyone else, who he knew were complaining without any experience to back it up, to get it done.
There is no difference how maintainable the code base is?
I've seen a very well-known business, which is regularly discussed on HN to grind to a halt and fall behind all of it's competitors in a very fast-growing and fast-moving space because it was built on a ugly spaghetti monolith developed by someone with PhD in history and almost no experience in engineering. And that's only the first of many examples I can think of.
You might also want to read Refactoring to Patterns, but the legacy book is more important to start with.
Oh, and you should get good at incremental refactorings, and at downscoping your improvements so that they become feasible and easy to sell. Or even not require any selling as they can be done as part of normal work. It is not the big rewrites that get done, it is the small improvements that take only a little time, so learn how to compound them.
By the way, getting good at the above points will over time also change your own priorities.
Also I would not frame it as playing them. That is the wrong mindset. You should be among for a high level of trust from their side and then playing them can backfire.