Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Senior Developer Skills in the AI Age

manuel.kiessling.net

Post reply on HN
Print view View original

311–320 of 323 posts

Re: Senior Developer Skills in the AI Age

#311

Post by necovek »

inerte wrote: post #269
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,…

100%! But the alternative would be the tool doesn't get built because the author doesn't know enough Python to even produce crappy code, or doesn't have the money to hire an awesome Python coder to do that for them.

If you check elsewhere in this thread, the author decided on Python to test out AI capabilities — they could have built it quickly in a language of their choice. I am sure I could have built it quickly in Python to a higher standard of quality.

Perhaps they wouldn't have built it because they did not set the time aside for it, like they did for this experiment (+ the blog post).

Re: Senior Developer Skills in the AI Age

#312

Post by necovek »

ManuelKiessling wrote: post #163
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,…

Thanks for looking into it. While I would have hoped for a better result, I'm not surprised. In this particular case, I really didn't care about the code at all; I cared about the end result at runtime, that is, can I create a working, stable solution that solves my problem, in a tech stack I'm not familiar with? (While still taking care of well-structured requirements and guard rails — not to guarantee a specific le…

I'd definitely be curious to see if another session provides higher quality code — good luck, and thanks for taking this amicably!

Re: Senior Developer Skills in the AI Age

#313

Post by namaria »

fragmede wrote: post #239
cess11 wrote: post #230

Earlier quoted context omitted.

Salesforce is and pretty much always has been a set of code generation platforms. If you can produce a decent code generation platform, do it. It's one of the most sure ways to making money from software since it allows you to deploy systems and outsource a large portion of design to your customers. Spotify is not the audio player widget in some user interface. It started off as a Torrent-like P2P system for file dis…

> Since then they've added massive, sophisticated systems for user monitoring and prediction, ad distribution, abuse and fraud detection, and so on. Use that code generation platform to build a product off any combination of two of the larger subsystems at Spotify I'm listening. I fully admit that I was looking at Spotify as a user and thus only as a music playing widget so I'd love to hear more about this side of th…

> I fully admit that I was looking at Spotify as a user and thus only as a music playing widget

This is the key insight here. Software is not the interface you see. There a whole lot more you don't know about (and probably no one knew before building it), and asking an LLM to find some JS front end patterns that abound in its training data won't come close to giving you.

That is why so many developers are skeptical of the amount of hype around LLMs generating code.

Re: Senior Developer Skills in the AI Age

#314

Post by bumblehean »

necovek wrote: post #308
cinntaile wrote: post #278

Earlier quoted context omitted.

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

Logging configuration is done at import time for "utils" module. Imagine code like this: main.py: 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 ... Or two "commands", one importing utils and another not: they would non-obviously use different loggin…

As a non Python developer, what would be the use-case(s) for importing a module inside of the main function instead of importing it at the top of main.py with the others?

Re: Senior Developer Skills in the AI Age

#315

Post by namaria »

yapyap wrote: post #231

> Context on Code Quality (via HackerNews): The HackerNews discussion included valid critiques regarding the code quality in this specific Python project example (e.g., logger configuration, custom config parsing, potential race conditions). It’s a fair point, especially given I’m not a Python expert. For this particular green-field project, my primary goal was rapid prototyping and achieving a working solution in an…

Yup this is full on addiction mechanics. You use these generative tools, it feels great, the team and the organization feel great. But it's not warranted, the underlying thing is inherently flawed.

When the good feeling fades and you need to up the dosage, you will find that your ability to function is declining and your dependency on the generative tools is increasing. Besides no one is thinking about the end game. If (and its a big if) this goes to plan and these generative tools can do everything. Well at that point the only software needed is the generative tool itself isn't it? There would be no need for anything else so anyone building stuff on top of it, or using it to build stuff, would be SOL.

So best case scenario we all get addicted to fundamentally flawed technology because our ability to function independently has eroded too far, worst case there will be only foundational model companies operating in software.

Re: Senior Developer Skills in the AI Age

#316

Post by skydhash »

atemerev wrote: post #304
skydhash wrote: post #295

Earlier quoted context omitted.

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…

Well, of course I check the output and correct it as needed. It is still much faster than writing it myself. And less boring. As for the documentation part — I infer that you hadn't used state of the art models, had you? They do not write symbol docs mechanistically. They understand what the code is _doing_. Up to their context limits, which are now 128k for most models. Feed them 128k of code and more often than not…

> They do not write symbol docs mechanistically. They understand what the code is _doing_.

What the code is doing is important only when you intend to modify it. Normally, what's important is how to use it. That's the whole point of design: Presenting an API that hides how things happens in favor of making it easier (natural) to do something. The documentation should focus on that abstract design and the relation to the API. The concrete implementation rarely matters if you're on the other side of the API.

Re: Senior Developer Skills in the AI Age

#317

Post by necovek »

bumblehean wrote: post #314
necovek wrote: post #308

Earlier quoted context omitted.

Logging configuration is done at import time for "utils" module. Imagine code like this: main.py: 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 ... Or two "commands", one importing utils and another not: they would non-obviously use different loggin…

As a non Python developer, what would be the use-case(s) for importing a module inside of the main function instead of importing it at the top of main.py with the others?

Since the entire evaluation and running is dynamic, you don't need to import (and thus evaluate) a module in certain branches.

Eg. that `if __name__` trick is used to allow a module to be both a runnable script and importable module.

Top it off with plenty of common libraries being dog-slow to import because they are doing some of the anti-pattern stuff too, and you end up executing a lot of code when you just want to import a single module.

Eg. I've seen large Python projects that take 75s just importing all the modules because they are listing imports at the top, and many are executing code during import — imagine wanting to run a simple unit test, and your test runner takes 75s just to get to the point where it can run that 0.01s test for your "quick" TDD iteration.

You can also look at Instagram's approach to solving this over at their engineering blog.

Re: Senior Developer Skills in the AI Age

#318

Post by spoonfeeder006 »

alternatex wrote: post #309
spoonfeeder006 wrote: post #270

Earlier quoted context omitted.

Well, whats the difference between Vibe Coding in 5 - 10 years vs coding in C 5 - 10 years after compilers came out?

Compilers produce verifiable results. Are we seriously comparing compilers to LLMs? It's like comparing math to sociology.

Well, arguably so do LLMs. You put in the same input prompt, out comes the same code. But yeah, it is kinda different, but I'm just saying that as LLMs become better at understanding how to solve sub-problems, they may become reliable enough that coding via LLMs becomes the new norm, and learning how to effectively prompt will become a new skill for coders

Re: Senior Developer Skills in the AI Age

#319

Post by theteapot »

necovek wrote: post #310
theteapot wrote: post #206

Earlier quoted context omitted.

> 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.

There is a log message that won't be output in that case: whether getting a full, "native" FileNotFound exception is better is beside the point, since the goal of the code was obviously to print a custom error message. And it's trivial to achieve the desired effect sanely: try: with open(...) ... except FileNotFound: logger.error(...) raise It'd even be fewer lines of code.

Or even fewer by doing it in a global exception handler instead of every time you try to open a file, since all your doing is piping the error though logger.

Re: Senior Developer Skills in the AI Age

#320

Post by ManuelKiessling »

necovek wrote: post #312
ManuelKiessling wrote: post #163

Earlier quoted context omitted.

Thanks for looking into it. While I would have hoped for a better result, I'm not surprised. In this particular case, I really didn't care about the code at all; I cared about the end result at runtime, that is, can I create a working, stable solution that solves my problem, in a tech stack I'm not familiar with? (While still taking care of well-structured requirements and guard rails — not to guarantee a specific le…

I'd definitely be curious to see if another session provides higher quality code — good luck, and thanks for taking this amicably!

I did another session with the sole focus being on code quality improvements.

The commit with all changes that Cursor/claude-3.7-sonnet(thinking) has done is at https://github.com/dx-tooling/platform-problem-monitoring-co....

As you can see, I've fed your feeback verbatim:

  I have received the following feedback regarding this codebase:

  "The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: @utils.py. 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..."

  I therefore ask you to thoroughly improve the code quality of the implementation in @src   while staying in line with the requirements from @REQUIREMENTS.md, and while ensuring that the Quality Tools (see @makefile) won't fail. Also, make sure that the tests in folder @tests  don't break.

  See file @pyproject.toml for the general project setup. There is already a virtualenv at @venv.
You can watch a screen recording of the resulting Agent session at https://www.youtube.com/watch?v=zUSm1_NFKpA — I think it's an interesting watch because it nicely shows how the tool-based guard rails help the AI to keep on track and reach a "green" state eventually.
Post reply on HN