4 ms·

What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. That's not to say that consensus always

by YZF 1y ago

What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. That's not to say that consensus always works. But it does mean the group needs to understand the objections and make decisions the team can live with. The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes. Sometimes there is time pressure or difficult people but the base assumption should be that people actually want to make the right decision, being difficult generally makes your life harder. Who would be responsible for executing on the decision and who would be responsible for the outcome? What are the consequences of strong arming the team into solutions they don't agree with?

atoav 1y ago
Chances based on my experience? 50:50 Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't updated my judgement since, despite the world having changed a lot". The problem is that unless you really know things inside out or know the hard held opinions of your older collegue well, it can be hard to tell the two apart. In that case it only helps to talk about it in more detail and try to get to the root of where the judgement comes from. Then it could come to light that the warning to use PHP comes from a bad experience with PHP version <1.0 or that there is a number of bad experienced that are really useful for deciding the direction of a project. In the end many decisions are about taste. And nothing is as good as a way to keep arguing than matters of taste. Weigh all the pros/cons and make a choice.
- bruce511 1y ago
  I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today. For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently. Like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field. All those habits proved to be bad in the long run. And today memory (and disk space) are abundant. But these old habits are hard to break. And that's before we talk about "modern" techniques, like version control etc. Experience is great. I'm a fan. But all too often experience is also "there was a bug I windows 95, so that API call is unreliable ".
  - cradsoit 1y ago
    You can still obtain a ton of performance by minimizing the size of right things, processor caches are relatively small still. Stuff like the order of columns in a postgres database can still at worst multiply your table size
    - atoav 1y ago
      Yes, but we went from a time where these optimizations were absolutely unavoidable (so unavoidable that programmers would sacrifice any other thing for it) to one where the optimizations may be a nice to have, but for most organizations the maintainability of the code is much more crucial. As mentioned before there are exceptions, like embedded programming, anything that needs to be finished within predictable time (game code, graphics, DSP code, etc). But even if you write a thing for a company website today I wouldn't dare to answer if making the code 10% less readable to make it use memory 10% less memory is a good trade off. Not that redability and memory use are necessarily mutually exclusive goals, but if you highly optimize code for one dimension, others will suffer at some point. And if you come from a generation where memory usage was king, it could be that you make these trade offs out of habit or principle despite them maybe no longer aligning with the goals of the project you're working on. Anybosy who is good at their craft will choose how to deal with trade offs depending on the needs of the project and not based on remembered tradition.
      - becarlos 1y ago
        With 20 years of experience in website development, I have led various site speed optimization teams. From my background, I pay particular attention to assets, JS profiling, and related aspects whenever I work on a web app. These practices are so ingrained that I perform them automatically and transparently, as they have been part of my process ever since. The same thing might happen to these engineers when working on existing or new projects and writing C/C++ code; these optimizations will be part of their process.
  - antonvs 1y ago
    > today memory (and disk space) are abundant. It still has a cost though, which needs to be taken into account in many situations. At our company the cost of compute, RAM, and storage are some of the biggest ongoing concerns, which can make the difference between profitability and bankruptcy, and we’ve done a lot of work on it.
- liquid_thyme 1y ago
  >Weigh all the pros/cons and make a choice. This is sound advice when people agree on which column things belong to :)
  - atoav 1y ago
    That would mean you're not on one page with the others about what the project is meant to achieve and what not. E.g. let's say one library is more privacy friendly and the other allows more data collection, depending on the project both could be pro or con. I respect developers who value privacy, but if you don't know whether a program is meant to collect data by the point you discuss library choices that eindicates either bad project planning, bad communication or both.
BrandoElFollito 1y ago
> What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. I would say that they are pretty average. First I am not sure what you mean by "know-it-all", specifically if this is a positive trait or not. Let's say that it is positive. In that case age does not matter much because you can have extremely good practices that are simply outdated. Yes they work. Yes, they are stable. But they may not be adapted to the current needs. So age is not a good differentiator for me. Now, if you drop "older" I agree with you (with the assumption of a positive meaning for know-it-all)
- fsckboy 1y ago
  >First I am not sure what you mean by "know-it-all"...if you drop "older" good lord, in those phrases he was quoting the wording in the comment he was replying to. I don't know if you are young or old, but I'd like to teach you about threading (and we won't stop till you get it or your eyebrows are gone)
  - BrandoElFollito 1y ago
    I have no idea what you are talking about. Could you please rephrase this in simple words adapted to my age?
    - joncrane 1y ago
      The post that this thread is replying to uses the phrase "know it all" and it's pretty obvious what OP meant. The person kvetching at you about not understanding threading is making a joke because there's also a process called "eyebrow threading." HN is supposed to be high quality discourse and you have to be on your toes if you want to participate! Missing context, and missing references, and doubling down when you're called out is NOT the optimal strategy.
      - BrandoElFollito 1y ago
        > HN is supposed to be high quality discourse and you have to be on your toes if you want to participate! I am so sorry not to be at the correct level and, as a non English speaker, not to know all the references. I feel so ashamed, fortunately you enlightened me about the high quality discourse I was missing. Thank you very much for your kindness.
skeeter2020 1y ago
>> The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes. Disagree. This can be very bad, but the worst situation I had was a very experienced developer with poor social skills making decisions for the team without a complete understanding of the entire picture

by YZF 1y ago

atoav 1y ago

Chances based on my experience? 50:50 Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't updated my judgement since, despite the world having changed a lot". The problem is that unless you really know things inside out or know the hard held opinions of your older collegue well, it can be hard to tell the two apart. In that case it only helps to talk about it in more detail and try to get to the root of where the judgement comes from. Then it could come to light that the warning to use PHP comes from a bad experience with PHP version <1.0 or that there is a number of bad experienced that are really useful for deciding the direction of a project. In the end many decisions are about taste. And nothing is as good as a way to keep arguing than matters of taste. Weigh all the pros/cons and make a choice.

bruce511 1y ago
I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today. For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently. Like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field. All those habits proved to be bad in the long run. And today memory (and disk space) are abundant. But these old habits are hard to break. And that's before we talk about "modern" techniques, like version control etc. Experience is great. I'm a fan. But all too often experience is also "there was a bug I windows 95, so that API call is unreliable ".
- cradsoit 1y ago
  You can still obtain a ton of performance by minimizing the size of right things, processor caches are relatively small still. Stuff like the order of columns in a postgres database can still at worst multiply your table size
  - atoav 1y ago
    Yes, but we went from a time where these optimizations were absolutely unavoidable (so unavoidable that programmers would sacrifice any other thing for it) to one where the optimizations may be a nice to have, but for most organizations the maintainability of the code is much more crucial. As mentioned before there are exceptions, like embedded programming, anything that needs to be finished within predictable time (game code, graphics, DSP code, etc). But even if you write a thing for a company website today I wouldn't dare to answer if making the code 10% less readable to make it use memory 10% less memory is a good trade off. Not that redability and memory use are necessarily mutually exclusive goals, but if you highly optimize code for one dimension, others will suffer at some point. And if you come from a generation where memory usage was king, it could be that you make these trade offs out of habit or principle despite them maybe no longer aligning with the goals of the project you're working on. Anybosy who is good at their craft will choose how to deal with trade offs depending on the needs of the project and not based on remembered tradition.
    - becarlos 1y ago
      With 20 years of experience in website development, I have led various site speed optimization teams. From my background, I pay particular attention to assets, JS profiling, and related aspects whenever I work on a web app. These practices are so ingrained that I perform them automatically and transparently, as they have been part of my process ever since. The same thing might happen to these engineers when working on existing or new projects and writing C/C++ code; these optimizations will be part of their process.
- antonvs 1y ago
  > today memory (and disk space) are abundant. It still has a cost though, which needs to be taken into account in many situations. At our company the cost of compute, RAM, and storage are some of the biggest ongoing concerns, which can make the difference between profitability and bankruptcy, and we’ve done a lot of work on it.
liquid_thyme 1y ago
>Weigh all the pros/cons and make a choice. This is sound advice when people agree on which column things belong to :)
- atoav 1y ago
  That would mean you're not on one page with the others about what the project is meant to achieve and what not. E.g. let's say one library is more privacy friendly and the other allows more data collection, depending on the project both could be pro or con. I respect developers who value privacy, but if you don't know whether a program is meant to collect data by the point you discuss library choices that eindicates either bad project planning, bad communication or both.

BrandoElFollito 1y ago

> What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. I would say that they are pretty average. First I am not sure what you mean by "know-it-all", specifically if this is a positive trait or not. Let's say that it is positive. In that case age does not matter much because you can have extremely good practices that are simply outdated. Yes they work. Yes, they are stable. But they may not be adapted to the current needs. So age is not a good differentiator for me. Now, if you drop "older" I agree with you (with the assumption of a positive meaning for know-it-all)

fsckboy 1y ago
>First I am not sure what you mean by "know-it-all"...if you drop "older" good lord, in those phrases he was quoting the wording in the comment he was replying to. I don't know if you are young or old, but I'd like to teach you about threading (and we won't stop till you get it or your eyebrows are gone)
- BrandoElFollito 1y ago
  I have no idea what you are talking about. Could you please rephrase this in simple words adapted to my age?
  - joncrane 1y ago
    The post that this thread is replying to uses the phrase "know it all" and it's pretty obvious what OP meant. The person kvetching at you about not understanding threading is making a joke because there's also a process called "eyebrow threading." HN is supposed to be high quality discourse and you have to be on your toes if you want to participate! Missing context, and missing references, and doubling down when you're called out is NOT the optimal strategy.
    - BrandoElFollito 1y ago
      > HN is supposed to be high quality discourse and you have to be on your toes if you want to participate! I am so sorry not to be at the correct level and, as a non English speaker, not to know all the references. I feel so ashamed, fortunately you enlightened me about the high quality discourse I was missing. Thank you very much for your kindness.

skeeter2020 1y ago

>> The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes. Disagree. This can be very bad, but the worst situation I had was a very experienced developer with poor social skills making decisions for the team without a complete understanding of the entire picture