9 ms·

That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and revi

by pdntspa 10mo ago

That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code. I am phenomenally productive this way, I am happier at my job, and its quality of work is extremely high as long as I occasionally have it stop and self-review it's progress against the style principles articulated in its AGENTS.md file. (As it tends to forget a lot of rules like DRY)

n4r9 10mo ago
I think we have different opinions on what's fun and what's boring!
- moffkalast 10mo ago
  He's a real straight shooter with upper management written all over him.
  - wpasc 10mo ago
    but what would you say... you do here?
  - SoftTalker 10mo ago
    Ummm, yeah... I’m gonna have to go ahead and sort of disagree with you there.
- AStrangeMorrow 10mo ago
  I really enjoy writing some of the code. But some is a pain. Never have fun when the HQ team asks for API changes for the 5th time this month. Or for that matter writing the 2000 lines of input and output data validation in the first place. Or refactoring that ugly dictionary passed all over the place to be a proper class/dataclass. Handling config changes. Lots of that piping job. Some tasks I do enjoy coding. Once in the flow it can be quite relaxing. But mostly I enjoy the problem solving part: coming up with the right algorithm, a nice architecture , the proper set of metrics to analyze etc
- embedding-shape 10mo ago
  Some people are into designing software, others like to put the design into implementation, others like cleaning up implementations yet others like making functional software faster. There is enough work for all of us to be handsomely paid while having fun doing it :) Just find what you like, and work with others who like other stuff, and you'll get through even the worst of problems. For me the fun comes not from the action of typing stuff with my sausage fingers and seeing characters end up on the screen, but basically everything before that and after that. So if I can make "translate what's in my head into source on disk something can run" faster, that's a win in my book, but not if the quality degrades too much, so tight control over it still not having to use my fingers to actually type.
  - mkehrt 10mo ago
    I've found that good tab AI-based tab completion is the sweet spot for me. I am still writing code, but I don't have to type all of it if it's obvious.
    - OkayPhysicist 10mo ago
      This has been my approach, as well. I've got a neovim setup where I can 1) open up a new buffer, ask a question, and then copy/paste from it and 2) prompt the remainder of the line, function, or class. (the latter two are commands I run, rather than keybinds).
- Nemi 10mo ago
  You've really hit the crux of the problem and why so many people have differing opinions about AI coding. I also find coding more fun with AI. The reason is that my main goal is to solve a problem, or someone else's problem, in a way that is satisfying. I don't much care about the code itself anymore. I care about the thing that it does when it's done. Having said that I used to be deep into coding and back then I am quite sure that I would hate AI coding for me. I think for me it comes down to – when I was learning about coding and stretching my personal knowledge in the area, the coding part was the fun part because I was learning. Now that I am past that part I really just want to solve problems, and coding is the means to that end. AI is now freeing because where I would have been reluctant to start a project, I am more likely to give it a go. I think it is similar to when I used to play games a lot. When I would play a game where you would discover new items regularly, I would go at it hard and heavy up until the point where I determined there was either no new items to be found or it was just "more of the same". When I got to that point it was like a switch would flip and I would lose interest in the game almost immediately.
  - pdntspa 10mo ago
    You are hitting the nail on the head. We are not being hired to write code. We are being hired to solve problems. Code is simply the medium.
    - wahnfrieden 10mo ago
      I believe wage work has a significant factor in all this. Most are not paid for results, they're paid for time at desk and regular responsibilities such as making commits, delivering status updates, code reviews, etc. - the daily activities of work are monitored more closely than the output. Most ESOP grant such little equity that working harder could never observably drive an increase in its value. Getting a project done faster just means another project to begin sooner. Naturally workers will begin to prefer the motions of the work they find satisfying more than the result it has for the business's bottom line, from which they're alienated.
      - Sammi 10mo ago
FeteCommuniste 10mo ago
Maybe I'm weird but I enjoy "actually writing the code."
- pdntspa 10mo ago
  Me writing code is me spending 3/4 of my time wading through documentation and google searches. It's absolutely hell on my ADD. My ability to memorize is absolutely garbage. Throughout my career I've worked in like 10 different languages, and in any given project I'm usually working in at least 3 or 4. There's a lot of "now what is a map operation in this stupid fucking language called again?!" Claude writing code gets the same output if not better in about 1/10 of the time. That's where you realize that the writing code bits are just one small part of the overall picture. One that I realize I could do without.
  - n4r9 10mo ago
    May be a domain issue? If you're largely coding within a JS framework (which most software devs are tbf) then that makes total sense. If you're working in something like fintech or games, perhaps less so.
    - pdntspa 10mo ago
      My last job was a mix of Ruby, Python, Bash, SQL, and Javascript (and CSS and HTML). One or two jobs before that it was all those plus a smattering of C. A few jobs before that it was C# and Perl.
  - tayo42 10mo ago
    How do you end up with 3 to 4 languages in one project?
    - saulpw 10mo ago
      Typescript on the frontend, Python on the backend, SQL for the database, bash for CI. This isn't even counting HTML/CSS or the YAML config.
alfalfasprout 10mo ago
I really hope you don't actually treat junior devs this way...
mjr00 10mo ago
> That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code. I am so tired of this analogy. Have the people who say this never worked with a junior dev before? If you treat your junior devs as brainless code monkeys who only exist to type out your brilliant senior developer designs and architectures instead of, you know, human beings capable of solving problems, 1) you're wasting your time, because a less experienced dev is still capable of solving problems independently, 2) the juniors working under you will hate it because they get no autonomy, and 3) the juniors working under you will stay junior because they have no opportunity to learn--which means you've failed at one of your most important tasks as a senior developer, which is mentorship.
- pdntspa 10mo ago
  I have mentored and worked with a junior dev. And the only way to get her to do anything useful and productive was to spell things out. Otherwise she got wrapped around the axle trying to figure out the complex things and was constantly asking for my help with basic design-level tasks. Doing the grunt work is how you learn the higher-level stuff. When I was a junior, that's how it was for me. The senior gave me something that was structured and architected and asked me to handle smaller tasks that were beneath them. Giving juniors full autonomy is a great way to end up with an unmaintainable mess that is a nightmare to work with without substancial refactoring. I know this because I have made a career out of fixing exactly this mistake.
  - mjr00 10mo ago
    I have never worked with junior devs as incompetent as you describe, having worked at AWS, Splunk/Cisco, among others. At AWS even interns essentially got assigned a full project for their term and were just told to go build it. Does your company just have an absurdly low hiring bar for juniors? > Giving juniors full autonomy is a great way to end up with an unmaintainable mess that is a nightmare to work with without substancial refactoring. Nobody is suggesting they get full autonomy to cowboy code and push unreviewed changes to prod. Everything they build should be getting reviewed by their peers and seniors. But they need opportunities to explore and make mistakes and get feedback.
rootnod3 10mo ago
Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?
- eightysixfour 10mo ago
  What would you like individual contributors to do about it, exactly? Refuse to use it, even though this person said they're happier and more fulfilled at work? I'm asking because I legitimately have not figured out an answer to this problem.
- bpt3 10mo ago
  Why is that a developer's problem? If anything, they are incentivized to avoid creating future competition in the job market.
  - rootnod3 10mo ago
    It's not a problem for the senior dev directly, but maybe down the road. And it definitely is a problem for the company once said senior dev leaves or retires. Seriously, long term thinking went out the window long time ago, didn't it?
    - bpt3 10mo ago
      No, long term thinking didn't go out the window. It is definitely a problem for the company. How is it a problem for the senior dev at any point? What incentive do they have to aid the company at the expense of their own *long term* career prospects?
- fluidcruft 10mo ago
  How do you get junior devs if your concept of the LLM is that it's "a principal engineer" that "do[es] not ask [you] any questions"? Also, I'm pretty sure junior devs can use directing a LLM to learn from mistakes faster. Let them play. Soon enough they're going to be better than all of us anyway. The same way widespread access to strong chess computers raised the bar at chess clubs.
AStrangeMorrow 10mo ago
Yeah at this point I basically have to dictate all implementation details: do this, but do it this specific way, handle xyz edge cases by doing that, plug the thing in here using that API. Basically that expands 10 lines into 100-200 lines of code. However if I just say “I have this goal, implement a solution”, chances are that unless it is a very common task, it will come up with a subpar/incomplete implementation. What’s funny to me is that complexity has inverted for some tasks: it can ace a 1000 lines ML model for a general task I give it, yet will completely fail to come up with a proper solution for a 2D geometric problem that mostly has high school level maths that can be solved in 100 lines
tiku 10mo ago
I enjoy finding the problem and then telling Claude to fix it. Specifying the function and the problem. Then going to get a coffee from the breakroom to see it finished when I return. The junior dev has questions when I did that. Claude just fixes it.
order-matters 10mo ago
I wonder if DRY is still a principle worth holding onto in the AI coding era. I mean it probably is, but this feels like enough of a shift in coding design that re-evaluating principles designed for human-only coding might be worth the effort
xnx 10mo ago
> rules like DRY Principles like DRY
mrsmrtss 10mo ago
> its quality of work is extremely high ... It may seem decent until you look closer. Just like with a junior dev, you should always review the code very carefully, you can absolutely not trust it. It's not bad at trivial stuff, but fails almost always if things get more complex and unlike a junior dev, it does not tell you, when things get too complex for it.
deleted 10mo ago
[deleted]
urxvtcd 10mo ago
Few weeks ago I'd disagree with you, but recently I've been struggling with concentration and motivation and now I kind of try to embrace coding with AI. I guide it pretty strictly, try to stick with pure functions, and always read the output thoroughly. In a couple of places requiring some carefulness I coded them in executable pseudocode (Python) and made AI translate it to the more boilerplate-y target language. I don't know if I'm any faster than I would be if I was motivated, but I'm A LOT more productive in my current state. I still hope for the next AI winter though.
traceroute66 10mo ago
I don't follow. In the same breath (same paragraph) you state two polar opposites about working with AI: - I am phenomenally productive - "as long as I occasionally have it stop" and "it tends to forget a lot of rules like DRY" I don't see how you can claim to be "phenomenally productive" when working with a tool you have to babysit because it forgets your instructions the whole time. If it was the "junior dev" you also mention, I suspect you would very quickly invite the "junior dev" to find a job elsewhere.
- pdntspa 10mo ago
  You don't have to follow. I'm still punching way above my weight. Not sure why both things can't be true at once.

by pdntspa 10mo ago

n4r9 10mo ago

I think we have different opinions on what's fun and what's boring!

moffkalast 10mo ago
He's a real straight shooter with upper management written all over him.
- wpasc 10mo ago
  but what would you say... you do here?
- SoftTalker 10mo ago
  Ummm, yeah... I’m gonna have to go ahead and sort of disagree with you there.
AStrangeMorrow 10mo ago
I really enjoy writing some of the code. But some is a pain. Never have fun when the HQ team asks for API changes for the 5th time this month. Or for that matter writing the 2000 lines of input and output data validation in the first place. Or refactoring that ugly dictionary passed all over the place to be a proper class/dataclass. Handling config changes. Lots of that piping job. Some tasks I do enjoy coding. Once in the flow it can be quite relaxing. But mostly I enjoy the problem solving part: coming up with the right algorithm, a nice architecture , the proper set of metrics to analyze etc
embedding-shape 10mo ago
Some people are into designing software, others like to put the design into implementation, others like cleaning up implementations yet others like making functional software faster. There is enough work for all of us to be handsomely paid while having fun doing it :) Just find what you like, and work with others who like other stuff, and you'll get through even the worst of problems. For me the fun comes not from the action of typing stuff with my sausage fingers and seeing characters end up on the screen, but basically everything before that and after that. So if I can make "translate what's in my head into source on disk something can run" faster, that's a win in my book, but not if the quality degrades too much, so tight control over it still not having to use my fingers to actually type.
- mkehrt 10mo ago
  I've found that good tab AI-based tab completion is the sweet spot for me. I am still writing code, but I don't have to type all of it if it's obvious.
  - OkayPhysicist 10mo ago
    This has been my approach, as well. I've got a neovim setup where I can 1) open up a new buffer, ask a question, and then copy/paste from it and 2) prompt the remainder of the line, function, or class. (the latter two are commands I run, rather than keybinds).
Nemi 10mo ago
You've really hit the crux of the problem and why so many people have differing opinions about AI coding. I also find coding more fun with AI. The reason is that my main goal is to solve a problem, or someone else's problem, in a way that is satisfying. I don't much care about the code itself anymore. I care about the thing that it does when it's done. Having said that I used to be deep into coding and back then I am quite sure that I would hate AI coding for me. I think for me it comes down to – when I was learning about coding and stretching my personal knowledge in the area, the coding part was the fun part because I was learning. Now that I am past that part I really just want to solve problems, and coding is the means to that end. AI is now freeing because where I would have been reluctant to start a project, I am more likely to give it a go. I think it is similar to when I used to play games a lot. When I would play a game where you would discover new items regularly, I would go at it hard and heavy up until the point where I determined there was either no new items to be found or it was just "more of the same". When I got to that point it was like a switch would flip and I would lose interest in the game almost immediately.
- pdntspa 10mo ago
  You are hitting the nail on the head. We are not being hired to write code. We are being hired to solve problems. Code is simply the medium.
  - wahnfrieden 10mo ago
    I believe wage work has a significant factor in all this. Most are not paid for results, they're paid for time at desk and regular responsibilities such as making commits, delivering status updates, code reviews, etc. - the daily activities of work are monitored more closely than the output. Most ESOP grant such little equity that working harder could never observably drive an increase in its value. Getting a project done faster just means another project to begin sooner. Naturally workers will begin to prefer the motions of the work they find satisfying more than the result it has for the business's bottom line, from which they're alienated.
    - Sammi 10mo ago

FeteCommuniste 10mo ago

Maybe I'm weird but I enjoy "actually writing the code."

pdntspa 10mo ago
Me writing code is me spending 3/4 of my time wading through documentation and google searches. It's absolutely hell on my ADD. My ability to memorize is absolutely garbage. Throughout my career I've worked in like 10 different languages, and in any given project I'm usually working in at least 3 or 4. There's a lot of "now what is a map operation in this stupid fucking language called again?!" Claude writing code gets the same output if not better in about 1/10 of the time. That's where you realize that the writing code bits are just one small part of the overall picture. One that I realize I could do without.
- n4r9 10mo ago
  May be a domain issue? If you're largely coding within a JS framework (which most software devs are tbf) then that makes total sense. If you're working in something like fintech or games, perhaps less so.
  - pdntspa 10mo ago
    My last job was a mix of Ruby, Python, Bash, SQL, and Javascript (and CSS and HTML). One or two jobs before that it was all those plus a smattering of C. A few jobs before that it was C# and Perl.
- tayo42 10mo ago
  How do you end up with 3 to 4 languages in one project?
  - saulpw 10mo ago
    Typescript on the frontend, Python on the backend, SQL for the database, bash for CI. This isn't even counting HTML/CSS or the YAML config.

alfalfasprout 10mo ago

I really hope you don't actually treat junior devs this way...

mjr00 10mo ago

> That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code. I am so tired of this analogy. Have the people who say this never worked with a junior dev before? If you treat your junior devs as brainless code monkeys who only exist to type out your brilliant senior developer designs and architectures instead of, you know, human beings capable of solving problems, 1) you're wasting your time, because a less experienced dev is still capable of solving problems independently, 2) the juniors working under you will hate it because they get no autonomy, and 3) the juniors working under you will stay junior because they have no opportunity to learn--which means you've failed at one of your most important tasks as a senior developer, which is mentorship.

pdntspa 10mo ago
I have mentored and worked with a junior dev. And the only way to get her to do anything useful and productive was to spell things out. Otherwise she got wrapped around the axle trying to figure out the complex things and was constantly asking for my help with basic design-level tasks. Doing the grunt work is how you learn the higher-level stuff. When I was a junior, that's how it was for me. The senior gave me something that was structured and architected and asked me to handle smaller tasks that were beneath them. Giving juniors full autonomy is a great way to end up with an unmaintainable mess that is a nightmare to work with without substancial refactoring. I know this because I have made a career out of fixing exactly this mistake.
- mjr00 10mo ago
  I have never worked with junior devs as incompetent as you describe, having worked at AWS, Splunk/Cisco, among others. At AWS even interns essentially got assigned a full project for their term and were just told to go build it. Does your company just have an absurdly low hiring bar for juniors? > Giving juniors full autonomy is a great way to end up with an unmaintainable mess that is a nightmare to work with without substancial refactoring. Nobody is suggesting they get full autonomy to cowboy code and push unreviewed changes to prod. Everything they build should be getting reviewed by their peers and seniors. But they need opportunities to explore and make mistakes and get feedback.

rootnod3 10mo ago

Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?

eightysixfour 10mo ago
What would you like individual contributors to do about it, exactly? Refuse to use it, even though this person said they're happier and more fulfilled at work? I'm asking because I legitimately have not figured out an answer to this problem.
bpt3 10mo ago
Why is that a developer's problem? If anything, they are incentivized to avoid creating future competition in the job market.
- rootnod3 10mo ago
  It's not a problem for the senior dev directly, but maybe down the road. And it definitely is a problem for the company once said senior dev leaves or retires. Seriously, long term thinking went out the window long time ago, didn't it?
  - bpt3 10mo ago
    No, long term thinking didn't go out the window. It is definitely a problem for the company. How is it a problem for the senior dev at any point? What incentive do they have to aid the company at the expense of their own *long term* career prospects?
fluidcruft 10mo ago
How do you get junior devs if your concept of the LLM is that it's "a principal engineer" that "do[es] not ask [you] any questions"? Also, I'm pretty sure junior devs can use directing a LLM to learn from mistakes faster. Let them play. Soon enough they're going to be better than all of us anyway. The same way widespread access to strong chess computers raised the bar at chess clubs.

AStrangeMorrow 10mo ago

Yeah at this point I basically have to dictate all implementation details: do this, but do it this specific way, handle xyz edge cases by doing that, plug the thing in here using that API. Basically that expands 10 lines into 100-200 lines of code. However if I just say “I have this goal, implement a solution”, chances are that unless it is a very common task, it will come up with a subpar/incomplete implementation. What’s funny to me is that complexity has inverted for some tasks: it can ace a 1000 lines ML model for a general task I give it, yet will completely fail to come up with a proper solution for a 2D geometric problem that mostly has high school level maths that can be solved in 100 lines

tiku 10mo ago

I enjoy finding the problem and then telling Claude to fix it. Specifying the function and the problem. Then going to get a coffee from the breakroom to see it finished when I return. The junior dev has questions when I did that. Claude just fixes it.

order-matters 10mo ago

I wonder if DRY is still a principle worth holding onto in the AI coding era. I mean it probably is, but this feels like enough of a shift in coding design that re-evaluating principles designed for human-only coding might be worth the effort

xnx 10mo ago

> rules like DRY Principles like DRY

mrsmrtss 10mo ago

> its quality of work is extremely high ... It may seem decent until you look closer. Just like with a junior dev, you should always review the code very carefully, you can absolutely not trust it. It's not bad at trivial stuff, but fails almost always if things get more complex and unlike a junior dev, it does not tell you, when things get too complex for it.

deleted 10mo ago

[deleted]

urxvtcd 10mo ago

Few weeks ago I'd disagree with you, but recently I've been struggling with concentration and motivation and now I kind of try to embrace coding with AI. I guide it pretty strictly, try to stick with pure functions, and always read the output thoroughly. In a couple of places requiring some carefulness I coded them in executable pseudocode (Python) and made AI translate it to the more boilerplate-y target language. I don't know if I'm any faster than I would be if I was motivated, but I'm A LOT more productive in my current state. I still hope for the next AI winter though.

traceroute66 10mo ago

I don't follow. In the same breath (same paragraph) you state two polar opposites about working with AI: - I am phenomenally productive - "as long as I occasionally have it stop" and "it tends to forget a lot of rules like DRY" I don't see how you can claim to be "phenomenally productive" when working with a tool you have to babysit because it forgets your instructions the whole time. If it was the "junior dev" you also mention, I suspect you would very quickly invite the "junior dev" to find a job elsewhere.

pdntspa 10mo ago
You don't have to follow. I'm still punching way above my weight. Not sure why both things can't be true at once.