3 ms·

In general anything written by nonprofessional programmers in pursuit of some other goal is terrible code by professional programmer standards. On the other ha

In general anything written by nonprofessional programmers in pursuit of some other goal is terrible code by professional programmer standards. On the other hand, it accomplishes a goal other than getting a programmer paid. So in one important sense is objectively better than probably 80% of the code I've seen people paid to write, no matter how nicely it was constructed.

cqqxo4zV46cp 2y ago
Amen to that. The confluence of an insulator nature of organisational developer cliques, the culture of self-importance in the field, and the ability for many teams to expend material effort on things that are…at best, tangentially related to business goals (due to cheap money, and frankly, often pulling the wool over management’a eyes), has bred at least a couple of generations of developer where large contingents have a completely out of whack perspective on what’s actually important.
- williamcotton 2y ago
  Preach!
hot_gril 2y ago
In one project, I had a new teammate ask me why almost our entire web backend is a single .js file mostly filled with SQL queries. He wanted to make it his personal project to refactor this into probably 20 different files, adding more layers between the handlers and the DB stuff, using a query builder, and also migrating to TS. When I asked him what's wrong with the current thing, he couldn't answer and gave up on this idea. That backend had decent integration tests, and it took less than 5 minutes to add a small new feature. Most prod code doing comparable things where I work is worse-tested, less reliable, and at least 10X more expensive in terms of SWE-time, so I think modern programming standards are actually nonsense even though I can play along with them.
- giraffe_lady 2y ago
  Yeah I think I got this from Sandi Metz a long time ago but it's been so valuable to me: "bad code that you never have to modify is good code." Now when business requirements change and you're constantly sending people into that 1600 line backend function or whatever, it's likely worth it to start doing some refactors. But otherwise if I don't have a good reason to be in there I pretend I don't see it.
  - hot_gril 2y ago
    I agree with the quote, but this was code that we did modify frequently. It was still ok. 1600 line func is bad, but 1600 line file, well that's what editor splits are for. A lot of app backends don't do much other than shoving stuff into a DB and getting it back.
    - lelanthran 2y ago
      > I agree with the quote, but this was code that we did modify frequently. Could still be the best approach, if by "modify" you meant "added new queries to an array of strings".
      - hot_gril 2y ago
        We'd edit queries or add new HTTP endpoints. Some did a little more than query, maybe hit a cache or external service. There were a few shared helpers, not more than one layer deep though.
__mharrison__ 2y ago
This is the crux of a lot of the anti-notebook rhetoric. I spend a good deal of time covertly teaching software engineering best practices to folks who claim they don't want to be "software engineers", yet they are in front of Jupyter most days.
- analog31 2y ago
  Thank you for your service. ;-) I'm a so called "scientific" programmer, and I use notebooks. I care about good programming practices, and have made an effort to improve my craftsmanship. And I don't want to be a software engineer. I'm surrounded by SWE's in my work area, and their job doesn't really interest me. Division of labor. I'm glad somebody enjoys it.
- packetlost 2y ago
  I don't, but this is the conclusion my team came to very early on as well. It has honestly worked wonders.

cqqxo4zV46cp 2y ago

Amen to that. The confluence of an insulator nature of organisational developer cliques, the culture of self-importance in the field, and the ability for many teams to expend material effort on things that are…at best, tangentially related to business goals (due to cheap money, and frankly, often pulling the wool over management’a eyes), has bred at least a couple of generations of developer where large contingents have a completely out of whack perspective on what’s actually important.

williamcotton 2y ago
Preach!

hot_gril 2y ago

In one project, I had a new teammate ask me why almost our entire web backend is a single .js file mostly filled with SQL queries. He wanted to make it his personal project to refactor this into probably 20 different files, adding more layers between the handlers and the DB stuff, using a query builder, and also migrating to TS. When I asked him what's wrong with the current thing, he couldn't answer and gave up on this idea. That backend had decent integration tests, and it took less than 5 minutes to add a small new feature. Most prod code doing comparable things where I work is worse-tested, less reliable, and at least 10X more expensive in terms of SWE-time, so I think modern programming standards are actually nonsense even though I can play along with them.

giraffe_lady 2y ago
Yeah I think I got this from Sandi Metz a long time ago but it's been so valuable to me: "bad code that you never have to modify is good code." Now when business requirements change and you're constantly sending people into that 1600 line backend function or whatever, it's likely worth it to start doing some refactors. But otherwise if I don't have a good reason to be in there I pretend I don't see it.
- hot_gril 2y ago
  I agree with the quote, but this was code that we did modify frequently. It was still ok. 1600 line func is bad, but 1600 line file, well that's what editor splits are for. A lot of app backends don't do much other than shoving stuff into a DB and getting it back.
  - lelanthran 2y ago
    > I agree with the quote, but this was code that we did modify frequently. Could still be the best approach, if by "modify" you meant "added new queries to an array of strings".
    - hot_gril 2y ago
      We'd edit queries or add new HTTP endpoints. Some did a little more than query, maybe hit a cache or external service. There were a few shared helpers, not more than one layer deep though.

__mharrison__ 2y ago

This is the crux of a lot of the anti-notebook rhetoric. I spend a good deal of time covertly teaching software engineering best practices to folks who claim they don't want to be "software engineers", yet they are in front of Jupyter most days.

analog31 2y ago
Thank you for your service. ;-) I'm a so called "scientific" programmer, and I use notebooks. I care about good programming practices, and have made an effort to improve my craftsmanship. And I don't want to be a software engineer. I'm surrounded by SWE's in my work area, and their job doesn't really interest me. Division of labor. I'm glad somebody enjoys it.
packetlost 2y ago
I don't, but this is the conclusion my team came to very early on as well. It has honestly worked wonders.