But obviously that's a generalisation. Just like your comment is.
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.
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".
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...
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.
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.
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.
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
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...
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.
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'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.
> 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.
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' ;)
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.
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".)
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.
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 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.)
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.
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.