[HN Gopher] We need young programmers; We need old programmers
___________________________________________________________________
We need young programmers; We need old programmers
Author : mrcsharp
Score : 244 points
Date : 2020-09-21 08:05 UTC (14 hours ago)
(HTM) web link (blog.ploeh.dk)
(TXT) w3m dump (blog.ploeh.dk)
| PaulDavisThe1st wrote:
| There's a fundamentally incorrect claim at the heart of this
| article.
|
| >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.
| rmah wrote:
| I agree so much. When I started my career as a programmer
| around 25 years ago... I used a text editor in a GUI. OOP
| frameworks were new, but they weren't much different from the
| ones around today. Sure, some of the specific tools have
| changed. But the day to day and the concepts used (OOP,
| processes/threads/async, networking, filesystems, signals,
| etc.) are all the same. I think the biggest changes is the huge
| increase in availability of information (docs, sample code,
| etc).
|
| 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. :-)
| sys_64738 wrote:
| This is about control by managers. Older or more experienced
| developers will often call out BS if a manager makes a faux pas
| for whatever they are delivering. Younger programmers will work
| longer hours to make the managers look good.
|
| With experience comes wisdom. Wisdom is a manager's worst
| nightmare unless they were technical in the first place.
| dcolkitt wrote:
| I think this is only true if you're working under bad managers
| or in a corporate culture that incentives bad management
| practices.
|
| 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.
| potta_coffee wrote:
| Good managers are like unicorns. I have yet to see one.
| sys_64738 wrote:
| There are some great managers but they're usually from a
| tech background and know not to micromanage. Non-tech
| managers are really glorified PMs.
| ChrisMarshallNY wrote:
| Well, I'm a bit tired of this "debate" (there actually isn't one
| -it's all about personal emotional baggage, when it gets stripped
| down to the bare skeleton, and we can't actually reason with our
| reptile brains; which is where this stuff lives).
|
| 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.
| etripe wrote:
| > "Good judgment comes from experience. Experience comes from
| bad judgment."
|
| 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.
| ChrisMarshallNY wrote:
| _> 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...
| mixmastamyk wrote:
| Boomers are retired now or soon to be, no? 1950 was 70
| years ago. How about GenX? While we didn't invent
| computers, we grew up building them at home from kits and
| later Computer Shopper. Very few folks get that experience
| any longer, outside of connecting a USB device.
| ChrisMarshallNY wrote:
| I'm 58, which is sort of "the last of the Boomers,"
| maybe. I don't remember the year range.
|
| 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
| rytis wrote:
| Unrelated to the subject of the article, but this I find
| questionable:
|
| > 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...
| AndrewDucker wrote:
| If you only store a customer's address once, rather than having
| a separate copy everywhere you store the customer, then that
| saves a lot of space (as well as ensuring that different
| instances don't contradict each other).
| marcosdumay wrote:
| AFAIK, old hierarchical databases had a very similar space
| usage as relational ones.
|
| I do think people adopt the modern theory because of its
| flexibility.
| rendall wrote:
| Yes, that is surprising to hear the first time, but it's true.
|
| 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
| rimliu wrote:
| I'd advise your clients to avoid your advise if I could.
| griffoa wrote:
| Young programmers are only idolized because they are the only
| ones you can convince to build your sausage app for pennies.
| arcticbull wrote:
| Lower pay, longer hours, and technically, just as strong as the
| senior folks. In part because they don't know better, in part
| because they're looking to prove themselves, and in part
| because without a family they don't have much else to do on a
| weeknight. Speaking from my experience as a junior engineer,
| that is.
|
| 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.
| Nursie wrote:
| > 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.
|
| 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.
| C1sc0cat wrote:
| The younger developers are not out with friends going to the
| pub / cub on weeknights?
| arcticbull wrote:
| I certainly drank my fair share haha, but it was often
| after working until 10pm. I'm referring more to the
| 4pm-10pm window you'd normally (I assume) be picking the
| kids up from school, making them dinner, berating them for
| not having completed their homework, and so on.
| C1sc0cat wrote:
| Why are you working till 10pm?
| Jarwain wrote:
| That's what the weekend is for.
| reificator wrote:
| I'm not trying to be rude here but have you met the average
| developer?
|
| When they go home they're just playing Fall Guys and
| rewatching Blade Runner, wishing Cyberpunk 2077 was out
| already.
| Juliate wrote:
| If "average developer" were a thing.
| dexterdog wrote:
| An average developer is easy to measure. He completes a
| man-month in one month on average.
| batsigner wrote:
| Congrats: you have created item id 24542069.
| rgblambda wrote:
| >>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.
| LaurensBER wrote:
| A good senior engineer makes sure that your app is still
| maintainable and scalable at the 1/2/5/10 year mark. If your
| never make it past the 1 year mark he or she will not provide
| any value.
|
| 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.
| C1sc0cat wrote:
| Yeh this exactly for a start-up and new projects you really
| do need experienced developers in the initial stages.
|
| My first couple of agile projects where like this - you can
| also bring in external consultants to help with getting up
| to speed.
| arcticbull wrote:
| I would go even further and say a senior engineer knows not
| just what to invest in, but what not to invest in. For
| instance, if you're solving zero-to-one problems, a senior
| engineer may caution you to avoid too much architecture and
| instead focus on development velocity at all costs. After
| all, what good is a well-crafted app in chapter 11?
| acqq wrote:
| A longer-term thinker will also have another idea about
| what can be considered "a well-crafted app" than somebody
| being interested to use one more hottest technology of
| the moment.
|
| 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.
| arcticbull wrote:
| Very true.
| pizza234 wrote:
| > technically, just as strong as the senior folks.
|
| > 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.
|
| those are the things that popped into my mind in a few
| seconds.
|
| 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).
| C1sc0cat wrote:
| That is what they meant by "I'll keep us dry."
| arcticbull wrote:
| Just to clarify I said "in terms of rote problem solving"
| which is what you referred to as "whiteboard interview
| problems." When I said "I'll keep us dry" I meant exactly
| the items you listed, with a particular focus on
| anticipating and avoiding problems and ensuring long-term
| stability over near-term thinking when appropriate.
| skohan wrote:
| > 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.
|
| 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.
| drenvuk wrote:
| Yup. They're driven by dreams far more than responsibilities
| and that dreaded death timer. It makes me feel a bit old tbh.
| asou wrote:
| You mean hack something out that doesn't actually work ?
|
| Paying people even if it's below market is fine. We all have to
| start somewhere.
| rmason wrote:
| I think one of the main values of senior developers is they've
| seen a few cycles. If something has been tried four times before
| and failed there's a pretty good chance that it will fail the
| fifth time. But if the boss has only seen it fail once he's going
| to try again, then when it fails get mad at you. He will be mad
| because of your calling it out in advance he will feel you're
| undermining his authority whether or not that's your intention.
|
| 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.
| bregma wrote:
| There is no old grizzled sarge because either the resume gets
| canned because it shows a university graduation date from last
| century, or because someone with a greying neckbeard and 40
| years successful on-the-job experience can't be bothered
| spending a day doing pointless whiteboard exercises to prove he
| knows something that will never be used and is not applicable
| to anything but pointless whiteboard exercises.
| user5994461 wrote:
| There is no old grizzled sarge because personal computers
| have been out for less than 20 years.
| pwinnski wrote:
| TIL that my IBM PC AT clone in 1987 was not a personal
| computer.
| kevin_thibedeau wrote:
| Better still. Your modern PC retains backwards
| compatibility and emulates hardware quirks of this "not a
| PC".
| 6gvONxR4sf7o wrote:
| You should take a look at how personal computers were
| affecting the economy in the 1980s.
|
| 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%E
| 2%80%...
|
| [2] Rise in digital technology use of computers, 1980-2020
| jfk13 wrote:
| That's...a little off. I started out writing programs on my
| school's Commodore PET around 40 years ago.
|
| Some people might regard me as grizzled, I guess.
| joefourier wrote:
| Is this an attempt at humour I'm not understanding? The
| eponymous Personal Computer came out in 1981, and it came
| in an already thriving market with the likes of the Apple
| ][, Commodore Pet, TI-99, etc.
|
| Heck some of the essays from Paul Graham date from the 90s.
| user5994461 wrote:
| It's hyperbole to illustrate that looking for people with
| 40 years of experience in personal computer is like
| looking for people with 10 years of kubernetes
| experience. You don't see any because they don't exist.
|
| 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.
| pwinnski wrote:
| There are many, many, many people with close to 40 years
| of PC experience. The k8s example is not analogous
| because the set of people with adequate experience is 0,
| while the set for PC experience is much much much higher
| than 0.
|
| 20 years? You are literally MULTIPLE decades off.
| joefourier wrote:
| I'm not sure what experience in "personal computing"
| would entail as opposed to specific systems like
| Kubernetes. You could find someone with 40+ years of
| experience in Unix, C, or writing 6502 assembly code,
| with varying degrees of relevance to modern day work.
| Someone who has 40 years of experience with the 8051 or
| PIC microcontroller could conceivably be useful today, so
| if you wanted your grizzled old sarge, you could have
| them, assuming you were willing to pay enough money or
| had an interesting enough project.
| microtherion wrote:
| May I ask when the place you grew up in acquired indoor
| plumbing?
|
| Apple was incorporated in 1976. What do you think they did
| for the first 25 years of their existence?
| confidantlake wrote:
| PCs came out in the early 2000s?
| user5994461 wrote:
| Sounds about right. Could say late 1990s if you were in
| the right location in an affluent family.
| pwinnski wrote:
| In San Diego, in 1987, I attended college using Pell
| grants from the US government because my family was
| considered below the poverty line. They provided enough
| money to cover tuition, books, and room and board, but I
| lived at home and used the room-and-board money to buy an
| IBM PC AT clone.
|
| 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.
| acdha wrote:
| You're off by a couple of decades: https://en.wikipedia.o
| rg/wiki/History_of_personal_computers
|
| 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.
| analog31 wrote:
| I started college in 1982, majoring in math and physics.
| The professors all had personal computers on their desks.
| I bought myself one for under $1000 the next year. By the
| time I graduated, even the computer science professors
| were using personal computers, though student assignments
| were still done on the mainframe.
| user5994461 wrote:
| Where were you living?
| analog31 wrote:
| I grew up in Michigan and went to one of the many small
| liberal arts colleges in the state.
| leothecool wrote:
| The TRS-80 was $600 in 1980. That's still less than $2000
| in today's dollars, in the same ballpark as a macbook,
| and around the same price as a VCR.
| retrac wrote:
| I did some searching. Most stats suggest that by 1985,
| more than 10% of American households, and a slight
| majority of small businesses, had a personal computer.
|
| By 2001, it's 60% and nearly 100%. I agree with the
| others. You're about two decades too late in your
| estimate.
| OliverJones wrote:
| Yeah. I started out in 1969 as an intern doing
| electrocardiogram analysis on a CDC 8090. It had four banks
| of sixteen KiB of twelve-bit core memory (yeah, little
| magnetic washers threaded onto a square screen of wires).
| Obvs 8090 assembler is now useless as a skill. But the
| thinking and troubleshooting skills needed to make that
| stuff work? Still use them every day.
| necheffa wrote:
| Lolwut? Personal computers have definitely been around
| _longer_ than just 20 years. Maybe not 40, but it is
| ludicrous to suggest _less_ than 20 years.
| michael1999 wrote:
| MS DOS was 1981. I got my vic-20 in 1984. But fair point,
| the actual numbers employed were tiny compared to current
| needs. Average experience is thin out there. The old timers
| clump, both in firms and geographically.
| proverbialbunny wrote:
| >He will be mad because of your calling it out in advance he
| will feel you're undermining his authority whether or not
| that's your intention.
|
| This is where communication skills come in. The more one levels
| up their communication skills the easier situations like this
| are to overcome.
| blablabla123 wrote:
| Both are really needed, especially when there is a lot of
| complexity. It's no fun to work buggy code that is buggy
| because lots of best practices were ignored/there is too much
| experimental stuff there at once. There is also a need for
| (usually young) people who doubt existing wisdom and try
| impossible things to find out they suddenly work.
| Retric wrote:
| Lack of development time and or skill is more likely to
| result in a buggy mess than failure to uphold best practices.
| What's confusing the issue is skilled people given sufficient
| time and support generally use best practices.
|
| 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._
| gregdoesit wrote:
| I've observed a company in London who followed a brilliant
| strategy with hiring old engineers and (very) junior ones.
|
| 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 PS50-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.
| username90 wrote:
| > The "old ones" brought a lot of maturity, practices (TDD,
| tests, even XP at times) and loved mentoring the super
| enthusiastic grads.
|
| 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.
| t-writescode wrote:
| Imagine how much more even more experienced developers can
| bring to the table, especially if they've been keeping up and
| growing :)
| username90 wrote:
| The few who continues to grow after 10 years gets into
| extremely well paid positions and have no problems getting
| jobs. We aren't talking about them here, we are talking
| about the majority who never grow out of their senior
| engineer position. They aren't more valuable after 20 or 30
| years than they were at 10 since they stopped growing, and
| this is the majority of people in every field.
|
| 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.
| benjaminjosephw wrote:
| > We need old people because they're in a position to speak truth
| to the world
|
| 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.
| codingdave wrote:
| > They are rarely willing to risk everything for the chance to
| make paradigm leaps.
|
| 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.
| jillesvangurp wrote:
| Simple demographics cause the number of programmers to double
| every 5 years. I'm 45. Any project I join, I'm extremely likely
| to be the oldest person around. That's not because all my
| generation has long retired into management but because there are
| about (2^4) 16x more younger people around in the industry, with
| most of them being below 30 and because becoming a developer was
| just not a common career path when I left high school. In 5 years
| it will be 2^5=32 for me. I'll still be coding though because I
| like doing that.
|
| 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.
| dpc_pw wrote:
| Surprises me how few people understand/mention the "programmers
| doubling"
| shekharshan wrote:
| Focus on keeping your knowledge current. If you have sound
| grounding in modern stack from virtualization and up using
| containers and monitoring, I don't see why you should worry about
| anything. Always be ready to code and even be ready to get your
| hands dirty with RDBMS query plan troubleshooting.
| UncleOxidant wrote:
| The older I get, the less I know. When I was in my 20s I thought
| I knew a whole lot about embedded software development. Now in my
| late 50s I seem to be painfully aware of how little I actually
| know. Maybe this is part of the risk-taking mindset of being
| young: they don't yet know what they don't know so they're not
| encumbered by that realization. If I had felt this way in my 20s
| I would have been paralyzed by doubt. Now, with experience I
| realize that most everyone is essentially driving in the fog.
| Sometimes you can only see a few yards ahead and you have to just
| become comfortable with the uncertainty while doing what you can
| to mitigate it. When I was younger I either didn't see the fog or
| thought I needed to pretend it wasn't there.
| backtoyoujim wrote:
| as a mediocre programmer who is now old let me tell you that you
| still do not need me.
| username90 wrote:
| The question isn't whether you'd hire a new grad or a guy in his
| 50's as many here seems to think. The young option is a guy in
| his 30's with 15 years of experience, they are much easier to
| find than older programmers (due to the number of programmers
| increasing exponentially over that time) so most senior hiring
| will be targeted at them.
| 8lall0 wrote:
| We need young and experienced programmers, not the old ones.
|
| 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.
| brailsafe wrote:
| An experienced programmer might look at the problem of whether
| or not the company should replace php 5.4 and determine whether
| or not it's a completely or partially a good idea based on the
| factors they have control over and have budget to solve. An in-
| experienced programmer would probably not have learned PHP 5.4,
| and so would need to replace it in order to be productive,
| regardless of accounting for how much value they actually add
| by doing so.
|
| The end result would probably be well argued strategy of
| incrementally adopting new ideas, testing them, and re-writing
| when time permits.
| confidantlake wrote:
| Being old does not make you close minded. People who assume old
| people are close minded are ironically close minded themselves.
| [deleted]
| jakuboboza wrote:
| I'm 36. I interviewed in last 10 years probably more than 250
| candidates. Young programmers. Imagine that more than half
| couldn't explain what is the difference between queue and stack.
|
| 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.
| dgellow wrote:
| You could take any of those young dev, teach them what a stack
| and a queue are in almost no time. The fact that they didn't
| face that question before doesn't mean they are bad picks for a
| job.
| ZephyrBlu wrote:
| > Imagine that more than half couldn't explain what is the
| difference between queue and stack
|
| > 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?
| thelean12 wrote:
| It's not a good indicator of experience. But it's probably a
| decent indicator of a lack of experience.
|
| 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.
| tomohawk wrote:
| Perhaps instead pose a problem where a queue and a stack would
| normally be used and have them solve it and explain their
| solution. You can tell a lot more about someone than asking a
| context free question on theoretical constructs. Is it more
| important to have someone who approaches a problem
| theoretically or practically?
| SamuelAdams wrote:
| > what is the difference between queue and stack
|
| 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.
| silveroriole wrote:
| Isn't the clue in the name? :) I feel like it's almost a mind
| trick. Ask anyone off the street what the difference is
| between a queue of people and a stack of plates, and they'd
| get the right answer pretty quick - but ask a tech person in
| an interview and they'll panic! (Which probably proves it's
| not a very good example to judge applicants by on its own)
| [deleted]
| magicalhippo wrote:
| While I don't disagree with the conclusion, I'm not sold on the
| argument.
|
| 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.
| webmaven wrote:
| _> While I don 't disagree with the conclusion, I'm not sold on
| the argument._
|
| _> 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)."
| magicalhippo wrote:
| As a personal analogy, we're currently redecorating our home.
| We've just spent about 4 days planning the layout of the
| electrical boxes and wiring pipes for a small hallway. Once
| it gets covered by the rock sheets and all that it's a PITA
| to make a change.
|
| 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.
| webmaven wrote:
| Right, but the correct analogy for putting up the drywall
| is deploying to production...
| magicalhippo wrote:
| At work we have a launcher that lets our users select one
| of the five previous minor versions of potentially
| multiple major versions they have installed. A local
| service checks for new versions every hour and downloads
| them automatically.
|
| 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.
| ericmcer wrote:
| Part of this could also be attributed to the way older
| generations approach work. You find a company, put in your 30
| years, then retire. That makes you a terrible prospect in the
| tech industry. 10+ years of doing repetitive tasks or exploiting
| domain knowledge to maintain some legacy system means you are far
| behind in both knowledge and motivation.
| _trampeltier wrote:
| I just think you just need a good mix. This is not just true for
| programmer but so many other jobs too. The young guys often have
| fresh ideas and work a lot, but yes, they fail sometimes. The
| older guys say maybe more "no" to a bs idea from managment/top.
| There are many things more .. and thats also not something new.
| incompatible wrote:
| "Once, if you had lots of data, you had to store it in fully
| normalised form, because storage was expensive."
|
| I don't think normalization was ever about storage space.
| webmaven wrote:
| _> "Once, if you had lots of data, you had to store it in fully
| normalised form, because storage was expensive."_
|
| _> 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.
| scanny wrote:
| How is the situation different from any other industry? Fields
| like civil engineering or accounting surely don't have these
| conversations?
| lnsru wrote:
| I don't think, somebody needs old programmers. Look from business
| perspective: there is no difference how polished code base is.
| Younger folks can develop the same product with lower salaries
| than grown ups. Yes, they will look for greener grass, or do some
| crazy things, but business gets same output at lower cost. I am
| experiencing this at my current workplace. It is desired, that
| people leave after few years and freshmen can be hired again.
| Experience has zero value in business context.
| sreng3678 wrote:
| It depends on the work and the caliber of talent. It also
| depends on the state of the organization. Some fields require
| specialized skills, and experience is highly valuable.
| Programmer is broad term. Not everyone is building crud apps.
|
| Inexperienced people can build small orgs into business
| crippling holes.
| one2know wrote:
| Actually that's not true. Experience does matter. In one
| particular class I took we implemented a simple marching cubes
| implementation, or rather I did because the rest of the class
| could not complete it. I had about 8 years of experience in
| graphics type programming at that point.
|
| 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.
| kinghtown wrote:
| Awesome comment. When you become old you'll then be talking
| about the value of experience and how that makes business
| sense. You'll switch because you think exclusively in terms of
| self interest.
| lnsru wrote:
| I am already graybeard. I had eye opening moments looking for
| a job right before pandemic. Now I desperately want to
| produce some rental real estate and leave engineering.
| contingencies wrote:
| This is the classic naive perspective. To a serious extent,
| experience tells you what to build and when. The actual
| building is quite often better to farm out to someone who can
| be bothered to trawl through familiarity with the latest
| 5-minute javascript framework. That is why successful founders
| tend to be middle aged[0]: they know when not to waste
| resources, and to use the right tool for the job. That tool
| might be you.
|
| _Furious activity is no substitute for understanding_. - H. H.
| Williams
|
| ... via https://github.com/globalcitizen/taoup
|
| [0] https://theconversation.com/most-successful-entrepreneurs-
| ar...
| C1sc0cat wrote:
| You are hoping they actually build what you told them to -
| from bitter experience.
| arcticbull wrote:
| > Experience has zero value in business context.
|
| I wish you luck fundraising.
| lnsru wrote:
| Luckily I am in industrial electronics without a smallest
| chance of fundraising.
| anderkas wrote:
| You must have a different definition what is "business
| context". In business context, it's all about selling your
| ideas and making money for the business - even as an
| industrial electronics.
| lnsru wrote:
| In this case I see business context as a cost structure
| of my current employer. I clash almost everyday against
| big bookkeeper army of the big Corp. Their view is very
| primitive: engineer costs money, they don't differentiate
| by experience, age, capabilities. Even mythical 10x
| engineer (there is one in the whole floor!) is just
| another row in excel. Technical people often overlook the
| fact, that organizations are run by bookkeepers and so
| called business people. They have no background to judge
| technical development. If they can sell code written by
| freshmen, why should they hires bunch of experienced and
| expensive experts?
| C1sc0cat wrote:
| Unless they fuck up - for example a botched site migration that
| causes massive losses and ends up mentioned in the financial
| pages.
|
| A number of UK banks have had disasters TSB, Santander caused
| by not having enough older more experienced developers.
| helsinkiandrew wrote:
| To be fair - the example of the UK banks who had disasters
| was because the systems in question were usually old 'legacy'
| systems that were being slowly replaced by new tech and newer
| developers. It was a lack of developers with experience of
| those particular legacy systems when something went wrong
| that was the problem, rather than the lack of older
| developers with more experience of development in general.
| golergka wrote:
| > there is no difference how polished code base is
|
| 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.
| lnsru wrote:
| Could you, please, elaborate more about that ugly spaghetti
| monolith? I have similar situation at work. Maintainability
| is hard to measure, so my every try to measure and improve
| stuff ends with words "not a business case".
| yxhuvud wrote:
| Then learn their language and phrase your suggestions in
| ways that expose the issues to them in terms they
| understand. This requires you to fully understand what is
| important, and what is not important, to the business.
|
| 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.
| lnsru wrote:
| But is it really my duty to play managers, so they are ok
| with refactoring and improvements? I imagined somehow,
| that management and developers have same goals and it's
| natural thing having clean codebase and up to date
| electronics.
| bdavisx wrote:
| If you're looking for help fixing the mess you are dealing
| with, find the book Working Effectively with Legacy Code -
| https://www.amazon.com/Working-Effectively-Legacy-Michael-
| Fe....
|
| You might also want to read Refactoring to Patterns, but
| the legacy book is more important to start with.
| TrackerFF wrote:
| While this discussion seems to lean heavily on the technical
| parts, there are many aspects of a business that can only be
| learned through experience.
|
| 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.
| GnarfGnarf wrote:
| One solution is to be self-employed and make a product. I'm 71, I
| code C++/C# forty+ hours a week, and I'm having a blast. I just
| discovered the STL a couple of years ago.
| artificial wrote:
| Depending on what you make anther toolkit for fun C++ things is
| https://openframeworks.cc/.
| dstick wrote:
| That 5 monkeys story is definitely not false, nor fabricated.
|
| 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
| simongray wrote:
| That experiment makes me uncomfortable.
| saagarjha wrote:
| Perhaps it'll make you feel better that there's a good reason
| we do it: when everyone else is doing something, it's often a
| good idea to follow them. We all love to hear the one time
| someone does something contrarian and it turns out well, but
| in general if you have no prior knowledge picking the thing
| that other people is doing is a good strategy because they
| may know a reason you don't.
|
| A slightly better thing to do, of course, is ask why they're
| doing something.
| Verdex wrote:
| I mean a little bit yeah. But problem solving through peer
| pressure is a real thing and it's totally legitimate. You do
| get some weird artifacts (because it functions via a weird
| distributed statistical function) and it can be exploited.
|
| 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.
| geuis wrote:
| That entire video smells of being fake. I'll admit I don't have
| anything other than a gut reaction to the combination of
| production quality, editing, and sheer silliness to go on. But
| there's enough off that it raises my skepticism a lot.
| nestorD wrote:
| I have seen a video of the experience being reproduced in a
| trustworthy setting so I personally trust it.
| Shorel wrote:
| Nowadays claiming loudly 'fake' seems to be the argument used
| for most things we can't readily understand, or simply as a
| default noise maker.
|
| 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.
| klmadfejno wrote:
| > Nowadays claiming loudly 'fake' seems to be the argument
| used for most things we can't readily understand, or simply
| as a default noise maker.
|
| > 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.
| tomohawk wrote:
| Dropped onto a project this year that was put together by 15 or
| so juniors over 18 months. They're all gone, and there's now just
| 3 seniors (new team) trying to make sense of things and save it.
|
| 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.
| rightbyte wrote:
| How can 15 people be gone? Contractors?
| ransom1538 wrote:
| If you don't think experience matters, try this:
|
| 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.
| teraku wrote:
| This has nothing to do with age, and little with experience.
|
| 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.
| ransom1538 wrote:
| Age and experience are strongly correlated. Sure you can have
| zero experience and be old, you can have tons of experience
| and be young. But normally: Age and experience are strongly
| correlated.
| teraku wrote:
| I did not indicate otherwise.
| dlkf wrote:
| > This has nothing to do with age, and little with
| experience.
|
| 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.
| Shorel wrote:
| I would say it is a prime example of the difference between
| "necessary" and "sufficient".
|
| The time investment is necessary. It is by no means
| sufficient.
| teraku wrote:
| > It has to do with experience because skills can only be
| honed through experience.
|
| 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".
| dlkf wrote:
| > 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.
| teraku wrote:
| No, I think we just have a different view on what
| knowledge, skills and proficiencies means.
|
| 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.
| szszrk wrote:
| I think this was precisely his point. Also knowledge, skills
| and proficiencies are called just 'experience' when you don't
| want to go into great detail.
| tomohawk wrote:
| As an experienced software engineer and also an experienced
| home remodeler, you make a great point.
|
| 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).
| kebman wrote:
| Do you want to discuss pedagogy, and why some people only need
| one youtube video to do this task just fine, while you could
| show 100 to others and they would fail every time, regardless
| of experience?
| klunger wrote:
| He explicitly said that experience does matter. It's just that
| it was a well known argument so he wouldn't bother retreading
| it. So, I'm not sure what your point is.
| klmadfejno wrote:
| Seems like the better question would be to hire someone under
| 30 (who has some means to demonstrate basic qualifications) to
| do step (2) if you want your point to have any meaning.
| mbeex wrote:
| Somebody else finding the Monkey experiment a good one but wrong
| for the Authors cause? I mean, the cold water was an artificial
| external influence and just the opposite of something
| fundamentally impossible. To be precise, exactly the exact kind
| of obstacles against which youth has rebelled at all times. Its
| not the same as the changed circumstances he relates later in his
| article to.
|
| 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.
| rovolo wrote:
| The author is saying that the cold water represents the
| technological limitations in the past. "What old people don't
| realise is that sometimes, circumstances change."
| ChicagoDave wrote:
| There's a cultural aspect.
|
| 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.
| munificent wrote:
| For kicks, I'm going to throw out a possibly odd analogy.
|
| 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.
| cholmon wrote:
| Great analogy! I'll be mulling this one over for sure in the
| coming weeks/months.
|
| 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.
| Pet_Ant wrote:
| Fantastic analogy. I leaving this comment so I can find it
| later.
| eitland wrote:
| You can click on the timestamp and then favorite it. In your
| profile you can access favorites as well as even stories (and
| comments) you have upvoted.
|
| I won't downvote you but based on observations over the last
| decade it wouldn't surprise me at all if someone else does.
| Pet_Ant wrote:
| Thank you for letting me know; I have done that. I'll leave
| my comment up so maybe others will learn as well.
| foo_barrio wrote:
| It's interesting that you pretty much described a physical
| "discrete Fourier transform". Our cochlea works this way with
| different length hairs attached to nerves to hear different
| frequency ranges and old harmonic analyzers were build with
| this principle.
| munificent wrote:
| It's not a coincidence. :) My quarantine hobby has been
| getting into music, audio programming, and electronics, so I
| very much have Fourier analysis on the mind.
| UncleOxidant wrote:
| This is a good observation. I'm in my late 50s and more and
| more I keep getting the feeling "I've seen this (or something
| very similar) before" whether having to do with software
| development trends, politics, fashions etc. That old adage
| about there being nothing new under the sun didn't make much
| sense to me when I was younger, but now it seems to often ring
| true.
| munificent wrote:
| One of the things that I like about this analogy is that it
| also points out one of the pitfalls as we age. As our string
| gets longer, we aren't as good as picking up the higher
| frequency vibrations, so we risk assuming they aren't there
| at all.
|
| 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.
| UncleOxidant wrote:
| The analogy might be a bit weak on the short side: Higher
| frequency means that the thing comes and goes within a
| short amount of time. Did I really need to learn a
| technology that was only in vogue for a few years?
|
| 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.
| munificent wrote:
| _> Higher frequency means that the thing comes and goes
| within a short amount of time._
|
| 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.
| jkingsbery wrote:
| I'm not an "old" programmer (I don't think... I did have an
| intern ask me one time if I had ever worked with punch cards, so
| maybe I am...).
|
| 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.
| helsinkiandrew wrote:
| The most useful 3 things that age/experience has taught me
| personally are:
|
| 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)
| rovolo wrote:
| Here's the "unknown unknowns" quote [0] in context. Rumsfeld is
| responding to a question on whether Iraq had any connections to
| WMDs. He's justifying the invasion by saying that inspectors
| aren't allowed in the country, so the US doesn't know if there
| are WMDs or not.
|
| > 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...
| michael1999 wrote:
| Off topic: We gave Rumsfeld grief because most of his unknowns
| were in fact well known! He just didn't like the facts on hand
| and led NATO into an evil disaster because reasons.
| dragonwriter wrote:
| > There are unknown unknowns (I don't know why Donald Rumsfeld
| got so much flak for saying this)
|
| 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.)
| waylandsmithers wrote:
| On Rumsfeld, I would guess people who opposed the war and his
| party were ready to proclaim anything he said was dumb and
| wrong.
| lmilcin wrote:
| I don't like the label "old".
|
| 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.
| CaptArmchair wrote:
| I don't think that the full story. The bottom line is that as
| you age, you will inevitably start making different trade off's
| and choices.
|
| 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.
| sheepybloke wrote:
| For me, the big thing is that older developers need to use their
| experience in helpful manners. In my experience, it's used it to
| simply block or scoff at the actions of younger devs or managers
| while not always working to solve the issue. In order to be
| useful, you have to also work and suggest alternatives and
| solutions, otherwise you're just a curmudgeon. That's at least
| what I've found working at a site that is mostly older engineers.
| gtsop wrote:
| I am under 30. I find it very frustrating and unfair to see older
| programmers being displaced or misstreated because 1) I need to
| squeeze out every damn ounce of wisdom these people have in order
| to accelerate my own progress and 2) one day I'll be in their
| place. I want them to be treated the same way I will be treated.
|
| 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)
| Nursie wrote:
| I think using the "five monkeys" parable as an argument to
| favour the young is fallacious.
|
| 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!
| rightbyte wrote:
| If you bail every three or whatever year you kinda never get
| to see a big project start to finnish.
| ivalm wrote:
| Three years should be enough for a decent project to go
| from inception to production. Realistically you will join a
| big project in mid-progress so three years is def enough.
|
| 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.
| jlokier wrote:
| And if you don't, you kinda never get to work on more than
| one thing, and therefore grow and cross-pollinate ideas
| from different domains.
|
| 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.
| yxhuvud wrote:
| While you are right in that you shouldn't stay on the
| same place forever, there is definitely very huge and
| important lessons in staying at a place long enough that
| you don't only have to deliver something, but also get to
| maintain it over time.
| jlokier wrote:
| I've found I actually got to stay "long enough" to
| maintain delivered projects _much_ more an independent
| than as an employee.
|
| 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.
| jlokier wrote:
| While I won't ask why the multiple downvotes, because
| that's discouraged here on HN, I will express
| considerable surprise. Reading over it again, it doesn't
| strike me as a disagreeable comment, just another point
| of view about one type of working relationship over
| another.
| Nursie wrote:
| When is a big project ever "finished" ?
|
| 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.
| sumtechguy wrote:
| That depends on what space you are in. In an embedded
| space 5 years can be half way through a products
| lifetime. You usually have something fairly close and
| mostly done in 1-2 years. But the next 2-3 years is
| finding out all sorts of quirks in a real world physical
| environment.
|
| 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.
| rimliu wrote:
| What makes you think, that new ideas, techniques, skills,
| etc. do not reach old places?
| Nursie wrote:
| I've seen a number of examples in my time, smart people who
| found a niche and then let the world pass them by.
|
| 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.
| mtberatwork wrote:
| > one day I'll be in their place. I want them to be treated the
| same way I will be treated.
|
| 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... :)
| maratumba wrote:
| There is an assumption that "old" means "experienced" which is
| not necessarily true. There are people who transition to
| programming from other fields and are "old". Their value
| shouldn't depend on whether or not they fit the stereotype of
| "old timer hacker geeks". They should be judged by their
| skills, the same way the young ones are being judged.
| skohan wrote:
| Yes it's not about valuing age, but it _is_ about valuing
| experience. Sometimes raw talent and problem solving ability
| is the most important quality to look for, but sometimes
| experience in the field is incredibly relevant and valuable,
| and can 't be replaced by raw talent.
| jondubois wrote:
| If you're young, you fit in a narrow spectrum of experience
| with a relatively low upper bound.
|
| 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.
| Loughla wrote:
| >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
|
| 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.
| skohan wrote:
| I agree with you as far as these general skills, but I
| think that the value of applicable experience should not
| be discounted.
|
| 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.
| jondubois wrote:
| I think that on average, an older experienced developer
| will be more skilled than a younger one, even with less
| natural talent. Experience is really important.
| dimmke wrote:
| I agree with this. I've known some people who've been coding
| for 15-20 years who just coast, and end up in senior
| positions because of how long they've been employed when
| their skills are really at the level of a 2 year junior.
|
| 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.
| nitrogen wrote:
| Frontend dev is a really good example of a field that is
| all short strings and missing the longer trends. It doesn't
| matter what framework you use, or no framework at all, if
| the site can be maintained, the site is fast, and it looks
| good in all the browsers you are targeting. Bootstrap,
| jQuery, React, Vue, etc can all be sloppy, or they can be
| used incisively.
| collyw wrote:
| Out of interest what skills are you talking about? I am an
| old fart by IT standards and i have come to realise that
| being able to come up with an algorithm randomly is not
| such a useful skill considering how infrequently we
| actually have to do it. Being able to say "no" and getting
| on with other developers are far more valuable than being
| able to solve a soduku puzzle once you have acquired a
| certain level of knowledge. After that it should be about
| managing complexity.
| akiselev wrote:
| Not the OP but I largely look for experience with CI/CD
| workflows and release management,
| unit/integration/systems testing that doesn't cripple
| R&D, QA, distributed systems beyond a webserver & DB, and
| just general "philosophy of software engineering" type
| stuff like an understanding of the factors that led to
| the evolution from monolith to microservice,
| agile/scrum/management fad of the week, and how to make
| tech tradeoffs based on business goals. These are largely
| soft skills, not algorithmic trivia.
|
| 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.
| dimmke wrote:
| >i have come to realise that being able to come up with
| an algorithm randomly is not such a useful skill
| considering how infrequently we actually have to do it.
|
| 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.
| ryandrake wrote:
| But why?
|
| 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.
| dimmke wrote:
| >Do new languages, new language features, new frameworks,
| new methodologies necessarily add business value?
|
| 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.
| nitrogen wrote:
| But there are other considerations. The constraint solver
| in flexbox used to be a lot slower to render than other
| layout methods. And if you have experience in non-web UI
| frameworks, you can see that flexbox isn't that different
| from things you can find in Swing and Qt, so you can just
| wait a while and learn it in a day when you need it.
|
| 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.
| decafninja wrote:
| Often times none of that is tested during the interview
| though, so you don't know whether the person is
| knowledgable on any of those or other frontend specifics
| until you've hired them because they were able to pass an
| leetcode DS&A phonescreen and 3-4 leetcode DS&A onsite
| rounds.
|
| 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.
| dimmke wrote:
| It really just depends on where you're interviewing. A
| lot of places that hire software engineers don't ask
| algorithmic questions at all.
|
| 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.
| decafninja wrote:
| "where" is the key word here I think. But at least in the
| vicinity of the major US coastal cities (SFBA, Seattle,
| NYC, probably LA and a few others) where a lot of tech
| jobs are concentrated, I would say most companies are in
| fact, leetcoding candidates to some degree.
|
| 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.
| gabereiser wrote:
| For sake of argument though, can we assume all "old"
| programmers in this case are ones that have been doing this a
| long time and are actually competent? I'm not disagreeing
| with you, but I know those are in the minority of us "old"
| programmers. "Old" vs "Young" can be a measure of experience.
| SteveMoody73 wrote:
| I agree that age doesn't mean experience. I work in a company
| with a small development team and we're all around the same
| age group with no young programmers.
|
| 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.
| Nursie wrote:
| I've met those guys.
|
| 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.)
| auggierose wrote:
| What exactly is the meaning of "On the other side" here?
| JustResign wrote:
| I believe the best equivalent phrase would be "on the
| other hand" or "in contrast"
| Consultant32452 wrote:
| Some people have 10 years of experience. Other people have 1
| year of experience 10 times.
| nullsense wrote:
| And some people have 10 years of just not very useful
| experience.
|
| Not the same year 10 times but 10 discrete, non-overlapping
| years.
| juped wrote:
| Most people have 1 month of experience repeated 120 times.
| This is the only way to be employed and not starve.
| collyw wrote:
| Ten years of experience in one tech stack will give you
| mastery. 1 year changes with a new language / framework /
| tools every time will mean you are forever a novice.
| bdcravens wrote:
| Ten years of experience in one tech stack that has fallen
| by the wayside means you're outclassed by the developer
| with 2 years of relevant experience.
| ivalm wrote:
| If you know 10 different tech stacks you probably have
| immense breadth and can learn/do new things easily.
| That's is incredibly valuable. There is a massive
| difference when you are learning a new stack for 11th
| time vs 2nd or 3rd time. Sometimes you need people with
| deep mastery of some specific, sometimes you need people
| who have seen everything, can learn anything, and
| synthesize a broad view.
| ticmasta wrote:
| There's also old with lots of experience but it's 20 years of
| doing the same thing, or 10 x 2 years experience vs. 20 years
| of xp
| otagekki wrote:
| If the current trend in the software engineering market
| continues, in 2040 we'll most likely have much more
| profiles with 10x2 years or 20x1 year than 1x20 years. I
| have the impression that really few companies value the
| latter nowadays.
| Juliate wrote:
| Actually, they should be judged by what they can and do
| contribute to the team, whatever that is. Skills is a subset
| of that.
| maratumba wrote:
| That's a better way of putting it.
| virgilp wrote:
| This (and original) statement(s) are all good and nice, but
| meaningless (in the same way as "there should be no hunger
| in the world because we have enough food").
|
| 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".
| austincheney wrote:
| > HOW?
|
| * 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.
| rezeroed wrote:
| Re initiative. I've had jobs which did not want
| initiative on a macro level - my manager would tell me
| what was wanted, I'd go away and make it happen. Those
| managers loved me. My current role, bullshitted into a
| "devops" role, I'm expected to spend my days showing
| initiative - building things that I think will be useful
| - and which never get used. I'll take the former jobs.
| What I have now sounds like freedom, it feels pointless
| and torturously demotivating. Do my managers know what
| they're doing? Do they have any roadmap? Can they see
| shortcomings in our systems? Is it mushroom management or
| cluelessness? I think these positive sounding words eg
| "initiative" are not positive - they are context
| dependent. "Potential" - if you need someone writing
| endless crud, if they have potential are they going to
| stick around? Do you really want/need Achilles? Are you
| really leading the Trojan army? Maybe you just need
| sticky tape, not a welding torch.
| austincheney wrote:
| That is why it is so empowering to have options. I have
| two employers: one is among the largest and most
| profitable companies in the US and the other is US Army.
| In one of those initiative and leadership are rewarded at
| every level. That makes things interesting because it
| provides the freedom to rapidly experiment and prototype
| leadership to empower people the way I experiment with a
| side code project. In this environment the people you are
| leading are more eager to learn new things and be
| creative than my corporate coworkers that need a
| framework to do anything and panic at the slightest hint
| of originality.
| virgilp wrote:
| You touch on two issues here: one, that there's an entire
| gamut and not a binary "senior/junior"... and management
| just LOVE to present requirements like "Can walk on
| liquid water; God asks him for advice on how to run the
| world" when you ask "what do I need to do in order to get
| to next level", especially in big corporations [1].
|
| 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)
| virgilp wrote:
| I'm not saying "people can't be managed" and "one can't
| evaluate the performance of a programmer" - that'd be
| obviously false.
|
| 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.
| athenot wrote:
| Poor metrics are meaningless regardless of _what_ you try
| to measure.
|
| 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).
| virgilp wrote:
| It's all in the details. If I get to pick who rates "how
| useful", this translates into a general "how well liked
| by my colleagues am I" (general problem with 360*
| feedback; I'm not saying it's useless, but it does have
| its limitations)
| tstrimple wrote:
| The way I've experienced it is that when a measurement
| becomes a metric, it ceases to be a good measurement.
| When people's bonus is tied to a measurement, they will
| find creative ways to influence that measurement which,
| in many cases, defeats the purpose of what it was trying
| to measure in the first place. It's not simply a matter
| of choosing the right measurements. It's also a matter of
| how you incentivize those measurements.
|
| 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.
| brlewis wrote:
| If it's true that one can evaluate the performance of a
| programmer, what does that mean? Can it be reduced to a
| vector of scalar values?
|
| 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.
| gtsop wrote:
| > There is an assumption that "old" means "experienced" which
| is not necessarily true.
|
| 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.
| boomlinde wrote:
| So if I make a huge effort yet manage to remain incompetent
| and underperforming for my role, I should be kept on the
| payroll as a sort of charity?
| maratumba wrote:
| Treating people differently based on the class they belong
| in, in this case age, is the definition of discrimination.
| gtsop wrote:
| Firstly I am all in for discrimination that results in
| positive effects for people in need (as long as it is
| reasonable and not blind benefits for the sake of
| suposedly helping minorities)
|
| 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.
| throwawayinfo wrote:
| Positive discrimination is just discrimination, in all
| contexts. Older engineers don't need your charity.
| [deleted]
| reflectiv wrote:
| We are talking about technical abilities...if you
| discriminate outside of that, including age, I would
| whole heartedly call that the bad kind of discrimination.
| gtsop wrote:
| I am really not sure why my point isn't clear. I am not
| judging people differently based on age. I observe that
| skills/performance is not a fair metric for old people to
| compare against young ones. Thus, in order to create a
| field of fair competition I argue that for the baseline
| desicisons (getting and keeping a job) people of all ages
| should be judged on the effort they put in, a fair metric
| for all ages. Then comes the second layer of judgement
| based on skills which decides who gets promoted or gets
| performance bonuses. Old people would have less chances
| to win in this layer of judgement but at least they can
| keep their jobs safe as long as they put in effort.
| reflectiv wrote:
| By doing that you are hurting your business by not
| putting the best person in that position. Also, that
| better person can help bring up your younger less
| experienced staff.
|
| 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.
| TheOtherHobbes wrote:
| There's a common trope about an established worker who
| works really, really hard at tasks - evenings, weekends,
| the whole deal.
|
| 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.
| boomlinde wrote:
| _> 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._
|
| 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.
| the_gipsy wrote:
| Judge by effort? You gotta be kidding.
| EdSharkey wrote:
| It makes me happy to see folks not dogpiling on you. I'll
| try to be similarly gentle.
|
| 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.
___________________________________________________________________
(page generated 2020-09-21 23:01 UTC)