Fabrice Bellard, the mind behind FFMpeg and QEMU.
Ask HN: What does mastery look like in software engineering?
11–20 of 290 posts
Re: Ask HN: What does mastery look like in software engineering?
#12I'm somewhat doubtful that 'mastering' Software Engineering is possible. You wouldn't ask what it looks like to master the practice of medicine today because there are dozens or hundreds of specialities and roles all of which contribute to medicine. Firmware engineering and 'agile' website development are very different practices with different assumptions, requirements, etc. I wouldn't expect someone to master both…
> You wouldn't ask what it looks like to master the practice of medicine today because there are dozens or hundreds of specialities and roles all of which contribute to medicine.
This is like saying you can't have a favorite type of rectangle because some rectangles are squares. If you're a master of neurosurgery, a reasonable person would also consider that to be a master of medicine. Just as I would expect a master neurosurgeon to not be a master dermatologist but be able to master dermatology much faster than I could as a non-medical person, I would similarly expect a master C++ developer to master Javascript frontend development much faster than a junior dev, let alone a non-software person.
Re: Ask HN: What does mastery look like in software engineering?
#13Consistently and reliably delivering good software solutions.
Just like a master woodworker would consistently and reliably deliver good furniture.
Or a master author would consistently and reliably deliver good books.
The key points are:
* Consistent - It wasn't just a fluke or luck, you know what you're doing and can repeat it.
* Reliable - You know how much effort it will take and can deliver it.
* Good - It's not crap, people want it.
Re: Ask HN: What does mastery look like in software engineering?
#14Pai Mei mustache, sits on a rock meditating and dispensing advice to juniors, quotes Martin Fowler by heart, seems to never touch a keyboard but every commit will replace entire module(s) flawlessly, demonstrating high level architectural knowledge that lies on the far side of the organisation's learning curve.
>but every commit will replace entire module(s) flawlessly
That's big commits, you're not supposed to do that. Masters commit individual characters that replace entire modules flawlessly.
Re: Ask HN: What does mastery look like in software engineering?
#15Some acceptance tests for a software engineer:
- Should know many tools to the level where they know their strengths and weaknesses. This allows them to select a useful collection of them for any new piece of work.
- Should produce incremental project changes which all either improve the value or reduce the cost.
- Should balance all the improvements to produce useful, working software with a reasonable cost. For example, producing super-secure software with no useful features, featureful software with a bajillion bugs, or bug-free software with a gigantic cost are all bad.
Re: Ask HN: What does mastery look like in software engineering?
#16Perfect 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.
That's only if the challenge is completely new. Sure, if you're researching something novel in an area you've not worked on, the information you have is likely very far from complete. But if you're writing a backend server for a new POC for the umpteenth time in your career, you're likely to be able to do it fast, well, and be able to estimate how long it's gonna take. The reason being that the unknowns are slim to none.
Re: Ask HN: What does mastery look like in software engineering?
#17Consistently and reliably delivering good software solutions. Just like a master woodworker would consistently and reliably deliver good furniture. Or a master author would consistently and reliably deliver good books. The key points are: * Consistent - It wasn't just a fluke or luck, you know what you're doing and can repeat it. * Reliable - You know how much effort it will take and can deliver it. * Good - It's not…
[deleted]
Re: Ask HN: What does mastery look like in software engineering?
#18Pai Mei mustache, sits on a rock meditating and dispensing advice to juniors, quotes Martin Fowler by heart, seems to never touch a keyboard but every commit will replace entire module(s) flawlessly, demonstrating high level architectural knowledge that lies on the far side of the organisation's learning curve.
> but every commit will replace entire module(s) flawlessly That's big commits, you're not supposed to do that. Masters commit individual characters that replace entire modules flawlessly.
Every module Pai Mei implements fits on a single page of his 80-column terminal, including comments. He manages this brevity not with obscure one-liners, but through algorithmic simplicity. Every module is precisely as complex as it needs to be to accomplish its purpose, no more, no less.
Re: Ask HN: What does mastery look like in software engineering?
#19Pai Mei mustache, sits on a rock meditating and dispensing advice to juniors, quotes Martin Fowler by heart, seems to never touch a keyboard but every commit will replace entire module(s) flawlessly, demonstrating high level architectural knowledge that lies on the far side of the organisation's learning curve.
The Master does his job
and then stops.
He understands that the universe
is forever out of control,
and that trying to dominate events
goes against the current of the Tao.
Re: Ask HN: What does mastery look like in software engineering?
#20IMO 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 engineers can identify possible solutions with different approaches.