91–100 of 206 posts
Can't you continue to do what you've been doing? What specifically about the existence of AI is killing the passion out of curiosity?
Earlier quoted context omitted.
PMs now expect that you can create a Java micro service that does basic REST/CRUD from a database and get it into production in a total of two days. That is hard if you are working in Notepad and have to write your own class import statements and write your own Maven POM or Gradle file. It’s a lot quicker in an IDE with autocomplete and auto-generated Maven POMs. And with AI it’s even faster but at the risk of lower…
> PMs now expect that you can create a Java micro service that does basic REST/CRUD from a database and get it into production in a total of two days. Have you heard of malicious compliance? Give the PMs what they ask for, then show them how what they've asked for is flawed. Your job as an engineer is not to just take orders blindly, it's to push for a better engineered solution. It's really not hard to show that wha…
> 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…
> 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.
I'm not sure I understand... why not simply ignore AI and keep coding the way you always have? It's a bit like saying motorboats killed your passion for rowing.
This is a real thing that happens and the analogy is clearly working against you! If you paddle a canoe or rowboat on a river or lake, your experience is made MARKEDLY worse by a motorboat zooming by and scaring the fish, rocking you with wake, smelling up the place with 2-stroke fumes, etc. Even when the motorboats aren't there, the built environment that supports them is bigger and more intrusive.
I found my peace with AI aided coding during the last three months. I started development of an environment for programming games and agent simulations that has its own S-expression based DSL, as a private project. Think somewhere between Processing and StarLogo, with a functional style and a unique programming model. I am having long design sessions with Claude Code and let it implement the resulting features and ch…
- Split up the work so that you write the high-level client code, and have AI write the library/framework code.
- Write some parts of your (client) code first.
- Write a first iteration of the library/framework so that your code runs, along with tests and documentation. This gives the AI information on the desired implementation style.
- Spend time designing/defining the interface (API, DSL or some other module boundary). Discuss the design with the AI and iterate until it feels good.
- For each design increment, let AI implement, test and document its part, then adapt your client code. Or, change your code first and have AI change its interface/implementation to make it work.
- Between iterations, study at least the generated tests, and discuss the implementation.
- Keep iterations small and commit completed features before you advance to the next change.
- Keep a TODO list and don't be afraid to dismiss an earlier design if it is no longer consistent with newer decisions. (This is a variation of the one-off program, but as a design tool.)
That way, there is a clear separation of the client code and the libraries/framework layer, and you own the former and the interface to the latter, just not the low-level implementation (which is true for all 3rd party code, or all code you did not write).
Of course this will not work for you if what you prefer is writing low-level code. But in a business context, where you have the detailed domain knowledge and communicate with the product department, it is a sensible division of labour. (And you keep designing the interface to the low-level code.)
At least for me this workflow works, as I like spending time on getting the design and the boundaries right, as it results in readable and intentional (sometimes even beautiful) client code. It also keeps the creative element in the process and does not reduce the engineer to a mere manager of AI coding agents.
I'm not sure I understand... why not simply ignore AI and keep coding the way you always have? It's a bit like saying motorboats killed your passion for rowing.
He's not getting customers by rowing them across the river when the motorboats do it faster and cheaper. You compared a hobby to doing something "for a living". I turned 59 this week. I am excited to go to work again. I use Claude every day. I check Claude. I learn new things from Claude. I no longer need a "UI person" to get something demonstrable quickly. (I've never been a "UI guy"). I've also never been a guy cod…
I got into “cloud” at 44, got my first job (and hopefully last) at BigTech at 46 and now I work in cloud consulting specializing in app dev leading projects at 51.
Every project I’ve done since late 2023 has involved integrating with LLMs and I usually have three terminal sessions up - one with Claude, one with Codex and one where I do command line stuff and testing.
I am motivated by the result, the design and on the system level.
> 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…
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 i…
Actually they are, but it's also true that you need to put solutions in to production.
Earlier quoted context omitted.
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 i…
> 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.