51–60 of 108 posts
I'm a DevOps engineer. I'm training someone new to the field. Often I'll ask the AI to do something and it goes sideways. Sometimes it really saves me time, but many times not. I'll break down and actually type out commands or even Google what to do instead of using the AI because it's still faster. It's true that my trainee uses the AI more because there's fewer commands in his muscle memory. But, it's still not gre…
I'm a DevOps engineer. I'm training someone new to the field. Often I'll ask the AI to do something and it goes sideways. Sometimes it really saves me time, but many times not. I'll break down and actually type out commands or even Google what to do instead of using the AI because it's still faster. It's true that my trainee uses the AI more because there's fewer commands in his muscle memory. But, it's still not gre…
Or turn it over and fix a broken belt.
> There is a popular argument that a software developer’s job is not write software but to solve a user’s problem. Bullshit Wait, what? > I was never particularly interested in the code itself > Instead, I was always more interested in the product Confusing contradictions aside, I had trouble engaging with this article. The author seems to think every developer thinks like they do. Some people actually enjoy helping…
While I agree with most of what the author says, this article does exude "Suno CEO says people don't enjoy making music" energy.
> There is a popular argument that a software developer’s job is not write software but to solve a user’s problem. Bullshit Wait, what? > I was never particularly interested in the code itself > Instead, I was always more interested in the product Confusing contradictions aside, I had trouble engaging with this article. The author seems to think every developer thinks like they do. Some people actually enjoy helping…
However, at my current job & role, my manager has left (or taken quite long leave) 2nd time now. Although both me and my team are assigned to another manager in different region (BigTech), it is not the same thing...
Why I mention this: I am gonna avoid doing any and all managerial work. Because last time, I did a lot of managerial work without the benefits. Both in terms of reporting, keeping the team morale (happiness) up, keeping our interest above from a lot of inter-team fighting/prioritization, etc.
In turn, I got no appreciation or compensation out of it. Even I partially did the jobs of other people (collecting artifacts, reporting up to the chain, etc.) So, nobody would get any _bad_ performance review. (Or worse, lay-offs...)
But I agree with the author, I got no dopamine out of these. Yes I was solving some problems, but they were like package conflicts of NPM peer dependencies. Provided no value to me, no improvement for my own performance, and worse, no goal or direction at all!
PS: My team is a completely DevOps team, in Big-Tech terms, support team. What we do is the grunt-work of various other teams to keep them up-to-date, which is why, overall job satisfaction is quite below of the average...
Now, I am refusing to do the same work again. My manager is in parental leave since mid-June. He has _not_ been doing good job in terms of job-satisfaction and team morale since he has joined. I slowly degraded doing the low-key managerial job, and he has not been taking over. With the long-leave in process, I just stopped taking care of it.
Since I stopped doing the managerial grunt-work, 2 people already left from the team of, well, 8 engineers.
Since I am also taking over the work that has been done by the other engineers, I noticed couple of things: 1. The code quality is somewhat okay, but there are obvious "useless" AI generated areas. Similarly, commit messages yield little to no value, as the review process were only within the people who worked within the project. (ie, Several "fix bugs" commits back to back, yields no value) 3. People who left or stayed, has no recollection of the things I helped them with, problems I solved (ie, unblocking those stuck) and no appreciation for the "space" I was able to get to them. (Even though I was quite explicit with each person. 4. I am one of those special engineers where you can put me in any domain/language whatsoever and I will do a good/decent job at it. (jack of all trades, swiss-army-knife, whatever you call it.) I also solve the issues as I go through with some bug-fixes, features, whatnot. 5. Product/project manager actively sabotages these tech-debt fixes, or the "refactor" of the "AI-generated" code to be a simpler, more-readable versions.
Which is why, unlike the CTO in question of the article, I started caring less and less about these. Now, I also produce code with AI-agents, as the leadership loves the AI-slop metrics.
At some point, these AI-generated code will fail to do something. We'll need to fix that, or replace that. This boils down to 2 different scenarios: 1. If this code is running an airplane, then it is a disaster. Maybe your engines will fail, you must crash-land somewhere at best. 2. If this code is running a rocket, then it already has a limited time anyway. Does not matter if has a memory leak at all. The lifetime is already so limited that the rocket will not even reach to the resource limits being hit.
I guess most of the leadership is currently betting on most problems being #2. Because software engineering going quite fast, rewrites are always at the next corner, what is the point of "maintaining" the codebase?
Meanwhile, I am not sure I will be there to solve more of an airplane problem when it occurs. I just wish best of luck with the AI-agents to the leaders who have just attached pair or rocket-boosters instead of actual jet-engines to an airliner!
However, at my current job & role, my manager has left (or taken quite long leave) 2nd time now. Although both me and my team are assigned to another manager in different region (BigTech), it is not the same thing...
Why I mention this: I am gonna avoid doing any and all managerial work. Because last time, I did a lot of managerial work without the benefits. Both in terms of reporting, keeping the team morale (happiness) up, keeping our interest above from a lot of inter-team fighting/prioritization, etc.
In turn, I got no appreciation or compensation out of it. Even I partially did the jobs of other people (collecting artifacts, reporting up to the chain, etc.) So, nobody would get any _bad_ performance review. (Or worse, lay-offs...)
But I agree with the author, I got no dopamine out of these. Yes I was solving some problems, but they were like package conflicts of NPM peer dependencies. Provided no value to me, no improvement for my own performance, and worse, no goal or direction at all!
PS: My team is a completely DevOps team, in Big-Tech terms, support team. What we do is the grunt-work of various other teams to keep them up-to-date, which is why, overall job satisfaction is quite below of the average...
Now, I am refusing to do the same work again. My manager is in parental leave since mid-June. He has _not_ been doing good job in terms of job-satisfaction and team morale since he has joined. I slowly degraded doing the low-key managerial job, and he has not been taking over. With the long-leave in process, I just stopped taking care of it.
Since I stopped doing the managerial grunt-work, 2 people already left from the team of, well, 8 engineers.
Since I am also taking over the work that has been done by the other engineers, I noticed couple of things: 1. The code quality is somewhat okay, but there are obvious "useless" AI generated areas. Similarly, commit messages yield little to no value, as the review process were only within the people who worked within the project. (ie, Several "fix bugs" commits back to back, yields no value) 3. People who left or stayed, has no recollection of the things I helped them with, problems I solved (ie, unblocking those stuck) and no appreciation for the "space" I was able to get to them. (Even though I was quite explicit with each person. 4. I am one of those special engineers where you can put me in any domain/language whatsoever and I will do a good/decent job at it. (jack of all trades, Swiss-army-knife, whatever you call it.) I also solve the issues as I go through with some bug-fixes, features, whatnot. 5. Product/project manager actively sabotages these tech-debt fixes, or the "refactor" of the "AI-generated" code to be a simpler, more-readable versions.
Which is why, unlike the CTO in question of the article, I started caring less and less about these. Now, I also produce code with AI-agents, as the leadership loves the AI-slop metrics.
At some point, these AI-generated code will fail to do something. We'll need to fix that, or replace that. This boils down to 2 different scenarios: 1. If this code is running an airplane, then it is a disaster. Maybe your engines will fail, you must crash-land somewhere at best. 2. If this code is running a rocket, then it already has a limited time anyway. Does not matter if has a memory leak at all. The lifetime is already so limited that the rocket will not even reach to the resource limits being hit.
I guess most of the leadership is currently betting on most problems being #2. Because software engineering going quite fast, rewrites are always at the next corner, what is the point of "maintaining" the codebase?
Meanwhile, I am not sure I will be there to solve more of an airplane problem when it occurs. I just wish best of luck with the AI-agents to the leaders who have just attached pair or rocket-boosters instead of actual jet-engines to an airliner!
>And with those new skills, your old skills will start to atrophy. Skills don't work like muscles, please stop with this thinking model of the world. No one is going to fire you because you don't have the same speed of recall of language constructs and have to look more things up. Speed of coding is not the damn bottleneck. Plus have a little faith in your brain that you could get back to that point if you wanted to.
What you say would only be true in an anarchist island colony devoted to software craftsmanship where everyone is healthy and under 40 years old.
> There is a popular argument that a software developer’s job is not write software but to solve a user’s problem. Bullshit Wait, what? > I was never particularly interested in the code itself > Instead, I was always more interested in the product Confusing contradictions aside, I had trouble engaging with this article. The author seems to think every developer thinks like they do. Some people actually enjoy helping…
Beyond that - doing coding without solving problems or enabling anyone/anything is just doing art for art's sake. It may have a place, but its more personal, a hobby, an expression than anything tangible to be used in the real world - leaving aside business.
Earlier quoted context omitted.
> Think of all the studying that is required before applying to tech jobs these days. Surely you realize this is the problem. I just landed a mid 6-figures job _without_ grinding leetcode. They’re out there. This game everyone plays is an abomination.
Surely you don't believe that there's a significant fraction of tech jobs that pay $500k?
> There is a popular argument that a software developer’s job is not write software but to solve a user’s problem. Bullshit Wait, what? > I was never particularly interested in the code itself > Instead, I was always more interested in the product Confusing contradictions aside, I had trouble engaging with this article. The author seems to think every developer thinks like they do. Some people actually enjoy helping…
Product is not the same as code. We code to build a product, sure, but I think the author means they are interested in designing the product to solve users problems (a.k.a UX)