Senior Developer Skills in the AI Age

Post by necovek » Sat, Apr 05, 2025, 5:09 AM UTC

nsonha wrote: post #301

necovek wrote: post #276

Earlier quoted context omitted.

The argument of "coding speed not a bottleneck to productivity" is not in contradiction to "productivity is a combination": it even implies it. Again, the context here was that somebody discussed speed of coding and you raised the point of not using any tooling with Notepad.

The context here is AI assisted engineering and you raised the point that non-engineering productivity is more important for engineers, which I think is absurd. You can have 10x engineering productivity boost and still complete work in the same amount of time, because of communication and human factors. Maybe it's a problem, may be it's not. It's still a productivity gain that will make you work better nonetheless.

Post by atemerev » Sat, Apr 05, 2025, 10:25 AM UTC

skydhash wrote: post #295

atemerev wrote: post #289

Earlier quoted context omitted.

"Given this code, extract all entities and create the database schema from these", "write documentation for these methods", "write test examples", "write README.md explaining how to use scripts in this directory", "refactor everything in this directory just like this example", etc etc Everything boring can be automated and it takes five seconds compared to half an hour.

It can only be automated if the only thing you care about is having the code/text, and not making sure they are correct. > Given this code, extract all entities and create the database schema from these Sometimes, the best representation for storing and loading data is not the best for manipulating it and vice-versa. Directly mapping code entities to database relations (assuming it's SQL) is a sure way to land yourse…

Post by necovek » Sat, Apr 05, 2025, 11:42 AM UTC

hjnilsson wrote: post #196

jjice wrote: post #182

Earlier quoted context omitted.

You’re objectively correct in a business context, which is what most software is for. For me, seeing AI slop code more and more is just sad from a craft perspective. Software that’s well designed and architected is a pleasure to read and write, even if a lower quality version would get the job done. I’m watching one of the things I love most in the world become more automated and having the craftsmanship stripped out…

It’s probably the same way monks copying books felt when the printing press came along. “Look at this mechanical, low-quality copy. It lacks all finesse and flourish of the pen!” I agree with you that it is sad. And what is especially sad is that the result will probably be lower quality overall, but much cheaper. It’s the inevitable result of automation.

Post by necovek » Sat, Apr 05, 2025, 11:51 AM UTC

cinntaile wrote: post #278

saila wrote: post #103

Earlier quoted context omitted.

The call to logging.basicConfig happens at import time, which could cause issues in certain scenarios. For a one-off script, it's probably fine, but for a production app, you'd probably want to set up logging during app startup from whatever your main entry point is. The Python standard library has a configparser module, which should be used instead of custom code. It's safer and easier than manual parsing. The stand…

Regarding your first paragraph, we still don't understand what the issue actually is.

  import logging
  logging.basicConfig(...)

  logging.info("foo") # uses above config
  
  if __name__ == "__main__":
      import utils # your config is overridden with the one in utils
      logging.info("bar") # uses utils configuration
      ...

Post by necovek » Sat, Apr 05, 2025, 5:10 PM UTC

theteapot wrote: post #206

necovek wrote: post #9

The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: https://github.com/dx-tooling/platform-problem-monitoring-co... All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves,…

> to a raciness in load_json where it's checked for file existence with an if and then carrying on as if the file is certainly there... It's not a race. It's just redundant. If the file does not exist at the time you actually try to access it you get the same error with slightly better error message.

  try:
      with open(...) ...

  except FileNotFound:
      logger.error(...)
      raise