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

81–90 of 323 posts

Re: Senior Developer Skills in the AI Age

#81

Post by lolinder »

Aurornis wrote: post #36
milicat wrote: post #24

Earlier quoted context omitted.

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(…

> I feel like one could delete almost all comments from that project without losing any information I far from a heavy LLM coder but I’ve noticed a massive excess of unnecessary comments in most output. I’m always deleting the obvious ones. But then I started noticing that the comments seem to help the LLM navigate additional code changes. It’s like a big trail of breadcrumbs for the LLM to parse. I wouldn’t be surpr…

It doesn't hurt that the model vendors get paid by the token, so there's zero incentive to correct this pattern at the model layer.

Re: Senior Developer Skills in the AI Age

#82

Post by shove »

ramesh31 wrote: post #76
nsonha wrote: post #67

Earlier quoted context omitted.

Why do you HAVE TO one-shot? No one says you have to code like those influencers. You are a software engineer, use AI like one, iteratively.

>No one says you have to code like those influencers. You are a software engineer, use AI like one, iteratively. This is my issue with all the AI naysayers at this point. It seems to all boil down to "haha, stupid noob can't code so he uses AI" in their minds. It's like they are incapable of understanding that there could simultaneously be a bunch of junior devs pushing greenfield YouTube demos of vibe coding, while…

“Maybe you didn’t hear me, I said ‘good morning steam driver, how are you?’”

Re: Senior Developer Skills in the AI Age

#83

Post by lolinder »

nottorp wrote: post #52
mjr00 wrote: post #33

Earlier quoted context omitted.

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

> those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities In my experience, type checking / type hinting already starts to pay off when more than one person is working on an even small-ish code base. Just because it helps you keep in mind what comes/goes to the other guy's code.

And in my experience "me 3 months later" counts as a whole second developer that needs accommodating. The only time I appreciate not having to think about types is on code that I know I will never, ever come back to—stuff like a one off bash script.

Re: Senior Developer Skills in the AI Age

#84

Post by yoyohello13 »

I’ve been pretty moderate on AI but I’ve been using Claude cli lately and it’s been pretty great.

First, I can still use neovim which is a massive plus for me. Second it’s been pretty awesome to offload tasks. I can say something like “write some unit tests for this file, here are some edge cases I’m particularly concerned about” then I just let it run and continue with something else. Come back a few mins later to see what it came up with. It’s a fun way to work.

Re: Senior Developer Skills in the AI Age

#85

Post by PaulDavisThe1st »

thisdougb wrote: post #20
skizm wrote: post #6

Earlier quoted context omitted.

Waterfall has always been the best model as long as specs are frozen, which is never the case.

When I first started in dev, on a Unix OS, we did 'waterfall' (though we just called it releasing software, thirty years ago). We did a a major release every year, minor releases every three months, and patches as and when. All this software was sent to customers on mag tapes, by courier. Minor releases were generally new features. Definitely times were different back then. But we did release software often, and it t…

The difference between agile and waterfall only really matters at the start of a project. Once it is deployed/released/in-use, the two approaches converge, more or less.

Re: Senior Developer Skills in the AI Age

#86

Post by abid786 »

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,…

Doesn’t load_json throw if the file doesn’t exist?

Re: Senior Developer Skills in the AI Age

#87

Post by guskel »

nottorp wrote: post #52
mjr00 wrote: post #33

Earlier quoted context omitted.

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

> those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities In my experience, type checking / type hinting already starts to pay off when more than one person is working on an even small-ish code base. Just because it helps you keep in mind what comes/goes to the other guy's code.

Yep, I've seen type hinting even be helpful without a type checker in python. Just as a way for devs to tell each other what they intend on passing. Even when a small percent of the hints are incorrect, having those hints there can still pay off.

Re: Senior Developer Skills in the AI Age

#88

Post by rcfox »

Perizors wrote: post #75
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,…

How do you properly configure a logger in application like that?

Usually you would do it in your main function, or a code path starting from there. Executing code with non-local side effects during import is generally frowned upon. Maybe it's fine for a project-local module that won't be shared, but it's a bad habit and can make it had to track down.

Re: Senior Developer Skills in the AI Age

#89

Post by NewsaHackO »

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

Explain the issue with load_json to me more. From my reading it checks if the file exists, then raises an error if it does not. How is that carrying on as if the file is certainly there?

Re: Senior Developer Skills in the AI Age

#90

Post by ilrwbwrkhv »

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,…

Yup this tracks with what I have seen as well. Most devs who use this daily are usually junior devs or javascript devs who both write sloppy questionable code.
Post reply on HN