Que all the managers that will immediately list off 5 manager activities as software engineering "mastery."
Ask HN: What does mastery look like in software engineering?
31–40 of 290 posts
Re: Ask HN: What does mastery look like in software engineering?
#32That's an interesting question and I'm going to give you a somewhat snarky but truthful answer: Software mastery is exhibited by the code that I wrote today - and oh how horrible it is to look at what I wrote six months ago.
Through-out my career, which is now over four decades if you include the software I wrote as a teenager (before I got paid to do it), I've continuously found a better, more elegant (which can almost always be read simpler or clearer) way to tell the computer what to do.
So my non-snarky view-point is that there's no such thing as mastery but rather that it's the proverbial journey. There is however a baseline at the other end ... if it's not functional and maintainable, there's a definite lack of mastery.
Re: Ask HN: What does mastery look like in software engineering?
#33Being able to break a complex project into granular bite-sized tasks.
Re: Ask HN: What does mastery look like in software engineering?
#34IMO it's about understanding the solution curve in the problem space. Every problem type has a range of possible solutions. Most of these solutions are wrong and a few are correct with different tradeoffs. When you can't do better without making tradeoffs, you're on the curve. Novice engineers will struggle to get something done. Intermediate engineers can get things done but fail to see the tradeoffs. Expert enginee…
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?
raw experience
Re: Ask HN: What does mastery look like in software engineering?
#35Perfect estimates, deep insights, and anticipating challenges
I would say that even just aiming at perfect estimates is a sign that mastery has not been achieved yet. Wisdom is to acknowledge uncertainty and that estimates are uncertain in nature because the information available at the time is always incomplete.
Yes, but there are also situations that demand certainty and accuracy in estimates. One must appease them by looking as though you are trying.
Re: Ask HN: What does mastery look like in software engineering?
#36Highly competent in at least 3 languages; general understanding of 5 others; good written communication and presentation skills; able to create gui; understanding of distributed systems and networking; unix command line; can at least rebase in git
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 languages just sets up a meaningless metric.
Re: Ask HN: What does mastery look like in software engineering?
#37That's an interesting question and I'm going to give you a somewhat snarky but truthful answer: Software mastery is exhibited by the code that I wrote today - and oh how horrible it is to look at what I wrote six months ago. Through-out my career, which is now over four decades if you include the software I wrote as a teenager (before I got paid to do it), I've continuously found a better, more elegant (which can alm…
More likely that you a) overrate the quality of the code you wrote today (recency bias) and/or b) have forgotten the context/constraints that you wrote the code 6 months ago under
Re: Ask HN: What does mastery look like in software engineering?
#38IMO it's about understanding the solution curve in the problem space. Every problem type has a range of possible solutions. Most of these solutions are wrong and a few are correct with different tradeoffs. When you can't do better without making tradeoffs, you're on the curve. Novice engineers will struggle to get something done. Intermediate engineers can get things done but fail to see the tradeoffs. Expert enginee…
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?
I'd recommend:
- Working with experts
- Writing and deleting lots of code
- Participating in code reviews
- Reading even more code from others
- Watch & read technical presentations
You can never truly be perfect, you can only approach it. Understanding your limitations is just as important as understanding your capabilities. Depth vs breadth is hard and you only have so much life to go so deep into so many domains.
Re: Ask HN: What does mastery look like in software engineering?
#39Re: Ask HN: What does mastery look like in software engineering?
#40Fabrice Bellard, the mind behind FFMpeg and QEMU.
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. Norton tools were impressive for their time.
Linus, as the namesake for Linux also made a huge impact on the field... and comes off as somewhat of an uncontrolled lunatic.
I don't though think that these three people are the highest level masters in the field. I think they are just the ones who have chosen to do things that have high impact and visibility.