6 ms·

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 person

by ruffel 9y ago

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.

arethuza 9y ago
"that's not how I'm used to doing it" 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.
- protomyth 9y ago
  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).
- tonecluster 9y ago
  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.
rpeden 9y ago
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.
kageneko 9y ago
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.
- nickrio 9y ago
  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".
  - btschaegg 9y ago
    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...
Mouse47 9y ago
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...
- bmj 9y ago
  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.
btschaegg 9y ago
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.
wwweston 9y ago
> 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.)

by ruffel 9y ago

arethuza 9y ago

"that's not how I'm used to doing it" 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.

protomyth 9y ago
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).
tonecluster 9y ago
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.

rpeden 9y ago

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.

kageneko 9y ago

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.

nickrio 9y ago
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".
- btschaegg 9y ago
  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...

Mouse47 9y ago

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...

bmj 9y ago
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.

btschaegg 9y ago

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.

wwweston 9y ago

> 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.)