> Your company isn’t paying you to solve puzzles. If you aren’t putting things into production, what good are you as an employee?
No, the company is exactly paying their employees to solve puzzles, which company labels them as problems or requirements.
And when an employee focuses on solving puzzles and enjoys it, the code naturally ends up in production, and gets forgotten because the puzzle is solved well.
I care about exchanging labor for money to support my addiction to food and shelter.
My employer just like any other employer cares about keeping up with the competition and maximizing profit.
Customers don’t care about the “craftsmanship” of your code - aside from maybe the UI. But if you are a B2B company where the user is not the customer, they probably don’t even care about that.
I bet you most developers here are using the same set of Electron apps.
Now I work in consulting AWS + app dev as a staff consultant leading ironed and unless you work in the internal consulting department at AWS (been there done that as blue badge RSU earning employee) or GCP, it’s almost impossible to get a job as an American as anything but sales or a lead. It’s a race to the bottom with everyone hiring in LatAm if you are lucky (same time zone more willing to push back against bad idea and more able to handle ambiguity) or India.
Everything is a race to the bottom. The only way I can justify not being in presales is because I can now do the work of 3 people with AI.
There still is. In most enterprises, the tasks are usually to take some data somewhere, transform it to be the intake of another process. Or to made a tweak to an existing process. Most of the other types of problems (information storage, communication, accounting,..) have been solved already (and solved before the digital world).
People can see it as grind. But the pleasure comes in solving the meta problem instead of the one in front (the latter always create brittle systems). But I agree that it can becomes hell if there were no care in building the current systems.
And they are tasks with standardized best practices. I knew that I wanted to write an internal web app that allowed users to upload a file to S3 using Lambda and storing the CSV rows into Postgres.
I just told it to do it.
It got the “create S3 pre-signed url to upload it to” right. But then it did the naive implementation of download the file and do a bulk upsetting wrong instead of “use the AWS extension to Postgres and upload it to S3”. Once I told it to do that, it knew what to do.
But still I cared about systems and architecture and not whether it decided to use a for loop or while loop.
Knowing that or knowing how best to upload files to Redshift or other data engineering practices aren’t knew or novel
They aren’t. But there are a lot of mistakes that can happen, and until an AI workflow is proven that it can’t happen, it’s best to monitor it, and then the speed increase is moot. Hunans can make the same kind of mistakes, but they are incentivized not to (loosing reputation and their jobs). AI tools don’t have that lever against them.
And so are mid level developers. A mid level developer who didn’t have 8 years of experience with AWS would have made the same mistake without my advice.
I would have been just as responsible for their inefficient implementation in front of the customer (consulting) as I would be with Claude and it would have been on me to guide the mid level developer just like it was on me to guide Claude.
The mid level developer would never have been called out for it in front of my customer (consulting) or in front of my CTO when I was working for a product company. Either way I was the responsible individual
No, the company is exactly paying their employees to solve puzzles, which company labels them as problems or requirements.
And when an employee focuses on solving puzzles and enjoys it, the code naturally ends up in production, and gets forgotten because the puzzle is solved well.