101–110 of 290 posts
Earlier quoted context omitted.
Additionally, expert engineers can better define the problem space to begin with. Some engineers can get things done and evaluate tradeoffs well, but end up solving the wrong problem. Expert engineers have the ability to think about a problem in a broader context than the engineering problem at hand.
“Talent hits a target no one else can hit. Genius hits a target no one else can see.” - Arthur Schopenhauer
I don't think there is mastery in this work. I've been doing this for decades, and I still think my code from 6 months ago is crap, no matter how much I learn and improve. Mastery would imply that you can do it all, and do it right, on any project, and there is just too much change and evolution for that to ever be true. My goal is simply that I continue to improve.
Earlier quoted context omitted.
He is one of 3 people that came to mind immediately reading this post. One of his latest creations, QuickJS, is quite remarkable. The other two I thought of are Peter Norton and Linus Torvalds. Fabrice, despite his tremendous contributions to the field, doesn't reach for acclaim and just seems to go his own way. Peter Norton was a genius in his field. His book on Assembly Language was one of my favorites as a youth.…
>Linus, as the namesake for Linux also made a huge impact on the field... and comes off as somewhat of an uncontrolled lunatic. What? Linus is one of the most Rational, Direct, No-Nonsense, Get Things Done Leader there is. Whenever i hear some self-appointed "expert" pontificate on Leadership/Management/etc. i always think of what Linus would say/do in that situation. People only think of him as a "Technical Guy" but…
I'll agree that many of the things he says are reasonable. An example is his recent defense of long lines and dismissal of the insane "80 characters per line" peeps.
What I mean specifically by "uncontrolled lunatic" is that he often ignores convention and current opinion and does and says things that get him into trouble. He also has a temper that he often is bad at controlling. I myself have this issue, and I don't see how one could say he does not have issues in this regard.
While it requires some amount of perpendicular thinking to be a master of software, having such an attitude and working with other people in that way will cause too much conflict that is unnecessary.
I think what you are missing in my statement is that I consider calling someone an "uncontrolled lunatic" as a sort of compliment.
I agree also that he is less of a technical person and more of a manager. His skills lie in herding.
On the other hand; Git is a flaming piece of garbage and he is directly responsible for its popularity... so... He did though reasonably tell people he didn't intend for anyone outside of kernel developers to use it. I just wish he corrected its deficiencies. Maybe someday he can apply his "arbitrary character restrictions are silly" logic to Git comments and become less contradictory.
Earlier quoted context omitted.
He is one of 3 people that came to mind immediately reading this post. One of his latest creations, QuickJS, is quite remarkable. The other two I thought of are Peter Norton and Linus Torvalds. Fabrice, despite his tremendous contributions to the field, doesn't reach for acclaim and just seems to go his own way. Peter Norton was a genius in his field. His book on Assembly Language was one of my favorites as a youth.…
>Linus, as the namesake for Linux also made a huge impact on the field... and comes off as somewhat of an uncontrolled lunatic. Ha! Would you consider Musk also as a Lunatic? :-)
I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such t…
junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
Earlier quoted context omitted.
This reminds me of a talk of Linus Torvalds. From this perspective, mastery can be seen as an acquired taste that came after doing a large volume of work.
Can you please link the talk?
I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such t…
> They are able to discern and avoid work that does not provide value (this is often their greatest skill) junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
I don't know, but I one practice along my journey has had a surprising impact upon my skill development. That one thing is: I started coding in VIM. For some reason, making that change has improved my thinking, and that's been a big part of my growth. So, maybe you'll find that to be a helpful practice as well. It's worth a try.
You introduced a new tool to your workflow. The consequences of that was
- Lower productivity initially - You where forced to think about how you create/edit your code
So, what made it work for you?
- Thinking about how you structure and edit your code. This gave you some clarity around how to think and solve a given problem. Longer you practiced this, better you became at it.
- Learning a new tool made you a better at certain things (Say how you manipulate large amount of text?). Better you became, more confidence you derived out of it. More confidence resulted in taking up more harder problems, and the cycle continues.
- You have started thinking about your tools. You spent time and energy in learning it. This has broadened how you think about software development. This in turn has widened your ability to look at the software problems.
I am not sure what I wrote resonates with you or not. But this is what I took away from you response "Making that change has improved my thinking"
I feel, it's not the choice of the specific tool that made a difference, but the result of changing your regular habits that VIM bought about in your way of writing code. I am sure, a person who changed to emacs or Jetbrains also would have seen something change :-)
Earlier quoted context omitted.
How do you learn that solution curve and their tradeoffs? Swap jobs and hope you see them all in your lifetime? Read articles and hope you pick everything up correctly?
Pre implementation - Identify and document possible solutions. Think hard about why each solution is good and each decision is bad. - Within each solution, attempt to find common patterns in that problemspace (when working with Sharded databases, this approach brings these results, etc) - Try to match your personal and organization requirements against the various patterns you find and the pros/cons you defined previ…
As they say, pain + reflection = progress. If you don't wanna reflect, good luck enjoying that pain without progress.
I’ve been pondering this a lot lately, as an engineering leader. Masters in my organization have an extremely high ratio of value shipped to hours worked. This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such t…
> They are able to discern and avoid work that does not provide value (this is often their greatest skill) junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'