| ▲ | questionableans 5 hours ago |
| I’m curious, what are some examples of XYZ? What does “mostly technical” mean to you, and why do you think it is the industry doesn’t want that? Just trying to understand, because I don’t think I’ve experienced this myself. |
|
| ▲ | proc0 5 hours ago | parent | next [-] |
| I'm talking about the day to day work. At least in my experience at several big tech companies, the more senior an engineer is, the more you need to delegate work and are expect to lead projects by managing them. There's technical knowledge involved of course but it's a small part of it, mostly directing other more junior engineers. AI allows you to move faster, but it also demands that you pay more attention in proportion to how fast you want to move. This requires more focus, i.e. more time developing. Effectively the structure at companies should swing back to how it used to be a few decades ago (I think, maybe I'm wrong and it's always been like this), where engineers mostly focused on delivering code. The difference now is that they can be expected to deliver much more code at higher quality. To summarize, using a little AI doesn't pay off, you need to be doing that all day, and that is not how engineers spend their time in most of the industry anymore. |
| |
| ▲ | questionableans 2 hours ago | parent [-] | | Thanks for clarifying. There have always been technical leads and hands-on engineering managers, but two things have changed:
1. The balance of responsibilities attributed to different titles has varied over time and across different companies.
2. Early personal computers were so resource limited that there were only so many programs you could write that actually made effective use of large teams. Today we can write much larger programs, which requires more coordination (across people and with AI—which can reduce the number of people required). I would also strongly push back on the assertions that being very technical means spending most of your time on the code, and that you have to be using AI all day for it to be useful. Let’s say I’m a technical lead or a manager reviewing a design doc for a large project. I have an idea based on my years of technical involvement for how to significantly improve the quality or delivery timeline for the project. I used to have to ask the doc author to look into this approach, not knowing for sure if it would directly translate. Now I can take my crazy idea, quickly dispatch a coding agent to try it out against the codebase, go to a meeting, and then check on what it came up with to give a much more informed and technically accurate suggestion on the doc. I still have to have the technical expertise to iterate a bit with the agent and not over or under state the possible impact of my idea. But this lets me take say an hour rather than a week to come up with a vetted recommendation that saves months on the schedule. | | |
| ▲ | proc0 an hour ago | parent | next [-] | | I'm just speculating why the current structure of companies is not maximizing what AI can offer. Until it becomes completely self-directed and reliable, using a tool that allows you to move fast requires more technical knowledge, not less. What you're missing from your example is releasing to production without breaking it, dealing with increasing complexity as more features are added, maintaining development pace as more features are added, and trying not to create more bugs than are fixed. The idea is more or less benefiting from doing work in bulk which AI is now allowing. I even think multiple engineers (human redundancy to double check the same code) should team up with one AI system and form a small team that handles millions of lines of code, with the only job to feed incoming tickets and check the AI work. Anyone not reviewing code should be facilitating everything else with their own AIs. I think large companies can collapse entire engineering departments into a few people. The cost would be that everyone else has to think like an engineer to sort out requirements and provide direction, but as you point out, this is now easier with the help of AI. | | |
| ▲ | questionableans 41 minutes ago | parent [-] | | IMO, a large amount of work, including a large amount of technical work is wasted effort. At startups you see it when they go out of business, at a big companies you see it as bloat. So unless AI is directed at finding the right problems to solve, past some point engineering efficiency via AI at best saves some money and at worst means more ultimately low, zero or negative value work gets done. Maybe this is why you’re seeing more effort shifted away from technical work. Maybe I’m a nihilist. Maybe both? | | |
| ▲ | proc0 25 minutes ago | parent [-] | | That was true when implementation was expensive. Now that implementation is cheap, doing it in bulk is the best way to maximize AI usage, and that means fewer engineers doing more of the technical work. > unless AI is directed at finding the right problems to solve This direction can be done by non-engineers with AI to consult (replacing that part of human engineer's role). | | |
| ▲ | questionableans 20 minutes ago | parent [-] | | My guess is in the end we’ll find the approach that works depends more on the personalities of the people involved as opposed to one approach being strictly better. |
|
|
| |
| ▲ | questionableans 2 hours ago | parent | prev [-] | | Actually, there is one other important thing that has changed: as developing a certain amount of functionality has gotten easier with modern languages, tools, libraries and coding agents, it’s also gotten less interesting for technology-driven people and more accessible to career-driven people. Implementing the first text edit field in your program is kind of interesting when all you have is asm and 4k of RAM. Nobody wants to bother doing it manually when you have a web browser that can eat gigs of RAM. |
|
|
|
| ▲ | eddythompson80 3 hours ago | parent | prev [-] |
| This has been happening before AI, but AI has turned it up to 11. The way I usually put it, senior engineers are the new engineering manager, engineering managers are the new product managers, and product managers are now something in between sales, consultants or social media contacts. AI made senior engineers pick up more product management from their engineering managers, and engineering managers are picking up more sales and social engagement, and product managers are in a limbo but the young ones are pushed to junior engineer roles. In large companies there is also the politics game. The more freed time senior engineering manager and senior product managers get, the more politics intensives and waste more of their time. I use the term “product management” in its traditional sense of establishing scope, feature prioritization, user experience, shape of integrations, etc. |
| |
| ▲ | questionableans 2 hours ago | parent [-] | | I’ve worked most of my career without dedicated product management support (very early startups and internal infrastructure teams at large companies), having to do that myself (both as an individual contributor engineer and as a very technical manager). So I have to wonder how much has the industry changed, and how much has your location within the industry drifted? | | |
| ▲ | eddythompson80 2 hours ago | parent [-] | | Yes my view mostly from within large engineering organizations. And yes, what you describe is pretty typical for engineers (and especially founding engineers) in young startups. Doubly so if it’s a startup with a technical product. Large organizations always envied startups’ efficiency and pace because of that, which is why the traditional sense of product management has been handed to engineering teams. This has been happening in the enterprise side for a long over the last 15 years and predates AI as I mentioned. It’s just more collapsing of disciplines now which is the answer I was giving to OP’s question. |
|
|