4 ms·

IMO it massively depends on what you're working on. I work on some codebases that are primarily about moving data around in Go. There are patterns to follow, t

IMO it massively depends on what you're working on. I work on some codebases that are primarily about moving data around in Go. There are patterns to follow, there are no tricky algorithms, concurrency is largely solved, etc. All the challenge is about the broader engineering task of developing requirements, communicating, managing risks of deployment, stuff like that. Then, I work on kernel code where it takes me months to get a few hundred lines of C to a quality that is acceptable. It's mentally exhausting, I have to take breaks. I can randomly get stuck for hours at a time on stupid stuff like a linked list corruption. Deadlocks happen. It's just as hard as programming has ever been. I have very little energy left over to engage with stakeholders, do project planning, etc. So there's one PoV.

semitones 3y ago
It might be the case that, the "hotter" the code paths that you're writing are (the more they get executed), the more difficult it is to write that code, where as for "colder" paths (of which there are so many more), the code isn't as difficult but there is a lot more overhead of managing complexity, business priorities, process, communication, etc. Linux kernel code is probably some of the hottest code on the planet, and the developers/community understand that contributors need to be able to do exactly what you are doing - spending months toiling over a few hundred lines, and making sure that they are as perfect as can be, because literally billions or even _trillions_ of systems will depend on that code path. It is understood that in order to get it correct, performant, and maintainable, there is no other option other than to have a skilled developer take on a very high cognitive load in order to correctly implement the task. For colder code paths, like business logic (e.g. customer registers, happens "once" per customer), that logic evolves with the team, the team evolves with the company, the company evolves with the business, the business evolves with the market, which evolves with the world. The code might be pretty simple and easy to write, but the conversations around priorities and complexity and "why are we doing this" take up the lions share of the mental effort around it. Also exhausting... TLDR it is much harder to write systems code than it is to write python code that makes a call to an API and saves a record in a database, and working on the former _perhaps_ gives you more opportunity to be shielded from typical "software engineering" toil of business communication.
- justincredible 3y ago
  [dead]
- cagmz 3y ago
  Well said.

semitones 3y ago

It might be the case that, the "hotter" the code paths that you're writing are (the more they get executed), the more difficult it is to write that code, where as for "colder" paths (of which there are so many more), the code isn't as difficult but there is a lot more overhead of managing complexity, business priorities, process, communication, etc. Linux kernel code is probably some of the hottest code on the planet, and the developers/community understand that contributors need to be able to do exactly what you are doing - spending months toiling over a few hundred lines, and making sure that they are as perfect as can be, because literally billions or even _trillions_ of systems will depend on that code path. It is understood that in order to get it correct, performant, and maintainable, there is no other option other than to have a skilled developer take on a very high cognitive load in order to correctly implement the task. For colder code paths, like business logic (e.g. customer registers, happens "once" per customer), that logic evolves with the team, the team evolves with the company, the company evolves with the business, the business evolves with the market, which evolves with the world. The code might be pretty simple and easy to write, but the conversations around priorities and complexity and "why are we doing this" take up the lions share of the mental effort around it. Also exhausting... TLDR it is much harder to write systems code than it is to write python code that makes a call to an API and saves a record in a database, and working on the former _perhaps_ gives you more opportunity to be shielded from typical "software engineering" toil of business communication.

justincredible 3y ago
[dead]
cagmz 3y ago
Well said.