13 ms·

Not directly related, but an anecdote: well before AI, I was talking to a Portfolio Solutions Manager or something from JP Morgan. He was an MD at the firm and

Not directly related, but an anecdote: well before AI, I was talking to a Portfolio Solutions Manager or something from JP Morgan. He was an MD at the firm and very full of himself. He told me, "You guys, your job is....you just Google search your problem and copy paste a solution, right?". What I found hilarious is that he also told me, "The quants, I hate that they keep their C++ code secret. I opened up the executable in Notepad to read it and it was just gibberish". Lesson: people with grave incompetence at programming feel completely competent to judge what programming is and should be.

game_the0ry 1y ago
> Lesson: people with grave incompetence at programming feel completely competent to judge what programming is and should be. As an employee at a company with a similar attitude, I cannot agree more with this.
JKCalhoun 1y ago
My own tangential gripe (a bit related to yours though): the factory work began when Agile crept into the workplace. Additionally, lint, unit tests, code reviews... all this crap just piled on making programming worse still. It stopped being fun to code around that point. Too many i's to dot to make management happy.
- thinkingtoilet 1y ago
  What's wrong with writing tests? I sleep well at night when we push to production because of our robust test suite.
  - whatwhaaaaat 1y ago
    Becuase builds are gated by test coverage people write tests for coverage and not for functionality. I’d say a good portion of the inherited tests I’ve ran in to wouldn’t catch anything meaningfully breaking in the function being tested.
    - foobarchu 1y ago
      Your issue is with targeting a metric then (coverage), not the unit tests. Good unit tests can be so useful. I've got a project currently that can't be run locally because of some dependencies, and coding against unit tests means I get to iterate at a reasonable speed without needing to run all code remotely.
    - __s 1y ago
      I spent 3 years getting a Ruby codebase to 100% branch coverage running locally in a few minutes (I wasn't just looking at coverage, I was also profiling for slow tests). Found a few bugs ofc having to read through code so carefully. The value was having a layer of defence while refactoring, if some unrelated test failed it implied you missed impact of your change. It also helped people avoid the issue of making changes to an area of code with no testing, where existing tests act as docs (which execute, so won't go stale as easily) & make it easier for new code to write new tests building on existing tests This codebase was quick to deploy at Microsoft. We'd rollout every week. Compared to other projects that took months to rollout with a tangling release pipeline Anyways I left for a startup & most of this fast moving team dissolved, so the Ruby codebase has been cast aside in favor of projects with tangling release pipelines https://techcommunity.microsoft.com/blog/adforpostgresql/how-we-shipped-postgresql-14-on-azure-within-one-day-of-its-release/2801300 https://techcommunity.microsoft.com/blog/adforpostgresql/how...
  - rvnx 1y ago
    Testing in production happens. This is for example the best practice at SpaceX or at Tesla (FSD, Robotaxi, Unboxed designs, etc), and I think these people sleep very well. Yes, of course, some rockets may explode (almost 10 soon), or some people may have accident, but that's ok from their perspective.
  - alasarmas 1y ago
    Tests that you write in order to contribute to a robust test suite are good. Tests that are written to comply with a policy that requires that all components must have a unit test, and that test must be green, could be good. Often, they are just more bullshit from the bullshit factory that is piling up and drowning the product, the workers, the management, and anyone else who comes too close. I feel that it’s still correct to call both of these things tests, because in isolation, they do the same thing. It’s the structure they’re embedded in that is different.
  - gofreddygo 1y ago
    Writing good tests is an art. Its hard. It takes a deep understanding of _how_ the system is implemented, what should be tested and what should be left alone. Coverage results don't mean much. Takes some experience to know how easy it is to introduce a major bug with 100% test coverage. Tests are supposed to tell you if a piece of code works as it should. But I have found no good way of judging how well a test suite actually works. You somehow need tests for tests and to version the test suite. A overemphasis on testing also makes the code very brittle and a pain to work with. Simple refactorings and text changes need dozens of tests to be fixed. library changes break things in weird ways. Unless I know the system being tested, I take no interest in tests. There's clever hacky ways to test systems that will never pass the "100% coverage" requirement and are a joy to work with. But they're the exception.
    - ponector 1y ago
      There are techniques to keep test quality high. However, usually no one really cares about testing at all. Also many projects are internal, not critical, etc. Make fast, break things, deliver crappy software.
    - dcherman 1y ago
      The point about coverage results is an important one to understand. Something that I like to say when discussing this with other folks is that while high code coverage does not tell you that you have a good test suite, low code coverage does tell you that you have a poor one. It's one metric amongst many that should be used to measure your code quality, it's not the end-all-be-all.
      - gofreddygo 1y ago
        code coverage is a bad metric either way. soon as it gets mentioned anywhere, an mba manager wants it as close to 100 as possible and goodhart's law kicks in. it's synonymous with LOC. don't bring it up anywhere.
  - skeeter2020 1y ago
    From my perspective it's not "tests" but this reaction. There's nothing wrong with tests, but there certainly is a cost to them, are you getting a positive ROI? Has the system been perverted to focus on tests vs. tests supporting quality? Are tests used to justify all sorts of unrelated actions or inaction? Now repeat this exercise with 100 or 1000 other perfectly valid concepts that can help destroy the the very thing that you are trying to accomplish.
    - jajko 1y ago
      Ha, this sounds like my work. I've developed and evolved a java set of apps that integrate our core banking system with few tens of other internal apps. In a decade and a half, we had very few issues, all easy to handle, and ie app has its own clustering via Hazelcast so its pretty robust with minimal resources. Simply nothing business could point a finger to and complain about. Since it was mostly just me, a pretty low cost solution that could be bent to literally any requirement pretty quickly. Come 2025, now its part of agile team and efforts, all runs on openshift which adds nothing good but a lot of limitations, we waste maybe 0.5-1md each week just on various agile meetings which add 0 velocity or efficiency, in fact we are much slower (not only due to agile, technology landacape became more and more hostile to literally any change, friction for anything is maasive compared to a decade ago and there is nothing I can do with that). I understand being risk averse against new unknown stuff, but something that proved its worth over 15 years? Well it aint my money being spend needlessly, I dont care and find life fulfillment completely outside of work (the only healthy approach for devs in places like banking megacorps). But smart or effective it ain't.
  - guywithahat 1y ago
    A lot of people never learned how, and now they just avoid doing it whenever possible. It's really frustrating; I'm all for some bit of code not needing a test, but it should be because the code doesn't need to be unit tested. Breaking unit testing, not knowing how to fix it, and removing all testing is not a good reason.
- rwmj 1y ago
  Agile yes, it's micromanagement at scale. But writing tests and doing code reviews is good practice.
  - dbolgheroni 1y ago
    Code review is another sacred process that seems too good not to have, but many teams use it as a "we care about quality" stamp when in fact they do not. Used for just nitpicking code style (important but not the whole reason to have CR, and there are tools for this), issue comments like "LGTM" and approve whatever arrives at the pull request anyway.
    - bArray 1y ago
      I've not yet seen code review implemented in a good way in places I have worked. It's not really considered "real work" (may result in zero lines of code change) and it takes time to properly read through code and figuring out where the weaknesses might be. I just end up being forced to skim read for anything obvious and merging, because there is not enough time to review the code properly.
      - carefulfungi 1y ago
        As a manager, code review has two benefits that typically matter to me: (a) cost: it's cheaper to fix a defect that hasn't shipped (reading tests for missing cases is a useful review, in my experience); (b) bus-factor: make sure someone else has a passing familiarity with the code. And some ancillary (and somewhat performative benefits) like compliance: your iso-27001, soc-2 change control processes likely require a review. It's hard, though, to keep code reviews from turning into style and architecture reviews. Code reviewing for style is subjective. (And if someone on the team regularly produces very poor quality code, code review isn't the vehicle for fixing that.) Code reviewing for architecture is expensive; settle on a design before producing production-ready code. My $0.02 from the other side of the manager/programmer fence.
        bArray 1y ago
- myvoiceismypass 1y ago
  I never found linting or writing unit tests to be particularly un-fun, but I generally really really value correctness in my code, and both of those things tend to help on that front.
  - JKCalhoun 1y ago
    I think unit tests are perfect for you then. Unfortunately, management often dictates this for all engineers.
- FooBarBizBazz 1y ago
  If you give up on unit tests and code review then the code is "yours" instead of "ours" and your coworkers will not want to collaborate on it with you. However, this has to be substantive code review by technical peers who actually care. Unit tests also need the be valued as integral to the implementation task. The author writes the unit tests. It helps to guide the thought process. You should not offload unit tests to an intern as "scutwork". If your code is sloppy, a stylistic mess, and unreviewed, then I am going to put it behind an interface as best I can, refer to it as "legacy", rely on you for bugfixes (I'm not touching that stinking pile), and will probably try to rally people behind a replacement.
  - JKCalhoun 1y ago
    In my experience that did not happen. I've been lucky perhaps to always work with engineers I trusted. And frankly, giving ownership to code ("it's yours") has, also in my experience, been an excellent way to give an engineer "pride of ownership". No one wants to have that "stinking pile".
- HDThoreaun 1y ago
  It turns out that doing a good job at work is more important than having fun.
  - JKCalhoun 1y ago
    You might get some pushback there. But obviously I would choose both. (And believe we had both before management started dictating how we coded.)
    - HDThoreaun 1y ago
      In my experience shops that dont have testing guidelines end up with untested code, and in my experience untested code always has bugs.
varjag 1y ago
It doesn't help that most "tech visionaries" or people considered tech bros these days more often come from accounting or legal background than anything technical. They are widely perceived as authorities but come without the expertise. This is why it's so perplexing for the techies when the industry gets caught up in some ridiculous hype cycle apparently neglecting the physical realities.
bumby 1y ago
I used to work in aerospace R&D. The number of times I heard some variant of “it’s just software” to disregard a safety critical concern was mind boggling. My favorite is a high-level person equating it to writing directions on a napkin.
dwaltrip 1y ago
Hubris and fragile egos run amok A burning need to dominate in a misguided attempt to fill the gaping void inside Broken and hurting people spreading their pain as they flail blindly for relief Our world creaks, cracks splintering out like spider thread The foundations tremble
- vijucat 1y ago
  Poetic

game_the0ry 1y ago

> Lesson: people with grave incompetence at programming feel completely competent to judge what programming is and should be. As an employee at a company with a similar attitude, I cannot agree more with this.

JKCalhoun 1y ago

My own tangential gripe (a bit related to yours though): the factory work began when Agile crept into the workplace. Additionally, lint, unit tests, code reviews... all this crap just piled on making programming worse still. It stopped being fun to code around that point. Too many i's to dot to make management happy.

thinkingtoilet 1y ago
What's wrong with writing tests? I sleep well at night when we push to production because of our robust test suite.
- whatwhaaaaat 1y ago
  Becuase builds are gated by test coverage people write tests for coverage and not for functionality. I’d say a good portion of the inherited tests I’ve ran in to wouldn’t catch anything meaningfully breaking in the function being tested.
  - foobarchu 1y ago
    Your issue is with targeting a metric then (coverage), not the unit tests. Good unit tests can be so useful. I've got a project currently that can't be run locally because of some dependencies, and coding against unit tests means I get to iterate at a reasonable speed without needing to run all code remotely.
  - __s 1y ago
    I spent 3 years getting a Ruby codebase to 100% branch coverage running locally in a few minutes (I wasn't just looking at coverage, I was also profiling for slow tests). Found a few bugs ofc having to read through code so carefully. The value was having a layer of defence while refactoring, if some unrelated test failed it implied you missed impact of your change. It also helped people avoid the issue of making changes to an area of code with no testing, where existing tests act as docs (which execute, so won't go stale as easily) & make it easier for new code to write new tests building on existing tests This codebase was quick to deploy at Microsoft. We'd rollout every week. Compared to other projects that took months to rollout with a tangling release pipeline Anyways I left for a startup & most of this fast moving team dissolved, so the Ruby codebase has been cast aside in favor of projects with tangling release pipelines https://techcommunity.microsoft.com/blog/adforpostgresql/how-we-shipped-postgresql-14-on-azure-within-one-day-of-its-release/2801300 https://techcommunity.microsoft.com/blog/adforpostgresql/how...
- rvnx 1y ago
  Testing in production happens. This is for example the best practice at SpaceX or at Tesla (FSD, Robotaxi, Unboxed designs, etc), and I think these people sleep very well. Yes, of course, some rockets may explode (almost 10 soon), or some people may have accident, but that's ok from their perspective.
- alasarmas 1y ago
  Tests that you write in order to contribute to a robust test suite are good. Tests that are written to comply with a policy that requires that all components must have a unit test, and that test must be green, could be good. Often, they are just more bullshit from the bullshit factory that is piling up and drowning the product, the workers, the management, and anyone else who comes too close. I feel that it’s still correct to call both of these things tests, because in isolation, they do the same thing. It’s the structure they’re embedded in that is different.
- gofreddygo 1y ago
  Writing good tests is an art. Its hard. It takes a deep understanding of _how_ the system is implemented, what should be tested and what should be left alone. Coverage results don't mean much. Takes some experience to know how easy it is to introduce a major bug with 100% test coverage. Tests are supposed to tell you if a piece of code works as it should. But I have found no good way of judging how well a test suite actually works. You somehow need tests for tests and to version the test suite. A overemphasis on testing also makes the code very brittle and a pain to work with. Simple refactorings and text changes need dozens of tests to be fixed. library changes break things in weird ways. Unless I know the system being tested, I take no interest in tests. There's clever hacky ways to test systems that will never pass the "100% coverage" requirement and are a joy to work with. But they're the exception.
  - ponector 1y ago
    There are techniques to keep test quality high. However, usually no one really cares about testing at all. Also many projects are internal, not critical, etc. Make fast, break things, deliver crappy software.
  - dcherman 1y ago
    The point about coverage results is an important one to understand. Something that I like to say when discussing this with other folks is that while high code coverage does not tell you that you have a good test suite, low code coverage does tell you that you have a poor one. It's one metric amongst many that should be used to measure your code quality, it's not the end-all-be-all.
    - gofreddygo 1y ago
      code coverage is a bad metric either way. soon as it gets mentioned anywhere, an mba manager wants it as close to 100 as possible and goodhart's law kicks in. it's synonymous with LOC. don't bring it up anywhere.
- skeeter2020 1y ago
  From my perspective it's not "tests" but this reaction. There's nothing wrong with tests, but there certainly is a cost to them, are you getting a positive ROI? Has the system been perverted to focus on tests vs. tests supporting quality? Are tests used to justify all sorts of unrelated actions or inaction? Now repeat this exercise with 100 or 1000 other perfectly valid concepts that can help destroy the the very thing that you are trying to accomplish.
  - jajko 1y ago
    Ha, this sounds like my work. I've developed and evolved a java set of apps that integrate our core banking system with few tens of other internal apps. In a decade and a half, we had very few issues, all easy to handle, and ie app has its own clustering via Hazelcast so its pretty robust with minimal resources. Simply nothing business could point a finger to and complain about. Since it was mostly just me, a pretty low cost solution that could be bent to literally any requirement pretty quickly. Come 2025, now its part of agile team and efforts, all runs on openshift which adds nothing good but a lot of limitations, we waste maybe 0.5-1md each week just on various agile meetings which add 0 velocity or efficiency, in fact we are much slower (not only due to agile, technology landacape became more and more hostile to literally any change, friction for anything is maasive compared to a decade ago and there is nothing I can do with that). I understand being risk averse against new unknown stuff, but something that proved its worth over 15 years? Well it aint my money being spend needlessly, I dont care and find life fulfillment completely outside of work (the only healthy approach for devs in places like banking megacorps). But smart or effective it ain't.
- guywithahat 1y ago
  A lot of people never learned how, and now they just avoid doing it whenever possible. It's really frustrating; I'm all for some bit of code not needing a test, but it should be because the code doesn't need to be unit tested. Breaking unit testing, not knowing how to fix it, and removing all testing is not a good reason.
rwmj 1y ago
Agile yes, it's micromanagement at scale. But writing tests and doing code reviews is good practice.
- dbolgheroni 1y ago
  Code review is another sacred process that seems too good not to have, but many teams use it as a "we care about quality" stamp when in fact they do not. Used for just nitpicking code style (important but not the whole reason to have CR, and there are tools for this), issue comments like "LGTM" and approve whatever arrives at the pull request anyway.
  - bArray 1y ago
    I've not yet seen code review implemented in a good way in places I have worked. It's not really considered "real work" (may result in zero lines of code change) and it takes time to properly read through code and figuring out where the weaknesses might be. I just end up being forced to skim read for anything obvious and merging, because there is not enough time to review the code properly.
    - carefulfungi 1y ago
      As a manager, code review has two benefits that typically matter to me: (a) cost: it's cheaper to fix a defect that hasn't shipped (reading tests for missing cases is a useful review, in my experience); (b) bus-factor: make sure someone else has a passing familiarity with the code. And some ancillary (and somewhat performative benefits) like compliance: your iso-27001, soc-2 change control processes likely require a review. It's hard, though, to keep code reviews from turning into style and architecture reviews. Code reviewing for style is subjective. (And if someone on the team regularly produces very poor quality code, code review isn't the vehicle for fixing that.) Code reviewing for architecture is expensive; settle on a design before producing production-ready code. My $0.02 from the other side of the manager/programmer fence.
      - bArray 1y ago
myvoiceismypass 1y ago
I never found linting or writing unit tests to be particularly un-fun, but I generally really really value correctness in my code, and both of those things tend to help on that front.
- JKCalhoun 1y ago
  I think unit tests are perfect for you then. Unfortunately, management often dictates this for all engineers.
FooBarBizBazz 1y ago
If you give up on unit tests and code review then the code is "yours" instead of "ours" and your coworkers will not want to collaborate on it with you. However, this has to be substantive code review by technical peers who actually care. Unit tests also need the be valued as integral to the implementation task. The author writes the unit tests. It helps to guide the thought process. You should not offload unit tests to an intern as "scutwork". If your code is sloppy, a stylistic mess, and unreviewed, then I am going to put it behind an interface as best I can, refer to it as "legacy", rely on you for bugfixes (I'm not touching that stinking pile), and will probably try to rally people behind a replacement.
- JKCalhoun 1y ago
  In my experience that did not happen. I've been lucky perhaps to always work with engineers I trusted. And frankly, giving ownership to code ("it's yours") has, also in my experience, been an excellent way to give an engineer "pride of ownership". No one wants to have that "stinking pile".
HDThoreaun 1y ago
It turns out that doing a good job at work is more important than having fun.
- JKCalhoun 1y ago
  You might get some pushback there. But obviously I would choose both. (And believe we had both before management started dictating how we coded.)
  - HDThoreaun 1y ago
    In my experience shops that dont have testing guidelines end up with untested code, and in my experience untested code always has bugs.

varjag 1y ago

It doesn't help that most "tech visionaries" or people considered tech bros these days more often come from accounting or legal background than anything technical. They are widely perceived as authorities but come without the expertise. This is why it's so perplexing for the techies when the industry gets caught up in some ridiculous hype cycle apparently neglecting the physical realities.

bumby 1y ago

I used to work in aerospace R&D. The number of times I heard some variant of “it’s just software” to disregard a safety critical concern was mind boggling. My favorite is a high-level person equating it to writing directions on a napkin.

dwaltrip 1y ago

Hubris and fragile egos run amok A burning need to dominate in a misguided attempt to fill the gaping void inside Broken and hurting people spreading their pain as they flail blindly for relief Our world creaks, cracks splintering out like spider thread The foundations tremble

vijucat 1y ago
Poetic