Among other things a master splits the I/O code and core logic code.
Ask HN: What does mastery look like in software engineering?
131–140 of 290 posts
Re: Ask HN: What does mastery look like in software engineering?
#132I’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 don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
This happens to me at my organization fairly often. I build solutions I'm asked to build and then an abusive architect coopts that work and rewrites it in a shitty, unusable way. Users cry at me, but when I tell them what happened, they are silent. No one cares enough to cry to leadership. And the leadership have clearly said they have no intention of overruling what said architect talks about.
Re: Ask HN: What does mastery look like in software engineering?
#133Earlier 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
Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats.
- Howard Aiken
Re: Ask HN: What does mastery look like in software engineering?
#134Two words: Functional Programming
Functional programming is taught in schools, so engineers straight out of college know it. I was one of them!
Re: Ask HN: What does mastery look like in software engineering?
#135Is it possible? Maybe if you say a specific language, yes, but even then, there are new versions or iterations where whole new features are introduced.
Mastery in software engineering needs to be defined very specifically.
An example, I used to build Flash microsites, campaigns and games for an ad agency. I had a very good grasp of the tech, built projects for large clients etc. If you looked at me at that point in time you could say I had mastery, but now Flash is gone, and I didn’t switch over to React and other web based tech soon enough so my “skill” is lesser than someone who purely started in that domain.
Re: Ask HN: What does mastery look like in software engineering?
#136Earlier 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?
Sticking around long enough to see a big mistake bite you is sometimes better for your growth than swapping jobs.
You can also dig into the problems that existed when you got to the project, and try to work out how they came to be. Project forensics is a skill set unto itself. And listen to and help people on other projects at your company. You can see how their story arc goes and where it surprises you.
An intelligent man learns from his own mistakes. A wise man learns from the mistakes of others.
Re: Ask HN: What does mastery look like in software engineering?
#137My definition of a "Master" is someone that can churn out software that is both;
- High performance (in terms of efficiency in using computational resources)
- Reliable i.e does exactly what we want and doesn't crash. This also includes clear documentation.
I think to reach there, some of the things one may want do are;
a) Learn TLA+
b) Study hardware (processors, memory)
c) Study software, protocols like tcp/ip
d) Build experiments & ship
Re: Ask HN: What does mastery look like in software engineering?
#138Earlier 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?
Prototyping alternative solutions is a cheap way to help uncover trade-offs, and you can do this independently. Attending retrospectives after things go wrong is a good way for experts to introduce their thought processes to less experienced engineers. Asking "why?" when senior engineers deliver feedback during design review can help you learn that a trade-off existed when you did not see it.
I once was trying to design a validation framework. I thought it should work this way. The other lead thought it should work that way. So I proposed we write some sample code for these APIs and show it to the team. TDD with pseudocode before any of us knew what TDD was.
Only, I didn’t like having two to chose from. Something told me three would be better. So we paired, I wrote mine, then hers, then just made another one up on the spot. Once we agreed they were complete and implementable, I shopped them to the team.
About 2/3rds preferred the made up one. Including me. So that’s what I implemented.
Re: Ask HN: What does mastery look like in software engineering?
#139I’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 don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
Totally agree and I wish to those people to leave the place they are currently in and find a better where their skills are truly recognised.
Re: Ask HN: What does mastery look like in software engineering?
#140Earlier quoted context omitted.
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
Totally agree and I wish to those people to leave the place they are currently in and find a better where their skills are truly recognised.
That's a tough one. Often the sensibility about what needs to be done comes from hours/weeks/month/years hacking away at their codebase in their specific setting. Much of that has to be rebuilt from scratch in a new place. If you don't find that same connection with your work at the new place - or are unable to develop the relationships with your peers or your manager, you may not end up able to make that impact at the new place either.
I tend to encourage folks who come to me about quitting to explore opportunities within the team/organization/company before leaving so they can leverage all the social capital they've built up.