As engineers, we solve problems. Picking a problem domain close to your heart that intersects with your skills will likely be valued - and valuable. Engage the work, aim to understand and solve the human problems for those around you, and the way forward becomes clearer. Human problems (food, health, safety) are generally constant while tools may change. Learn and use whatever tools to help you, be it scientific principles, hammers or LLMs. For me, doing so and living within my means has been intrinsically satisfying. Not terribly successful materially but has been a good life so far. Good luck.
An interesting post on the role of respect and skill building - in this case, the skill to end suffering. One paragraph near the end wraps it up somewhat:
----
Perhaps the most delicate skill with regard to respect is learning how to balance all three aspects of respect: for yourself, for the truth of causality, and for the insight of others. This balance is essential to any skill. If you want to become a potter, for example, you have to learn not only from your teacher, but also from your own actions and powers of observation, and from the clay itself. Then you have to weigh all of these factors together to achieve mastery on your own. If, in your pursuit of the Buddhist path, your self-respect outweighs your respect for the truth of causality or the insights of others, you’ll find it hard to take criticism or to laugh at your own foolishness. This will make it impossible for you to learn. If, on the other hand, your respect for your teachers outweighs your self-respect or your respect for the truth, you can open yourself to charlatans and close yourself to the truth that the canon says “is to be seen by the wise for themselves.”
----
I've been using DuckDuckGo for about a year now and I've not noticed the difference. Stack Overflow, MDN are common search results while the occasional blog post also find its way into the result..
Nicely and clearly put. Doesn't really matter if it is merely a convenience as @electrograv said, i find this a very pragmatic way of looking and handling at the matter.
As one digs deeper into distributed systems, Lamport's writing keeps popping up. Below is a transcript of the last few slides in the video lecture.
[starting@28:30]
The fundamental problem facing computer engineers is complexity.
Good engineering means making systems as simple as possible.
The math needed to describe computer systems is simple.
Programming languages are complicated.
You don't achieve simplicity by thinking in terms of complicated languages.
Simplicity requires thinking abstractly before implementing.
This means thinking mathematically before writing any code.
TLA+ teaches how to think mathematically, but few engineers are willing to try.
They must overcome years of "brain washing" that began with their computer science education.
Mathematical thinking must be taught in universities.
I believe I know what students should learn:
* Understanding a system as a state machine
* Describing a state machine mathematically with an initial predicate and next-state relation.
* Thinking of implementation as substitution.
Can anyone help explain what Lamport meant by "implementation as substitution"?
Wonder if there's something similar in other domains.