←back to thread

421 points briankelly | 3 comments | | HN request time: 0.001s | source
Show context
necovek ◴[] No.43575664[source]
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...

In a nutshell, if the rest of it is like this, it simply sucks.

replies(23): >>43575714 #>>43575764 #>>43575953 #>>43576545 #>>43576732 #>>43576977 #>>43577008 #>>43577017 #>>43577193 #>>43577214 #>>43577226 #>>43577314 #>>43577850 #>>43578934 #>>43578952 #>>43578973 #>>43579760 #>>43581498 #>>43582065 #>>43583922 #>>43585046 #>>43585094 #>>43587376 #
milicat ◴[] No.43575953[source]
The more I browse through this, the more I agree. I feel like one could delete almost all comments from that project without losing any information – which means, at least the variable naming is (probably?) sensible. Then again, I don't know the application domain.

Also…

  def _save_current_date_time(current_date_time_file: str, current_date_time: str) -> None:
    with Path(current_date_time_file).open("w") as f:
      f.write(current_date_time)
there is a lot of obviously useful abstraction being missed, wasting lines of code that will all need to be maintained.

The scary thing is: I have seen professional human developers write worse code.

replies(5): >>43576009 #>>43576011 #>>43576425 #>>43579037 #>>43579215 #
ramesh31 ◴[] No.43576009[source]
>The scary thing is: I have seen professional human developers write worse code.

This is kind of the rub of it all. If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter? I mean at that point its kind of like looking at the output of a bytecode compiler and being like "wow what a mess". And it's not like they can't write code up to your stylistic standards, it's just literally a matter of prompting for that.

replies(5): >>43576193 #>>43576693 #>>43577895 #>>43578279 #>>43579014 #
mjr00 ◴[] No.43576193[source]
> If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter?

You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.

We did this song and dance pretty recently with dynamic typing. Developers thought it was so much more productive to use dynamically typed languages, because it is in the initial phases. Then years went by, those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities, and those developers who hyped up dynamic typing invented Python/PHP type hinting and Flow for JavaScript, later moving to TypeScript entirely. Nowadays nobody seriously recommends building long-lived systems in untyped languages, but they are still very useful for one-off scripting and more interactive/exploratory work where correctness is less important, i.e. Jupyter notebooks.

I wouldn't be surprised to see the same pattern happen with low-supervision AI code; it's great for popping out the first MVP, but because it generates poor code, the gung-ho junior devs who think they're getting 10x productivity gains will wisen up and realize the value of spending an hour thinking about proper levels of abstraction instead of YOLO'ing the first thing the AI spits out when they want to build a system that's going to be worked on by multiple developers for multiple years.

replies(5): >>43576618 #>>43578091 #>>43578491 #>>43578913 #>>43579028 #
dheera ◴[] No.43578913[source]
> You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.

Humans also worry about their jobs, especially in PIP-happy companies; they are very well known for writing intentionally over-complicated code that only they understand so that they are irreplaceable

replies(2): >>43579292 #>>43589014 #
XorNot ◴[] No.43579292[source]
I'm not convinced this actually happens. Seems more like somthing people assume happens because they don't like whatever codebase is at the new job.
replies(3): >>43579323 #>>43579631 #>>43582088 #
baq ◴[] No.43579631{3}[source]
If your TC is 500k-1M and you don’t feel like job hopping anymore, you’d certainly not want to get hit by a random layoff due to insufficient organizational masculinity or whatever. Maintaining a complex blob of mission critical code is one way of increasing your survival chances, though of course nothing is guaranteed.
replies(1): >>43579765 #
1. LtWorf ◴[] No.43579765{4}[source]
People doing layoffs have no idea of who works and who's warming the chair.
replies(1): >>43579819 #
2. baq ◴[] No.43579819[source]
Depending on the layoff they may look into yearly reviews... or not.
replies(1): >>43580472 #
3. LtWorf ◴[] No.43580472[source]
Ah yes, those work /s