4 ms·

> it depends on what you enjoy: the journey or the destination This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing a

by donatj 7mo ago

> it depends on what you enjoy: the journey or the destination This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. The fun part is in the building, it's in the understanding, the growth of me. I have coworkers who get itchy when they don't see their work on production, and super defensive in code review but I've never really cared. The goal is to solve the puzzle. If there's a better way to solve the puzzle, I want to know. If it takes a week to get through code review, what do I care, I'm already off to the next puzzle. Being forced to use Claude at work, it really just took away everything that was enjoyable. Instead of solving puzzles I'm wrangling a digital junior dev that doesn't really learn from its mistakes, and lies all the time.

jebarker 7mo ago
I agree with you. I try to remember though that this is just the same situation that artists, musicians and (more recently) writers have been in for a long time. Unless you’re one of a very lucky few you’ll only get fulfillment in those pursuits if you enjoy the process rather than the output since it’s hard to get money or recognition for output anymore. Pure coding and lots of areas of code problem solving are going to end up in the same position.
mike_slinn 7mo ago
"wrangling a digital junior dev that doesn't really learn from its mistakes, and lies all the time" SO TRUE!
- sixtyj 7mo ago
  This dev thinks that it knows everything /s
specproc 7mo ago
One hundred percent. I came back into tech professionally over the last decade. Always been into computers, but the first decade or so of my career was in humanitarian amin. Super interesting sector, super boring day-to-day. Getting back into code felt like coming home. I'm good at it, I really enjoy it, the problem-solving aspect totally lights up my brain in this amazing way. I feel exactly the same way. Totally robbed of pleasure at work, with the added kicker of mass layoffs hanging over the sector. At least OP is sixty, I've got 25 years of work left and I really don't know what to do. I hate it all so much.
throw310822 7mo ago
Oh wow, that's exactly the opposite of how I feel, and conversely, I am that developer who gets itchy when his work doesn't go to prod quickly enough and gets defensive on code reviews. Sure, part of the fun of programming is understanding how things work, mentally taking them apart and rebuilding them in the particular way that meets your needs. But this is usually reserved for small parts of the code, self-contained libraries or architectural backbones. And at that level I think human input and direction are still important. Then there is the grunt work of glueing all the parts together, or writing some obvious logic, often for the umpteenth time- these are things I can happily delegate. And finally there are the choices you make because you think of the final product and of the experience of those who will use it- this is not a puzzle to solve at all, this is creative work and there is no predefined result to reach. I'm happy to have tools that allow me to get there faster.
voxleone 7mo ago
I've been coding since I was about 15 and still love it. These days I mostly build tailored applications for small and medium companies, often alone and sometimes with small ad-hoc teams. I also do the sales myself, in person. For me, not using LLMs would mean giving up a lot of productivity. But the way I use them is very structured. Work on an application starts with requirements appraisal: identifying actors, defining use cases, and understanding the business constraints. Then I design the objects and flows. When possible, I formalize the system with fairly strict axioms and constraints. Only after that do LLMs come in, mostly to help with the mechanical parts of implementation. In my experience it's still humans all the way down. The thinking, modeling, and responsibility for the system are human. The LLM just helps move the implementation faster. I also suspect the segment I work in will be among the last affected by LLM-driven job displacement. My clients are small to medium companies that need tailored internal systems. They're not going to suddenly start vibe-coding their own software. What they actually need is someone to understand the business, define the model, and take responsibility for the system. LLMs help with the implementation, but that part was never the hard part of the job.
- jantb 7mo ago
  I’m doing the same as you and even though I was producing coding a lot of the actual products I estimated the coding part just to be about 20% of the work. The rest is figuring out what and how to build stuff and what stakeholders really need, and solving production issues in live event driven systems. Agentic coding is just faster at the 20% part, and I can always sit down and code the really hard stuff if I want to or feel I need to if the LLM gets stuck. If it produces something not understandable I either learn from it until I understand it og makes it do a pattern I know instead. So all in all, not so worried.
finaard 7mo ago
> This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. The fun part is in the building, it's in the understanding, the growth of me. Quite a few of the projects I always wanted to do have components or dependencies I really don't want to do. And as a result, I never did them, unless they eventually became viable to do in a commercial setting where I then had some junior developer to make the annoying stuff go away. Now with LLMs I have my own junior developer to handle the annoying stuff - and as a result, a lot of my fun stuff I was thinking about in the last 3 decades finally got done. One example from just last week - I had a large C codebase from the 90s I always wanted to reuse, but modern compilers have a different idea of how C should look like. It's pretty obvious from the compiler errors what you need to do each case, but I wasn't really in the mood for manually going through hundreds of source files. So I just stuck a locally running qwen coder in yolo mode into a container, forgot about it for a week, and came back to a compiling code base. Diff is quick to review, only had a handful of cases where it needed manual intervention.
- throw-the-towel 7mo ago
  Note that you are able to choose freely what parts of the work get done by Claude, and what parts you do yourself. At work, many of us have no such luxury because bosses drunk on FOMO are forcing agent use.
  - finaard 7mo ago
    Yeah, I've noticed at several customers that they're just trying to cram LLMs into everything, instead of maybe first thinking if it's sensible for that specific usecase. I'm also doing some things where I don't think LLMs are not a good fit - but I'm doing it because I care to see about things like failure behaviour, how to identify when it is looping (which can be sometimes hard to see when using huge context models) and similar stuff - which results in more knowledge about when it makes sense to use LLMS. No such learnings visible at many customers, even if LLMs do something stupid.
sktrdie 7mo ago
You still care about end result though: in your case, the end result being the puzzled you solved. AI can make that process still enjoyable. For instance I had to build a very intricate cache handler for Next.js from scratch that worked in a very specific way by serializing JSON in chunks (instead of JSON.parse it all in memory). I knew the theory, but the API details and the other annoyances always made it daunting for me. With AI I was able to thinker more about the theory of the problem and less about the technical implementation which made the process much more fun and doable. Perhaps we're just climbing the ladder of abstraction: in the early days people were building their own garbage collection mechanisms, their own binary search algorithms, etc. Once we started using libraries, we had to find the fun in some higher level. Perhaps in the future the fun will be about solving puzzles within the realm of requirement definitions and all the intricacies that stem from that.
raw_anon_1111 7mo ago
Your company isn’t paying you to solve puzzles. If you aren’t putting things into production, what good are you as an employee? > Being forced to use Claude at work, it really just took away everything that was enjoyable. Instead of solving puzzles I'm wrangling a digital junior dev that doesn't really learn from its mistakes, and lies all the time. Claude very much learns if you teach it and tell it to note things in the CLAUDE.md files you want it to remember. Claude is much better than any junior and most mid level ticket takers.
- nly 7mo ago
  > Your company isn’t paying you to solve puzzles. Actually they are, but it's also true that you need to put solutions in to production.
  - raw_anon_1111 7mo ago
    No your company is very much paying you to put things in production. Thats all they care about
    - bayindirh 7mo ago
      No the company wants its problems to be solved and needs to be addressed. When things are put to production as soon as possible without respect to quality, we see what's happening all the time. Bloat, performance problems, angry customers, Windows 11... You get the idea.
      - raw_anon_1111 7mo ago
        The reason your login is taking 45 seconds and your database is locking up with 10 concurrent users isn’t because developers didn’t write good code following the correct GOF pattern. If companies cared about bloat and performance you wouldn’t see web apps with dozens of dependencies, cross platform mobile apps and Electron apps.
    - nly 7mo ago
93n 7mo ago
> The fun part is in the building, it's in the understanding, the growth of me. I agree with this sentiment as well. Without a doubt, my favorite part of the job is coming up with a solution that just 'feels right', especially when said solution is much cleaner than brute force/naive approach. It sounds cheesy, but it truly is one of my favorite sensations. I'm the senior-most engineer on my team of about 15. I try to emphasize software craftsmanship, which resonates with some but not all. We have a few engineers who have seemingly become reliant on AI tooling, and I struggle with them. Some of them are trying to push code that they clearly don't understand and aren't reviewing, and I think they're setting themselves up for failure due to lack of growth.
markus_zhang 7mo ago
From my understanding, you can instead use Claude in the following manner: understand and solve the problem, put up pseudo code, and then tell Claude to generate real code and maybe restructure it a bit. So you don't have to write the actual code but have solved the problem all by yourself.
- fastasucan 7mo ago
  "So you dont have to" - I suspect the person you are replying to likes to write code.
  - markus_zhang 7mo ago
    > This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. I don't really see where he/she said that explicitly. My understanding is that he likes to solve problems but don't care about the final implementation. But I stand corrected.
  - parpfish 7mo ago
    If you worked in an office and your boss asked for 100 copies of their memo, they want you to use the copy machine. If they saw you typing it out 100 times they’d tell you that you’re wasting time. It does t matter that you like to type and that you went to school to get a degree in typing.
fastasucan 7mo ago
This is me as well. I am actively seeking out a different line of work, because talking to a chat bot gives me 0 joy.
parpfish 7mo ago
I feel like I still get to solve the puzzles I like because I like the higher level architecture/design parts. I just don’t have to type as much because I can provide a stubbed out solution and tell it to fill I the rest.
aaron695 7mo ago
[dead]
leekrasnow 7mo ago
Adapting the workflow to this new paradigm is a different sort of puzzle. I think that the folks whom enjoy agentic pair programming have found various satisfactory solutions. As a puzzle enthusiast myself, I have been particularly enjoying this pivotal moment in technology because of how many opportunities there are to create novel approaches to combat the lies and mistakes.

by donatj 7mo ago

jebarker 7mo ago

I agree with you. I try to remember though that this is just the same situation that artists, musicians and (more recently) writers have been in for a long time. Unless you’re one of a very lucky few you’ll only get fulfillment in those pursuits if you enjoy the process rather than the output since it’s hard to get money or recognition for output anymore. Pure coding and lots of areas of code problem solving are going to end up in the same position.

mike_slinn 7mo ago

"wrangling a digital junior dev that doesn't really learn from its mistakes, and lies all the time" SO TRUE!

sixtyj 7mo ago
This dev thinks that it knows everything /s

specproc 7mo ago

One hundred percent. I came back into tech professionally over the last decade. Always been into computers, but the first decade or so of my career was in humanitarian amin. Super interesting sector, super boring day-to-day. Getting back into code felt like coming home. I'm good at it, I really enjoy it, the problem-solving aspect totally lights up my brain in this amazing way. I feel exactly the same way. Totally robbed of pleasure at work, with the added kicker of mass layoffs hanging over the sector. At least OP is sixty, I've got 25 years of work left and I really don't know what to do. I hate it all so much.

throw310822 7mo ago

Oh wow, that's exactly the opposite of how I feel, and conversely, I am that developer who gets itchy when his work doesn't go to prod quickly enough and gets defensive on code reviews. Sure, part of the fun of programming is understanding how things work, mentally taking them apart and rebuilding them in the particular way that meets your needs. But this is usually reserved for small parts of the code, self-contained libraries or architectural backbones. And at that level I think human input and direction are still important. Then there is the grunt work of glueing all the parts together, or writing some obvious logic, often for the umpteenth time- these are things I can happily delegate. And finally there are the choices you make because you think of the final product and of the experience of those who will use it- this is not a puzzle to solve at all, this is creative work and there is no predefined result to reach. I'm happy to have tools that allow me to get there faster.

voxleone 7mo ago

I've been coding since I was about 15 and still love it. These days I mostly build tailored applications for small and medium companies, often alone and sometimes with small ad-hoc teams. I also do the sales myself, in person. For me, not using LLMs would mean giving up a lot of productivity. But the way I use them is very structured. Work on an application starts with requirements appraisal: identifying actors, defining use cases, and understanding the business constraints. Then I design the objects and flows. When possible, I formalize the system with fairly strict axioms and constraints. Only after that do LLMs come in, mostly to help with the mechanical parts of implementation. In my experience it's still humans all the way down. The thinking, modeling, and responsibility for the system are human. The LLM just helps move the implementation faster. I also suspect the segment I work in will be among the last affected by LLM-driven job displacement. My clients are small to medium companies that need tailored internal systems. They're not going to suddenly start vibe-coding their own software. What they actually need is someone to understand the business, define the model, and take responsibility for the system. LLMs help with the implementation, but that part was never the hard part of the job.

jantb 7mo ago
I’m doing the same as you and even though I was producing coding a lot of the actual products I estimated the coding part just to be about 20% of the work. The rest is figuring out what and how to build stuff and what stakeholders really need, and solving production issues in live event driven systems. Agentic coding is just faster at the 20% part, and I can always sit down and code the really hard stuff if I want to or feel I need to if the LLM gets stuck. If it produces something not understandable I either learn from it until I understand it og makes it do a pattern I know instead. So all in all, not so worried.

finaard 7mo ago

> This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. The fun part is in the building, it's in the understanding, the growth of me. Quite a few of the projects I always wanted to do have components or dependencies I really don't want to do. And as a result, I never did them, unless they eventually became viable to do in a commercial setting where I then had some junior developer to make the annoying stuff go away. Now with LLMs I have my own junior developer to handle the annoying stuff - and as a result, a lot of my fun stuff I was thinking about in the last 3 decades finally got done. One example from just last week - I had a large C codebase from the 90s I always wanted to reuse, but modern compilers have a different idea of how C should look like. It's pretty obvious from the compiler errors what you need to do each case, but I wasn't really in the mood for manually going through hundreds of source files. So I just stuck a locally running qwen coder in yolo mode into a container, forgot about it for a week, and came back to a compiling code base. Diff is quick to review, only had a handful of cases where it needed manual intervention.

throw-the-towel 7mo ago
Note that you are able to choose freely what parts of the work get done by Claude, and what parts you do yourself. At work, many of us have no such luxury because bosses drunk on FOMO are forcing agent use.
- finaard 7mo ago
  Yeah, I've noticed at several customers that they're just trying to cram LLMs into everything, instead of maybe first thinking if it's sensible for that specific usecase. I'm also doing some things where I don't think LLMs are not a good fit - but I'm doing it because I care to see about things like failure behaviour, how to identify when it is looping (which can be sometimes hard to see when using huge context models) and similar stuff - which results in more knowledge about when it makes sense to use LLMS. No such learnings visible at many customers, even if LLMs do something stupid.

sktrdie 7mo ago

You still care about end result though: in your case, the end result being the puzzled you solved. AI can make that process still enjoyable. For instance I had to build a very intricate cache handler for Next.js from scratch that worked in a very specific way by serializing JSON in chunks (instead of JSON.parse it all in memory). I knew the theory, but the API details and the other annoyances always made it daunting for me. With AI I was able to thinker more about the theory of the problem and less about the technical implementation which made the process much more fun and doable. Perhaps we're just climbing the ladder of abstraction: in the early days people were building their own garbage collection mechanisms, their own binary search algorithms, etc. Once we started using libraries, we had to find the fun in some higher level. Perhaps in the future the fun will be about solving puzzles within the realm of requirement definitions and all the intricacies that stem from that.

raw_anon_1111 7mo ago

Your company isn’t paying you to solve puzzles. If you aren’t putting things into production, what good are you as an employee? > Being forced to use Claude at work, it really just took away everything that was enjoyable. Instead of solving puzzles I'm wrangling a digital junior dev that doesn't really learn from its mistakes, and lies all the time. Claude very much learns if you teach it and tell it to note things in the CLAUDE.md files you want it to remember. Claude is much better than any junior and most mid level ticket takers.

nly 7mo ago
> Your company isn’t paying you to solve puzzles. Actually they are, but it's also true that you need to put solutions in to production.
- raw_anon_1111 7mo ago
  No your company is very much paying you to put things in production. Thats all they care about
  - bayindirh 7mo ago
    No the company wants its problems to be solved and needs to be addressed. When things are put to production as soon as possible without respect to quality, we see what's happening all the time. Bloat, performance problems, angry customers, Windows 11... You get the idea.
    - raw_anon_1111 7mo ago
      The reason your login is taking 45 seconds and your database is locking up with 10 concurrent users isn’t because developers didn’t write good code following the correct GOF pattern. If companies cared about bloat and performance you wouldn’t see web apps with dozens of dependencies, cross platform mobile apps and Electron apps.
  - nly 7mo ago

93n 7mo ago

> The fun part is in the building, it's in the understanding, the growth of me. I agree with this sentiment as well. Without a doubt, my favorite part of the job is coming up with a solution that just 'feels right', especially when said solution is much cleaner than brute force/naive approach. It sounds cheesy, but it truly is one of my favorite sensations. I'm the senior-most engineer on my team of about 15. I try to emphasize software craftsmanship, which resonates with some but not all. We have a few engineers who have seemingly become reliant on AI tooling, and I struggle with them. Some of them are trying to push code that they clearly don't understand and aren't reviewing, and I think they're setting themselves up for failure due to lack of growth.

markus_zhang 7mo ago

From my understanding, you can instead use Claude in the following manner: understand and solve the problem, put up pseudo code, and then tell Claude to generate real code and maybe restructure it a bit. So you don't have to write the actual code but have solved the problem all by yourself.

fastasucan 7mo ago
"So you dont have to" - I suspect the person you are replying to likes to write code.
- markus_zhang 7mo ago
  > This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. I don't really see where he/she said that explicitly. My understanding is that he likes to solve problems but don't care about the final implementation. But I stand corrected.
- parpfish 7mo ago
  If you worked in an office and your boss asked for 100 copies of their memo, they want you to use the copy machine. If they saw you typing it out 100 times they’d tell you that you’re wasting time. It does t matter that you like to type and that you went to school to get a degree in typing.

fastasucan 7mo ago

This is me as well. I am actively seeking out a different line of work, because talking to a chat bot gives me 0 joy.

parpfish 7mo ago

I feel like I still get to solve the puzzles I like because I like the higher level architecture/design parts. I just don’t have to type as much because I can provide a stubbed out solution and tell it to fill I the rest.

aaron695 7mo ago

[dead]

leekrasnow 7mo ago

Adapting the workflow to this new paradigm is a different sort of puzzle. I think that the folks whom enjoy agentic pair programming have found various satisfactory solutions. As a puzzle enthusiast myself, I have been particularly enjoying this pivotal moment in technology because of how many opportunities there are to create novel approaches to combat the lies and mistakes.