3 ms·
I disagree on making it easier. I'm very capable of writing code in multiple languages but it's boring and monotonous. It's getting in the way of me building th
by RevEng 7mo ago
I disagree on making it easier. I'm very capable of writing code in multiple languages but it's boring and monotonous. It's getting in the way of me building the system I have in mind. I prefer the engineering (design) to writing. If I can describe my system design to something (a junior developer or an AI) and see it come to life quickly, that's great; it lets me spend more time on designing the system, or perhaps designing more systems.
That said, there are plenty of amateurs who find coding to be approachable and system design to me daunting. For them, eliminating coding and moving the focus to system design would be a nightmare.
- _zagj 7mo agoTo be frank, this just sounds like self-serving BS, likely from someone who's only ever done front-end stuff and hasn't ever cracked open Godbolt (or doesn't even know what that is). Describing system constraints at a high-level, whether to an AI prompt or subordinate devs, and letting them figure out the details is much more akin to system architecture than actual engineering.
- RevEng 7mo agoFor what it's worth, I'm a principal engineer. I've been building software professionally for 18 years. I've done very little front end work; I appreciate it but I'm not good at it. My work has mostly been with databases, cluster management systems, machine learning models, parsers and generators, network file systems, and a bunch of other back and work, tying that all together into applications used in custom integrated circuit design. I've never heard of Godbolt before but I have written assembly for x86, AVR and PIC. I've optimized PTX based on analyzing the SASS assembly instructions for building GPU-accelerated linear system solvers. System architecture is part of engineering. It's literally part of the design documents we had to produce in my engineering capstone project. Engineering is about choosing among a bunch of alternatives to meet the intended goal. That requires understanding the problem that's to be solved, details of all the alternatives and their trade-offs, and how those alternatives would be implemented into a solution. You apply the same engineering principals at the system architecture level, module level, function level, and even each line of code. I work with some very capable developers. I can discuss with them and come up with a plan at a system or module level and trust them to make their own design decisions. We can discuss them ahead of time if I think it might be too much for them. I can review their work and iterate with them if I have concerns. These are all things I can do with modern AI tools. If that's self-serving, so be it, but me and fellow engineers of all different levels of experience are seeing benefits from using AI at times where it makes sense for us. This hasn't cost us our jobs - we are hiring madly - but it has helped us to learn things and build things faster. It's another tool in the toolbox. Use it when it suits you.