[deleted]
Ask HN: What does mastery look like in software engineering?
81–90 of 290 posts
Re: Ask HN: What does mastery look like in software engineering?
#82I 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.
> I don't think there is mastery in this work. I take it one step further, I don't believe mastery exists, or rather we don't have a consistency on what mastery 'is'. I prefer the saying something along the lines of "expertise* just means you get in more trouble when you do it wrong" * Expertise is replaced with 'black belt' for martial art expertise
I think it's more like that quote from a supreme court decision about porn, it's very hard to define but you know it when you see it.
I play violin, and know and admire many masters. What makes them so good is fun to study and pursue because they are worth emulation.
But it's not some secret or hack. It's a million small things and a lot of feel.
Re: Ask HN: What does mastery look like in software engineering?
#83Earlier quoted context omitted.
Why on earth would number of languages have anything to do with it. That doesn’t make sense. Parochial number of languages doesn’t capture the idea of understanding multiple paradigms, low level / high level, type system considerations. A person might have zero experience except Node.js yet still show high mastery of functional programming, mixed OOP, design patterns, compilers, etc. Setting any threshold on language…
It’s just a simple and objective yet general measure of mastery If you have these skills there is a very high likelihood that you can do most other things that are thrown at you Most of the other answers have all these high level wishy washy specifications, I thought I’d take a more brass tacks approach.
It is mostly beginners and students that think learning programming languages is difficult or is a big part of the difficulty of writing software.
Re: Ask HN: What does mastery look like in software engineering?
#84Pay attention to who was the lead dev on the code you are using. When you see that you are using 2+ (sometimes 5+, rarely 10+) projects from the same person, then you've found a master. Start looking closely at what they are doing, what they are reading, what they are saying on their blog, twitter, etc. I think of Linus, Lars, Anders, TJ, Rich, etc
Can you add the last names? Some these are difficult to tell who you are referring to.
Linus TechTips, Lars Ulrich, Anders Holm, TJ Maxx, Rich Nixon
Re: Ask HN: What does mastery look like in software engineering?
#85I’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 that the cost of adding more value to the system remains constant as the system grows in complexity.
Re: Ask HN: What does mastery look like in software engineering?
#86Earlier 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?
OP is giving a problem solving framework, it's not tied to specific solutions or tradeoffs. It's more of a method for thinking through a solution. In more detail, the steps go like this. Find as many solutions to a given problem as you can. Bad engineers run with the first solution that comes to mind, letting confirmation bias drive them. Evaluate each solution for its costs and benefits. Imagine two steps in the fut…
This comment made me realize what my mentor did years ago. He would have the entire team list all possible solutions to a problem, including the obviously bad ones, then have us whittle down the list based on pros and cons of each until we reached consensus on what to do. It was a teaching exercise and I didn’t realize it.
I’ve repeated it that exercise with junior engineers to great effect. Some catch on over time and start intuitively considering the trade offs of a few reasonable solutions to a problem; some don’t.
I never reflected on what he was doing there; thanks.
Re: Ask HN: What does mastery look like in software engineering?
#87Ability to design and implement a large scale system from the ground up.
Re: Ask HN: What does mastery look like in software engineering?
#88George Hotz lol
Re: Ask HN: What does mastery look like in software engineering?
#89I’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…
I agree with this. The best engineers choose the best targets
Re: Ask HN: What does mastery look like in software engineering?
#90When is "mastery" a meaningful concept for a field of endeavor? I think we wouldn't believe it makes sense to "master" physics or math, because the advanced work in those fields focuses on open problems. Even if one understands classical physics well, one cannot make specific predictions about medium-sized, low-ish energy systems like a double pendulum. Can anyone claim to be a "master" of an area in which there are…
Very nice analogy to physics/math. I agree: the "best" people are always working on the next big problem.