Journeyman, perhaps? I duno.
I want to be a Journey Programmer Again
11–20 of 79 posts
Re: I want to be a Journey Programmer Again
#12LLMs offered a much needed contrast that allowed me to understand the true value of what I do. Before LLMs I took it for granted
This is well put and something I have tried to express to people.
Long before LLMs came onto the scene, I was telling people (like friends and family trying to understand what I do at work) that the actual coding part of the job is the least valuable, but that you just do still have to be able to write the code once you do the more valuable work of figuring out what to write.
But LLMs have made that distinction far more clear than I ever imagined. And I have found that for all my previous talk about it, I clearly still felt that the "writing the code" part was an important portion of my contribution, and have found it jarring to rebalance my conception of where I can contribute value.
Re: I want to be a Journey Programmer Again
#13Journeyman, perhaps? I duno.
No, they do mean "journey programmer".
> I think the cliche saying that the "journey is better than the destination" serves as a good framework to model this issue. Fundamentally, programmers (or individual programming projects) can be put into two categories: destination programmers and journey programmers.
Re: I want to be a Journey Programmer Again
#14Let me share a problem I solved recently (well, a year ago god I'm getting old)! I had to write this template loader for my space sim... reference resolution, type mapping, and YAML parsing. This isn't the code I wanted to write. The code I wanted to write was behavior trees for AI traders, I'm playing with an idea where successful traders can combine behavior trees yada yada, fun side project. But before I could tou…
> OP treats all implementation details as equally valuable parts of "the journey,"
Do they? That wasn’t my take away from the article.
My impression was that the author missed the enjoyment of problem solving because they overused AI. Not that they think all problems are equal.
For what it’s worth though, I do agree with your more general point about AI use. And in fact that’s how I’ve used AI code generation too. “Solve the tedious problem quickly so you can focus on the interesting one”.
Re: I want to be a Journey Programmer Again
#15Feels like we're heading towards a world where computer languages disappear, and we just use human language to tell machines what to do. Kinda like how typewriters got replaced by computers in the 80s. Back then, people spent so much time making sure there were no typos, they'd lose focus on the actual story they were trying to write. Same thing's happening now with code. We waste so much time dealing with syntax, fi…
Perhaps solving the real problem implies using programming languages?
Or perhaps it doesn't. An architect also solves a real problem, even though he's not laying brick.
Re: I want to be a Journey Programmer Again
#16The solution to this, imo, is to expand the definition of what it means to "program". I'm increasingly realizing that AI tools are the new programming substrate. I've been able to heavily automate workflows and I use the word workflows loosely here.
It's allowed me tackle other parts of the knowledge stack that I would otherwise have no time for. For example, learning more about product management, marketing, and doing deeper research into business ideas. The programming has now gone strictly from coding to automating the flows related to these other jobs. In that sense, I'm still "programming", it just looks different and doesn't always involve an IDE. Bonus is my leverage has dramatically increased.
Re: I want to be a Journey Programmer Again
#17Fred Brooks observed it in 75
As software engineers, we work with “pure thought-stuff”. We build puzzle like objects. It’s satisfying to make useful tools. It’s an ever-renewing stimulating task.
Re: I want to be a Journey Programmer Again
#18Feels like we're heading towards a world where computer languages disappear, and we just use human language to tell machines what to do. Kinda like how typewriters got replaced by computers in the 80s. Back then, people spent so much time making sure there were no typos, they'd lose focus on the actual story they were trying to write. Same thing's happening now with code. We waste so much time dealing with syntax, fi…
I reckon that while my programming has become more productive with LLMs, it has at the same time gotten a bit more frustrating and boring.
I think it is difficult to know in advance when the LLM will do a reasonable or good job and when it won't. But I am slowly learning when and how to use the tools while still enjoying using them.
Re: I want to be a Journey Programmer Again
#19Let me share a problem I solved recently (well, a year ago god I'm getting old)! I had to write this template loader for my space sim... reference resolution, type mapping, and YAML parsing. This isn't the code I wanted to write. The code I wanted to write was behavior trees for AI traders, I'm playing with an idea where successful traders can combine behavior trees yada yada, fun side project. But before I could tou…
OP here, I whipped this up in like 10 minutes after modelling the problem from a new perspective (I want to be less of a perfectionist with my blogs) so there are definitely grey areas I didn't consider/cover.
I do think LLMs can be good for certain boilerplate code whilst still allowing you to enjoy the problems you care about, and as far as my binary definitions this is more of a grey area.
I guess for me, this has introduced a slippery slope where if the LLM can also code the "fun" stuff, I'll be more inclined to use it, which defeats the whole purpose for me. Perhaps being able to identify which type of project I am working on, it can help me avoid using LLMs to enjoy programming more again!
Re: I want to be a Journey Programmer Again
#20The solution to this, imo, is to expand the definition of what it means to "program". I'm increasingly realizing that AI tools are the new programming substrate. I've been able to heavily automate workflows and I use the word workflows loosely here. It's allowed me tackle other parts of the knowledge stack that I would otherwise have no time for. For example, learning more about product management, marketing, and doi…
> I'm increasingly realizing that AI tools are the new programming substrate
Human programming is the old, and new, programming substrate - and the liberal substrate for what AI tools do. They're trained on it.