Conversely I find that a number of the old(er) programmers I've worked with are incredibly stubborn and bigoted. They refuse to see anything from another persons perspective especially if that person is young. As well refusing to keep up with 'modern' technologies and paradigms because "that's not how I'm used to doing it". It's a lot of the "I've been round the block a few times I know what I'm doing" bullshit attitude.
But obviously that's a generalisation. Just like your comment is.
In my experience, growing older, I've found both of these generalizations to be true in myself. There are plenty of times that I've watched junior developers make literally the exact same mistakes I made 10 years ago. At the same time, I've learned that technology has continued to move on and things that were wrong 10 years ago may not be wrong today.
I remember when I started out that I'd scour every line of code for memory leaks and optimize the hell out of it. Today we've got more memory, faster machines, and the code doesn't need to be quite as tight.
Mentorship goes both ways. I help newer devs about processes and patterns. They help me with new technology and trends. I think it works well but it requires patience on everyone's parts.
This reminds me of an intern that recently went through our company.
A part of his summer project was to make some api calls to a soap endpoint. We were all very busy so he tried to be as self sufficient as possible and not ask questions. After about a week, he comes to me with questions about soap xml schema and implementation details.
He did not understand it's already built into the tooling. You literally drag-n-drop a url endpoint into your project and get a proxy class for calling the soap endpoint. He was way off into the weeds trying to finish his project. A little guidance helps.
Hopefully you lot took it as your own failure and not the poor intern dropped into the field with one of the most over complicated technologies and 'magical thinking' tooling.
Sure, we shouldn't have been so busy to not support our teammates.
Still, I don't consider it a big failure. A lot of people go through life using technologies without really knowing how they work. He could have very well drag-n-dropped the soap endpoint and never learned a thing about soap. Now that he knows a bit about it he may alter his decisions in the future knowing the guts e.g. 'don't do that because it won't work through soap' etc.
Not saying that is necessarily the case, but situations like this can also develop if you have a lot of basic knowlege (especially regarding tooling) that is neither documented properly nor spread amongst most of the team.
I've had scenarios where I spent an afternoon building a little one-off application I needed for some specific debugging task only to be told a month or so later that someone already built a proper tool for that - but only one developer knew about it, and it was stored in a different repository I had no access to.
Problem is a lots of young people may not seeing old people and old knowledge the same way like old people do.
They may think the old programmer are leak of passion, just there to do their part of job, not creating things and "Change the world" like they do.
For example when you tell them to parse HTTP header with a 256 buffer, they may argue why not give me 4K buffer so they can done it more easily, "It's fine to use 4K for that, just install more memory".
Well, it often isn't that simple, really. "Old" knowledge can also be simply not true anymore.
I've had discussions with "industry veterans" that didn't get the fundamentals about their machines straight (a couple of them, for example, seemed to be ignorant of the fact that caching is a thing and influences your memory access delays).
Usually, that wouldn't be much of a problem, except when they claimed authority on performance and how hot-path algorithms should be implemented. The upside to those discussions is that they're usually easily settled with a couple of benchmarks and unit tests.
Similarly, I'm often puzzled whenever I encounter someone who works on a ("official") C++ project and e.g. refuses to use RAII and/or const properly. I get that you might dislike to depend on too many "external" tools, but just throwing the upsides of the language you're using away because "that's not how we did it back in the day" really bugs me. I can't avoid the impression that those people are being willingly ignorant...
Yup. I've seen 55+ year old programmers write what was essentially a message queue persisted in a database table, processed by a cron job. We frequently had problems with duplicate processing of messages, due to multiple cron jobs running at once.
I've personally argued against a key-value store schema in SQL Server and was in favor of a flat-table design. In our case, there were records of different 'types', and each type may have a number of fields always be null. Looking back, I'd probably do something like this:
Entity
common attribute 1
common attribute 2
etc
Entity_Type1
entity_id fk references Entity,
type1_attribute 1,
etc
He was certain that the flat-table design would take up more space since it would 'have to store every attribute every time'. Most of these were varchars, so (looking back) that was straight up false. Not only that, but in a key-value schema you have to store the name of the 'column' (key)... every time. I was unable to articulate the harms of key-value schemas when it comes to queryability...even though our existing system was filled to the brim with 'unions' due to a key-value schema. I lost this argument.
Each of these developers refused to use git, in favor of visual source safe. I know.
All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing.
I've lost count of the times I've been steamrolled in discussions. I'm not sure if it's my age or if I'm just lacking that much socially. When you lose an argument over key-value schemas of all things it makes you really question if you know what you're doing...
>All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing.
I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument.
It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in. I use the database for what it was made for, and only what it was made for: to persist and retrieve data. Anything else should be in the code.
Also, key/value schemas are terrible and slow, but sometimes they're the only way to get the dynamic nature of what you are doing. The best compromise I've seen of that is to have the values you know are going to be used a lot by groups/customers flat, then have the key/value schema for anything oddball.
I guess the moral of the story is old/young doesn't really matter. It's know / don't know what you are doing. I guess it boils down to thinking about what you are doing. Key value is very dynamic but I'll bet it's slow. Do we need fast more than dynamic? Is there a compromise that will satisfy both requirements? Many people don't think that deeply and just want to get it finished.
When I was young, the dot bomb was the "great filter." After that, there were a lot more people who knew what they were doing because they survived. It sucked though, I don't recommend it.
> I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument.
> It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in.
If i recall correctly, back in the dark ages of Classic ASP and SQL Server 6.5, database stored procedures was the only feasible way of implementing a reasonably performing web application.
No, we had middleware back then. It was ugly text over sockets, or worse, DCOM, but it worked. That was more ISAPI than classic ASP. If nothing else, we could create a queue table in a database and have a Windows Service pick it up.
Back in SQL 6.5 days (and all the MS SQL versions up to, i believe, 2005), "precompiling" queries in stored procedures was recommended for performance reasons. It was even asked on hiring interviews, at least to me.
Oh I wasn't saying it was -- just providing examples for when the hand-waving/dismissive attitude by senior developers isn't really backed by anything. I'm pretty skeptical of 'because I said so' answers nowadays (by both young and old devs).
>then have the key/value schema for anything oddball
Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)
Yes, I'm prepared to defend any design decision I have all day if I have to. I like discussing / arguing things because someone else might have thought of something I didn't consider. It's about making a good product, not about who wins. I use the pro/con model. That's probably lost on most people, especially defensive ones. I get aggravated by "because I said so," too. When you're older, you don't get dismissed as much if at all.
My mentor was a huge arguer, that's probably where I got it from. He'd start talking louder and spittle would come out at me and everything. It was ugly, but I got used to it. We'd go at it for hours, but we both knew when we came up with the right decision and were receptive to it. I like to think I'm quite a bit more tactful than he is though.
>Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)
Oh god, I suffer over schema design decisions more than I should, but sometimes, relational just doesn't fit what I'm doing. What's really helped is I got stuck doing reports for a huge schema my 2nd two years and I really saw what crappy design could do to performance. My favorite is when a schema has missing foreign keys on 80% of the tables. It's like they discovered foreign keys 3/4 of the way through the project and didn't bother to retrofit them.
Eh, I've seen some fresh college grads advocate the same stored procedures and silly k/v stores in relational DBs; someone told them that "model code must be isolated; stored procedures are the best way to do that" and they took that as gospel.
And I have been steamrolled in discussions with 20-somethings as well. "Don't worry, I'll always give you enough time to refactor the tree shaking caused by this design," from a first-time manager is probably my favorite, followed by "this must be re-written, there's no way to salvage it in-place."
They went from consistent if slow progress in defusing the landmines in the old backend to eight months of re-writing everything (frontend included since the data model was also changed) and trying to claw their way back to parity.
Bad programmers will be bad programmers, regardless of age. At least age will put a polish on average developers, letting them work above their raw potential simply because of "I've seen this before; here's how it was solved".
I work in an organization that is relatively balanced as far as age goes (I'm 45). The most senior-level engineers tend to be older than me, though there are a few younger guys (still over 30). Perhaps I'm just fortunate, but here's what I've observed:
We tend to be fairly agile with regard to new technologies, and much of that is driven by the architects. A few of the young folks will recommend bleeding edge platforms/libraries/techniques. Some of this stuff has been accepted, some of it hasn't. It is almost always filtered through the lens of experience ("what happened when we tried to introduce x?
").
Experience counts, primarily because one group has been burned in the past by accepting recommendations from just-out-of-college engineers. That's not to say the younger devs don't know anything, but they have precious little experience shipping actual product.
(We work in the medical domain, so "move fast and break things" doesn't work so well in a highly-regulated industry).
On the other hand, our senior build engineer is more, uh, established in his ways, and we are currently stuck on an antiquated version control system. This particular engineer also wields quite a bit of influence to the larger company, so his way tends to be the way we go (unfortunately).
At the end of the day, I think you find stuck-in-their-old-way folks in an industry. This is not at all unique to software engineering.
In some cases, the Old Ways and the Old Software is better, and it takes wisdom and experience to identify these cases. "Because it's old" is almost never a good reason not to use some software or technique (code does not rot). "Because it's new" is sometimes a good reason to try something, though.
"""All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing."""
I remember when this was the thing to do; to store as much as possible in stored procs. Fat server (the server here being the database server), thin client.
That has changed, and changed again, and no doubt it will be different in the future again. The problem with our profession is that it isn't always easy to determine which changes are actual progress, and which are a fad or fashion.
(Anecdotally: I also remember having to replace ~100 lines of Python with ~60 stored procs and views in Access. This was code that was very unsuitable to be done in a database. The Python code did the job fast, and was readable and understandable; the Access queries were NOT, and it took them minutes to do the same thing. But, management considered Python "unmaintainable" because it was "an obscure language"... so they preferred the Access "solution".)
git is a good litmus test. If they're old and refuse to use it, they're probably a close-minded dinosaur.
If they like git and know it well, they're probably old, full of the experience and benefits you're looking for, _and_ energetic, growing and open-minded.
(I said "probably" because it's not perfect. But it's a pretty good heuristic).
To be fair - I'm not sure how that is age related. e.g. I've had very strong reactions from some inexperienced developers who literally only had knowledge of one way of doing things to the possibility that another option might be possible and better.
Yep, pattern bias happens to a lot of people in a lot of age groups in a lot of professions. One of the consequences of having a massive pattern matching machine for the human CPU.
It's irritating in programmers because we can write prototypes to prove out our theories. It is really irritating in the fuzzy areas (like government and organization grant readers).
I hear this much more often from the less-experienced programmers than I do from the seasoned, experienced ones. Once in a while, and usually in a very large shop, I hear it from an experienced veteran. However, usually (not always, but usually) from one who's had 1 year of experience 20 times rather than 20 years of experience.
> As well refusing to keep up with 'modern' technologies and paradigms
I don't know if in the situations you've observed or participated in the primary argument was about the "modern" nature of the technology choices in question, but as far as I've been able to tell, often when someone employs it as a descriptor, it's a sign that you need to probe carefully to figure out if there's any "there" there. Often enough the person doesn't know how to assign it any other merit than it was recently created. Which can be another way of saying "fashionable."
That might not be the only merit a technology that makes that claim has, but I tend to find it's more likely that there are other merits the less visibility the term modern has in the discussion surrounding it.
> because "that's not how I'm used to doing it".
Here's a question: if you already know a way of doing something that will meet project requirements... why spend time investing in another way of doing the same thing?
One of my guidelines is to prefer learning things that expand my capabilities over learning things that retread existing ones.
That's a more finely articulated proposition than "that's not how I'm used to doing it", but I wouldn't be surprised if they had a large degree of overlap.
(Also, my observation has been "that's not how I'm used to doing it" is an argument employed across age ranges without discrimination.)
I've also had my share of encounters with such people, so I can relate to what you're saying here.
However: I strongly suspect the reason for both generalizations to exist is the fact that we as humans tend to remember the extreme encounters the most - the obvious observation being that the Dunning-Kruger effect applies to all ages.
It definitely happens in lots of other types of jobs, too. It's not just programming.
I'm interested in why it happens to some people, but not others. You'll see people who are set in their ways by their mid to late 20s, and others who seem to keep an open mind perpetually.
