Ask HN: What does mastery look like in software engineering? • Hacker News Board

Re: Ask HN: What does mastery look like in software engineering?

#191

Post by DarkWiiPlayer » Thu, Jan 07, 2021, 10:35 AM UTC

I'd say the key point is the ability to identify and reason about complexity.

Figuring out what the irreducible complexities of a problem are and at what tradeoffs these complexities could be addressed in different components of an application (including handing them off to the user).

A few corollaries of this are:

- Masters will write less code, as they will eliminate most of the complexity when there is time for this.

- Masters can more easily put the complexity where they want it, having more control over trade-offs between performance, usability, flexibility, etc.

- Masters will have an easier time estimating the required work needed to implement a project, as experience gives them a good intuition for what the irreducible complexity of a problem is.

- Masters will rarely tell you a "right" solution except for simple problems. Their answer will depend as much on your specific requirements as the problem you're trying to solve[1].

- Masters will often fix problems by simplifying code. Refactoring will be a natural part to their coding workflow, not a separate "housekeeping" activity.

- Those who hide complexity behind more complexity are not masters. Those who always fix problems by adding more code are not masters.

[1] It could be argued that "add to numbers and do it fast" is a single problem and that's not wrong. Requirements like "speed" and "usability" are really just another aspect of the desired outcome of a program, but it's rarely thought of as part of the problem to be solved, thus I am considering these constrains as separate from the "core" of the problem.

Re: Ask HN: What does mastery look like in software engineering?

#192

Post by GistNoesis » Thu, Jan 07, 2021, 10:37 AM UTC

I think of tool makers.

Software engineering, gives you some degrees of freedom, therefore it's kind of an art form. Therefore mastery is about intent and the ability to realize it.

In this canvas, you can ask yourself, is the bearer wielding the tool or is it the other way around.

For me a proficient tool user is no master until he makes his tools his own. He can become one either by creating them, or by understanding them deeply enough that he could recreate them.

There are then various levels of mastery and mastery over various sizes of domain. Levels are more about the capacity of imagining new tools, and having new visions in order to advance your field in some interesting way. Growing domain size is about trying to have bigger and bigger tools while still retaining control over them.

Re: Ask HN: What does mastery look like in software engineering?

#193

Post by mstipetic » Thu, Jan 07, 2021, 10:38 AM UTC

itsmejeff wrote: post #85

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…

Can we stop using this word leader? What's wrong with the word manager?

Re: Ask HN: What does mastery look like in software engineering?

#194

Post by pbourke » Thu, Jan 07, 2021, 10:38 AM UTC

INTPenis wrote: post #153

In my experience it means you rarely write software but you've moved into architecting software platforms and telling other people how to write software. I'm just a devops guy but my current project is like that, where our lead architect has really impressed me by drawing up the design of a very scalable system. My task is merely to implement and manage kubernetes for it and we have other devs who are using java, .ne…

If you rarely write software then you are not moving towards mastery in engineering it. There is no such thing as a master painter who is primarily a manager of painters.

You can be a masterful manager, can deliver much more value than a single programmer, etc. But the engineering of software occurs primarily in the thinking about and directly working on it in its specifics.

Re: Ask HN: What does mastery look like in software engineering?

#195

Post by disgruntledphd2 » Thu, Jan 07, 2021, 10:55 AM UTC

healsjnr1 wrote: post #188

conductr wrote: post #147

Earlier quoted context omitted.

While your bridge analogy is true, I feel it's even more valuable to have an informed view for what's on the other end of that bridge. If you work the politics and use all the right materials to build an efficient bridge that's great. But a wonderful bridge to nowhere is still a bridge to nowhere. I say this because as a finance guy, I've been on lots of projects that look great on a spreadsheet and marketing, sales,…

That sounds amazing, sadly in a lot of organisations that isn't how it pans out. Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out. The crux of this is that many of those people who carry the weight in decision making do…

It depends on the organisation, to be honest.

For instance, in my experience at a FAANG, the issue was often that a new technical solution was proposed, architected and built before any business/market people got involved with the result that loads of amazing, brilliantly architected and completely useless projects got built.

(My favourite time was when a (really smart, to be fair) software engineer rediscovered the normal distribution while looking for a way to reduce storage requirements for an analytics product).

Re: Ask HN: What does mastery look like in software engineering?

#196

Post by J-dawg » Thu, Jan 07, 2021, 11:04 AM UTC

habosa wrote: post #190

I don't think there is one answer but there are a few things I have noticed in my short career so far: * I think an intermediate level of mastery is when you realize that a computer is a logic machine built to serve humans and it will always listen to you if you're willing to put in the effort. You can always go a level deeper. Great engineers know all of the tools at their disposal and will bend the computer to thei…

> I think an intermediate level of mastery is when you realize that a computer is a logic machine built to serve humans and it will always listen to you if you're willing to put in the effort. You can always go a level deeper. Great engineers know all of the tools at their disposal and will bend the computer to their will if they need to.

I've worked with some people who definitely seemed like "masters", and this was true of all of them. Quiet patience and an unshakeable belief that this thing is going to be fixable, even after trying multiple things that have gone nowhere. And they're almost always proved right.

It also made me realise I need to get out of this business as soon as possible, because I'm the polar opposite. After a few failed attempts my brain goes into panic mode and the problem seems insurmountable. Then I "wake up" an hour later after a bout of procrastination, no closer to a solution.

I often wonder about the chicken and egg of how people attain this state. Are they first and foremost technically brilliant, and the confidence emerges from that? Or is it more of a personality type that has allowed them to solve lots of problems and become technically brilliant along the way?

Re: Ask HN: What does mastery look like in software engineering?

#197

Post by INTPenis » Thu, Jan 07, 2021, 11:24 AM UTC

pbourke wrote: post #194

INTPenis wrote: post #153

In my experience it means you rarely write software but you've moved into architecting software platforms and telling other people how to write software. I'm just a devops guy but my current project is like that, where our lead architect has really impressed me by drawing up the design of a very scalable system. My task is merely to implement and manage kubernetes for it and we have other devs who are using java, .ne…

If you rarely write software then you are not moving towards mastery in engineering it. There is no such thing as a master painter who is primarily a manager of painters. You can be a masterful manager, can deliver much more value than a single programmer, etc. But the engineering of software occurs primarily in the thinking about and directly working on it in its specifics.

I see what you mean but it's more nuanced than that in my case.

It's not like he turned 50 and suddenly stopped coding. I'm talking about a real nerd, a person who codes even on their free time.

And he still writes code in other projects, he's a consultant, but in our project he's not touching any code, only advising. And he's 50+ now so he has 15 more years until retirement.

Of course I've seen people here work beyond retirement because our field is so easy on the body.

Re: Ask HN: What does mastery look like in software engineering?

#198

Post by indymike » Thu, Jan 07, 2021, 11:35 AM UTC

They build better software. They are both strong contributors individually, and strong team members. Better is relative to whatever the purpose of that software is. If it needs to be fast, it is. If it needs to be secure, it is. If it needs to be made quickly, it is.

Re: Ask HN: What does mastery look like in software engineering?

#199

Post by Aeolun » Thu, Jan 07, 2021, 11:35 AM UTC

arcticbull wrote: post #142

bedobi wrote: post #122

Earlier 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.

Part of what it means to be a senior engineer is that you have a mastery over the soft skills/people skills commensurate with your engineering abilities. Someone who knows how a bridge should be architected but cannot navigate the politics of city council necessary to get it built isn't much of a bridge builder. The importance of good politics cannot be understated. Politics in this case is roughly defined as getting…

You can be as nice a person as you want, if you are talking with an asshole, you are in for a bad time.

Re: Ask HN: What does mastery look like in software engineering?

#200

Post by robertlagrant » Thu, Jan 07, 2021, 11:36 AM UTC

disgruntledphd2 wrote: post #195

healsjnr1 wrote: post #188

Earlier quoted context omitted.

That sounds amazing, sadly in a lot of organisations that isn't how it pans out. Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out. The crux of this is that many of those people who carry the weight in decision making do…

It depends on the organisation, to be honest. For instance, in my experience at a FAANG, the issue was often that a new technical solution was proposed, architected and built before any business/market people got involved with the result that loads of amazing, brilliantly architected and completely useless projects got built. (My favourite time was when a (really smart, to be fair) software engineer rediscovered the…

If you have a load of smart engineers, sometimes it can be a more successful strategy to just build something than to pay EY £250k to do market analysis, get a load of execs bought in who then will "make it work" even if it shouldn't, or kill it off even if they shouldn't, and then finally get a committee-written spec handed over to be built in a rush.