The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.
Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself.
A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).
Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.
Before LLMs, "organizations" have seen code review as multiple things:
* Share knowledge about a particular area of the codebase between multiple people
* Share overall engineering knowledge between the parties in the review
* Ensure maintainability of the codebase long-term
* Ensure readability of the code
* Catch architectural/directional omissions (yes, from the planning/architecture phase) before it's really too late and non-reversible change goes in (eg. large destructive DB schema change)
* Ensure changes are small, self-contained, and as often as possible, reversible
* Do some basic manual QA
* Do comprehensive integration testing with a fully built-out system
...
* And yes, catch bugs before they hit production.
A lot of the above could be fun and engaging, and especially knowledge sharing and ensuring maintainability/readability was a very motivating thing for me as a more experienced engineer having learned so much from getting good reviews when I was less experienced.
Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).
The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.
Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself.
A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).
> The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.
Yes! That's sooo accurate. Tools you use change, the level of abstraction you operate changes, but the role remains.
Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.
Before LLMs, "organizations" have seen code review as multiple things:
A lot of the above could be fun and engaging, and especially knowledge sharing and ensuring maintainability/readability was a very motivating thing for me as a more experienced engineer having learned so much from getting good reviews when I was less experienced.Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).