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

Things that helped me get out of the AI 10x engineer imposter syndrome

colton.dev

Post reply on HN
Print view View original

641–650 of 675 posts

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#641

Post by generalizations »

pornel wrote: post #548
generalizations wrote: post #66

In many ways this feels like average software engineers telling on themselves. If you know the tech you're building, and you're good at splitting up your work, then you know ahead of time where the complexity is and you can tell the AI what level of granularity to build at. AI isn't magic; there is an upper limit to the complexity of a program that e.g. Sonnet 4 can write at once. If you can grok that limit, and you…

This is tautological. If you keep instructions dumbed-down enough for AI to work well, it will work well. The problem is that AI needs to be spoon-fed overly detailed dos and donts, and even then the output can't be trusted without carefully checking it. It's easy to reach a point where breaking down the problem into pieces small enough for AI to understand takes more work than just writing the code. AI may save time…

I made an STT tool (guess who wrote it for me) and have a bluetooth mic. I spend 10 minutes pacing and telling the AI what I need it to build, and how to build it. Then it goes off and builds it, and meanwhile I go to the next Claude Code instance on a different project, and do the same thing there. Then do the same for a third, and maybe by that time the first is ready for more direction. Depending on how good you are with context switching and quickly designing complex systems and communicating those designs, you can get a whole lot done in parallel. The problems you're describing can be solved, if you're careful and detailed.

It's a brave, weird and crazy new world. "The future is now, old man."

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#642

Post by generalizations »

Fraterkes wrote: post #197
generalizations wrote: post #66

In many ways this feels like average software engineers telling on themselves. If you know the tech you're building, and you're good at splitting up your work, then you know ahead of time where the complexity is and you can tell the AI what level of granularity to build at. AI isn't magic; there is an upper limit to the complexity of a program that e.g. Sonnet 4 can write at once. If you can grok that limit, and you…

Is the implication here that you consider yourself an above-average engineer?

The implication is that I'm finding it straightforward to handle the issues that other people here seem to consider insurmountable. And they seem to be directly related to how good one is at building software.

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#643

Post by com2kid »

astrange wrote: post #604
com2kid wrote: post #584

Earlier quoted context omitted.

> device drivers are the easiest thing in the world to code. Except the documentation lies and in reality your vendor shipped you a part with timing that is slightly out of sync with what the doc says and after 3 months of debugging, including using an oscilloscope, you figure out WTF is going on. You report back to your supplier and after two weeks of them not saying any thing they finally reply that the timings you…

I'm not sure if this counts as systems or application engineering, but if you think your computer doesn't lie to you, try writing an nginx config. Those things aren't evaluated at /all/ the way they look like they are.

At no point have any of my nginx files ever flipped their own bits.

Are they a constant source of low level annoyance? Sure. But I've never had to look at a bus timing diagram to understand how to use one, nor worried about an nginx file being rotated 90 degrees and wired up wrong!

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#644

Post by necovek »

bongodongobob wrote: post #518
necovek wrote: post #403

Earlier quoted context omitted.

Even so, tickets munched out or tasks completed is still "output" — sometimes you could provide more value by avoiding tickets that are not bringing benefits to customers or business, solving things customers need and not what they think they need, suggesting solutions which are 5% of work yet provide 90% of the value, etc.

My job is to do what's asked of me. Do the stories, knock out the tickets. It helps me do that faster. That's a crazy far goalpost move from you.

I never worked as an engineer like that: I always wanted to influence what I am being asked to do (I started with free software communities, moved to an open source company, and only worked "proprietary" work the last decade), and especially, challenging it when I was confident it made no sense, or when there were obvious improvements for the end user experience at lower, equal, or slightly bigger cost.

You can certainly be very productive by doing what you are told. I'd probably fail at that metric against many engineers, yet people usually found me very valuable to their teams (I never asked if it was 1x or 2x or 0.5x compared to whatever they perceive as average).

The last few years, I am focused on empowering engineers to be equal partners in deciding what is being done, by teaching them to look for and suggest options which are 10% of the effort and 90% of the value for the user (or 20/80, and sometimes even 1% effort for 300% the value). Because they can best see what is simple and easy to do with the codebase, so if they put customer hat on, they unlock huge wins for their team and business.

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#645

Post by necovek »

Tronno wrote: post #525
necovek wrote: post #204

Earlier quoted context omitted.

An aside, but I am curious: as an old hat today, I now find that using the Perl RE (though some of it lives on through sed) syntax as "we used to do back in the day" in regular communications confuses most people. People are usually unfamiliar with it, so I am slowly phasing it out. What's your experience? And what do the "kids" use these days to indicate alternative options (as above — though for that, I use bash {}…

I've never used Perl and I am not confused. It's just an eyeroll-inducing referential joke, and ironically a perfect example of OP's point. See also: $BIGCORP, Day_Job, etc They could have just said "the most important language [...] is spoken language".

I understand the meaning — I am a self professed "old hat" :)

I am curious if this is still understandable in wider software engineering circles, esp outside the HN and Linux bubbles.

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#646

Post by necovek »

ffsm8 wrote: post #210
necovek wrote: post #185

Earlier quoted context omitted.

Thanks for this perspective, but I am a bit confused by some of your takes: you used "Claude Code with Opus model" in "the same toy project" with great success, which led you to conclude that this will "make a vast majority of all jobs redundant". Toy project viability does not connect with making people redundant in the process (ever, really) — at least not for me. Care to elaborate where do you draw the optimism fr…

I cannot use it on my production code base. I'm working for a company that requires the devs to code from virtual workplaces, which is a fancy term to say virtual machines running in the azure cloud. These are completely locked down and anything but copilot is forbidden from use, and enforced via firewall and process monitoring. I can still use sonnet 3.7 through that, but that's a far cry from my experience on my pe…

I did not miss the time horizon: this is why I put a remark of "ever, really".

"Toy project" is usually used in a different context (demonstrate something without really doing something useful): yours sounds more like a "hobby project".

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#647

Post by necovek »

AdrianB1 wrote: post #293
necovek wrote: post #211

Earlier quoted context omitted.

The first red flag there is "2x their output". You can find many an anecdote where a good engineer produced better solution in fewer lines of code (or sometimes, by removing code — the holy grail). So always aim for outcomes , not output :) At my company, we did promote people quickly enough that they are now close to double their salaries when they started a year or so ago, due to their added value as engineers in t…

When I go to buy 2 bottles of milk I am never offered to get it for 1.x the price of one bottle. I don't see any way it is fair to deliver double and get just 1.5x, in a hypothetical scenario just for the sake of the discussion. The suggestion to work 50% of the time and relax, socialize and network the other 50% is way more reasonable, when possible (not in my case).

I am always being bombarded with different "buy more for less" options in any store I enter. All of those "3rd item free", "second item 50% off"...

The thing is that company is hunting for better value, and you are looking for a better deal.

If company can get 2x engineers' production at lower cost, you are only more valuable than having 2 engineers producing as much if you are cheaper. Your added value is this extra 1x production, but if you are selling "that" at the same price, they are just as well off by hiring two engineers instead of you: there is no benefit to having you over them.

If you can do it cheaper, then you are more valuable the cheaper you are. Which is why I said 1.5x cost is splitting the value/cost between you and the employer.

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#649

Post by TsiCClawOfLight »

docmars wrote: post #549
spopejoy wrote: post #421

Earlier quoted context omitted.

> Being able to refactor things with only a couple sentences is remarkably fast. I'm curious, this is js/ts? Asking because depending on the lang, good old machine refactoring is either amazeballs (Java + IDE) or non-existent (Haskell). I'm not js/ts so I don't know what the state of machine refactoring is in VS code ... But if it's as good as Java then "a couple of sentences" is quite slow compared to a keystroke or…

I'm using TypeScript. In my case, these refactors are usually small and only spanning up to 5 files depending on how interdependent things are. The benefit with an Agent is it's ability to find and detect related side effects caused by the refactor (broken type-safety, broken translation strings, etc.) and renaming for related things, like an actual UI string if it's tied to the naming of what I'm working on, and my…

IntelliJ has keyboard shortcuts for all of these. I think how impressed you are by AI depends a lot on the quality of the tooling you were previously working with.

Re: Things that helped me get out of the AI 10x engineer imposter syndrome

#650

Post by Fraterkes »

generalizations wrote: post #642
Fraterkes wrote: post #197

Earlier quoted context omitted.

Is the implication here that you consider yourself an above-average engineer?

The implication is that I'm finding it straightforward to handle the issues that other people here seem to consider insurmountable. And they seem to be directly related to how good one is at building software.

I’ve seen claims of this flavour in the past, and it often turns out that the person making the claim is writing software that is a lot less novel / complicated than the software the other engineers (who struggle to find uses for ai) are writing.
Post reply on HN