←back to thread

Senior Developer Skills in the AI Age

(manuel.kiessling.net)
421 points briankelly | 8 comments | 03 Apr 25 18:47 UTC | HN request time: 0s | source | bottom
Show context
necovek ◴[03 Apr 25 21:27 UTC] 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 ◴[03 Apr 25 21:55 UTC] 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 ◴[03 Apr 25 22:01 UTC] 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 #
dilyevsky ◴[03 Apr 25 23:28 UTC] No.43576693[source]▶
what are you going to do when something suddenly doesn't work and cursor endlessly spins without progress no matter how many "please don't make mistakes" you add? delete the whole thing and try to one-shot it again?
replies(1): >>43576880 #
nsonha ◴[03 Apr 25 23:55 UTC] No.43576880[source]▶
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.
replies(2): >>43577027 #>>43577098 #
ramesh31 ◴[04 Apr 25 00:21 UTC] No.43577027[source]▶
>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 at the same time expert software engineers are legitimately seeing their productivity increase 10x on serious codebases through judicious use.

Go ahead and keep swinging that hammer, John Henry.

replies(5): >>43577125 #>>43578176 #>>43578365 #>>43578997 #>>43579773 #
achierius ◴[04 Apr 25 04:37 UTC] No.43578365{4}[source]▶
I think some of the suspicion is that it's really not 10x in practice.
replies(1): >>43579953 #
1. Macha ◴[04 Apr 25 09:27 UTC] No.43579953{5}[source]▶
Like AI could write code perfectly as soon as I thought of it, and that would not improve my productivity 10x. Coding was never the slow part. Everything that goes around coding (like determining that the extra load here is not going to overload things, getting PMs to actually make their mind up what the feature is going to do, etc.), means that there's simply not that much time to be saved on coding activities.
replies(1): >>43580331 #
2. nsonha ◴[04 Apr 25 10:33 UTC] No.43580331[source]▶
Same argument can be said for not using any tooling really. "Tech is the easy part". No difference typing code on notepad and having zero process/engineering infrastructure I guess. Because stakeholder management is the main engineering skill apparently.

Btw, AI doesn't just code, there are AIs for debugging, monitoring etc too.

replies(2): >>43583213 #>>43585874 #
3. necovek ◴[04 Apr 25 14:47 UTC] No.43583213[source]▶
If you were to really measure speed improvement of notepad vs a tricked out IDE, it's probably not much. The problem would be the annoyance caused to an engineer who has to manually type out everything.

No, coding speed is really not the bottleneck to software engineer productivity.

replies(1): >>43583431 #
4. nsonha ◴[04 Apr 25 15:00 UTC] No.43583431{3}[source]▶
> coding speed > the annoyance caused to an engineer

No one said productivity is this one thing and not that one thing, only you say that because it's convenient for your argument. Productivity is a combination of many things, and again it's not just typing out code that's the only area AI can help.

replies(1): >>43585433 #
5. necovek ◴[04 Apr 25 17:28 UTC] No.43585433{4}[source]▶
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.

replies(1): >>43589842 #
6. achierius ◴[04 Apr 25 18:07 UTC] No.43585874[source]▶
There are two levels to this.

1. Tooling obviously does improve performance, but not so huge a margin. Yes, if AI could automate more elements of tooling, that would very much help. If I could tell an AI "bisect this bug, across all projects in our system, starting with this known-bad point", that would be very helpful -- sometimes. And I'm sure we'll get there soon enough. But there is fractal complexity here: what if isolating the bug requires stepping into LLDB, or dumping some object code, or running with certain stressors on certain hardware? So it's not clear that "LLM can produce code from specs, given tight oversight" will map (soon) to "LLM can independently assemble tools together and agentically do what I need done".

2. Even if all tooling were automated, there's still going to be stuff left over. Can the LLM draft architectural specs, reach out to other teams (or their LLMs), sit in meetings and piece together the big picture, sus out what the execs really want us to be working on, etc.? I do spend a significant (double-digit) percentage of my time working on that, so if you eliminate everything else -- then you could get 10x improvement, but going beyond that would start to run up against Amdahl's Law.

7. nsonha ◴[05 Apr 25 01:59 UTC] No.43589842{5}[source]▶
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.

replies(1): >>43590935 #
8. necovek ◴[05 Apr 25 05:09 UTC] No.43590935{6}[source]▶
I did not raise it, but what was raised was "coding speed": as in, the speed to type code into an editor.

That's not "engineering", but "coding".

Engineering already assumes a lot more than just coding: most importantly, thinking through a problem, learning about it and considering a design that would solve it.

Nobody raised communication or the human factors.

Current LLMs can indisputably help with the learning part, with the same caveats (they will sometimes make shit up). Here we are looking at how much they help with the coding part.