|
|
|
|
|
|
by pg_bot
3463 days ago
|
|
|
I disagree, the tooling around most ecosystems is fine you just need someone who knows what they are doing to help guide people in the right direction. Technical leadership is sorely lacking in our industry, and when you are solving business problems management cares about solving customer's issues on time rather that craftsmanship. Therefore people go down the path of doing just enough to get it done rather than doing it right. If you never are forced to do something correct, you are likely never going to be able to build great products. This leads to patchwork engineering and the veritable big ball of mud that most products look like behind the scenes. It's up to us as professionals to simplify, abstract, focus, and enforce standards so that you can build maintainable products faster. Very few problems that we are working on are "difficult" from the technical side of things. Identify when you've made a mistake, think about about how it could be made better, and then apply the knowledge you've gained when building something new. If you repeat that process you will be a lot better than the majority of your peers. |
|
|
I'd say these problems are technically difficult, just not deep. To clarify the difference:
(0) A difficult problem requires a lot of effort to solve. Example: Finding and fixing use-after-free errors in a buggy C program.
(1) A deep problem requires creativity and insight to solve. Example: Inventing and formalizing Rust's borrow checker rules.
Programmers are naturally attracted to deep problems, but not difficult ones. In fact, reducing difficult problems to deep ones is often considered progress, for good reason. After you come up with the right insight, solving a deep problem can be very easy. But solving a difficult problem will always be hard.