4 ms·

I've said "code was always the easy part" recently so I should probably explain where I'm coming from. I think the practice of software engineering includes tha

I've said "code was always the easy part" recently so I should probably explain where I'm coming from. I think the practice of software engineering includes that "understanding of the relationship between code, business, people and teams" you mention, which essentially boils down to the ability to skillfully design a system - regardless of whether it's a big cloud-based web application or a tiny cli tool for use within a team. To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance. Once all that is covered I generally have a good high-level mental map of a system's structure, and actually writing the code to bring those ideas to life truly is the easier part. That being said, I still believe writing good code is a skill that is only learned through experience/the practice of actually writing code. And that experience is necessary for reviewing code - regardless of whether the code you're reviewing was written by humans or AI. Kind of like baking. Putting it in the oven was always the easy part. But combining the right ingredients in the right ratios is necessary, and much more difficult than the putting-it-in-the-oven part. And even then, it takes experience to know when something needs to be pulled early or left in longer. Because ovens are non-deterministic.

timr 2mo ago
> To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance. This is exactly why I became a PM [1]. I wanted to do "harder" things that had bigger scope than I could do as "just an engineer", and the kind of roles that offer that scope within engineering end up being thin on the ground. Unfortunately, what I've generally found is that being a technical PM is a good way to have people try to knife you constantly. Most PMs are technically illiterate MBA types, and carry a deep grudge against anyone who gives the technology any consideration. They're also good at politics, and want you to die. On the other side of the coin, because most PMs are technically illiterate, engineers often instinctively reject you like a tumor. To overcome this, you need to appeal to the technology, which puts more of a target on your back from the other PMs... Anyway, my point is that this is all very sad, because you're describing is exactly what a PM does -- but with technical competence. And because of the way the industry is structured, the people who can do that either get shuffled into people management, or reach a rapid career ceiling when so-called "architecture" roles aren't available. There's this pervasive myth that you cannot be good at technology while also prioritizing the business needs, but usually what this really means is that the "business types" bias in one direction exclusively, and treat the technology as the enemy. It's why so many companies are AI-maxxing now -- the promise of replacing the expensive nerds is the eternal flame for the MBA. [1] well, that, plus after being a founder, people were suddenly willing to hire me to be a PM...
- Terr_ 2mo ago
  "Product Manager, your job is to find the mix of features which is fast and cheap and good, and then browbeat the Engineers into implementing them. Don't just parrot me their excuses, fix it!"
hn_throwaway_99 2mo ago
Sure, I'm not saying design is easy either, but even if you have detailed user requirements, a fully spec'ed out UI, and some general technical requirements, translating that to (working) code is still really, really difficult. I used to do a lot of interviews in my previous career, and I can't tell you the number of times I'd be interviewing someone who could talk a good game, but the second it got to writing code, if the world depended on them being able to write a simple correct loop, we'd all be dead. I know everyone shits on Lee code, and I agree the "brain teaser-y" nature of it doesn't often match real world development, but often times I'd tell folks almost exactly what the code needed to do, in English, and they still couldn't translate that to sensible code. Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part". Well, yeah, sure. But actually writing correct, maintainable, well-structured code is (was?) very much at least one of the hard parts.
- skydhash 2mo ago
  > Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part Compared to the other parts. If you can do the problem solving part and the design part,code is easy. If you can't write code, I strongly doubt your ability to do the first two. People talking good game always try to keep it high level and full of jargon. Once you ask them to explain part of the design, you'll see the inconsistency and holes of what they are saying very easily.
- mrheosuper 2mo ago
  "Talk is cheap, show me the code" - Linus
sgarland 2mo ago
Your analogy to baking makes no sense. At best, compiling would be like putting a cake in the oven. Making the cake is coding. > ovens are non-deterministic Uhhh… no? Modulo calibration drift, they will get to and hold a commanded temperature for as long as you tell them to. The ambient humidity and temperature in your house / bakery may differ - which can absolutely affect some foods - but ovens are pretty binary.

timr 2mo ago

> To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance. This is exactly why I became a PM [1]. I wanted to do "harder" things that had bigger scope than I could do as "just an engineer", and the kind of roles that offer that scope within engineering end up being thin on the ground. Unfortunately, what I've generally found is that being a technical PM is a good way to have people try to knife you constantly. Most PMs are technically illiterate MBA types, and carry a deep grudge against anyone who gives the technology any consideration. They're also good at politics, and want you to die. On the other side of the coin, because most PMs are technically illiterate, engineers often instinctively reject you like a tumor. To overcome this, you need to appeal to the technology, which puts more of a target on your back from the other PMs... Anyway, my point is that this is all very sad, because you're describing is exactly what a PM does -- but with technical competence. And because of the way the industry is structured, the people who can do that either get shuffled into people management, or reach a rapid career ceiling when so-called "architecture" roles aren't available. There's this pervasive myth that you cannot be good at technology while also prioritizing the business needs, but usually what this really means is that the "business types" bias in one direction exclusively, and treat the technology as the enemy. It's why so many companies are AI-maxxing now -- the promise of replacing the expensive nerds is the eternal flame for the MBA. [1] well, that, plus after being a founder, people were suddenly willing to hire me to be a PM...

Terr_ 2mo ago
"Product Manager, your job is to find the mix of features which is fast and cheap and good, and then browbeat the Engineers into implementing them. Don't just parrot me their excuses, fix it!"

hn_throwaway_99 2mo ago

Sure, I'm not saying design is easy either, but even if you have detailed user requirements, a fully spec'ed out UI, and some general technical requirements, translating that to (working) code is still really, really difficult. I used to do a lot of interviews in my previous career, and I can't tell you the number of times I'd be interviewing someone who could talk a good game, but the second it got to writing code, if the world depended on them being able to write a simple correct loop, we'd all be dead. I know everyone shits on Lee code, and I agree the "brain teaser-y" nature of it doesn't often match real world development, but often times I'd tell folks almost exactly what the code needed to do, in English, and they still couldn't translate that to sensible code. Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part". Well, yeah, sure. But actually writing correct, maintainable, well-structured code is (was?) very much at least one of the hard parts.

skydhash 2mo ago
> Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part Compared to the other parts. If you can do the problem solving part and the design part,code is easy. If you can't write code, I strongly doubt your ability to do the first two. People talking good game always try to keep it high level and full of jargon. Once you ask them to explain part of the design, you'll see the inconsistency and holes of what they are saying very easily.
mrheosuper 2mo ago
"Talk is cheap, show me the code" - Linus

sgarland 2mo ago

Your analogy to baking makes no sense. At best, compiling would be like putting a cake in the oven. Making the cake is coding. > ovens are non-deterministic Uhhh… no? Modulo calibration drift, they will get to and hold a commanded temperature for as long as you tell them to. The ambient humidity and temperature in your house / bakery may differ - which can absolutely affect some foods - but ovens are pretty binary.