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

Lots of people here seem to think they know what mastery looks like, but to tell whether someone is a master in something takes another master. And I doubt most of the people who think they are one, actually are.

I will try to avoid doing that myself, specially I will avoid implying I am one, but I think it's possible to come up with a few criteria to help you "judge" the level of mastery one has in software engineering:

* can create a project from scratch without pondering forever about each and every choice, while picking reasonable choices that, together, approach optimality given the circumstances (notice that this depends mostly on the team/company involved so there's not one right universal answer).

* can break up the work in manageable pieces so that progress can be made (regardless of how many people actually work on the project) and measured easily. This is really hard and can only be done properly by a practitioner (meaning, no, your PM can't do that for you).

* can establish a good base design that facilitates achievement of the project's objectives (e.g. if performance-focused, then architecture might differ significantly from a more maintainability-focused one).

* knows to apply the right amount of testing/automation (too much or too little can be damaging).

* can focus on the task at hand, avoiding unnecessary work (many great technical developers fail to do this due to their preference for harder challenges that may not be the right ones to address).

* can communicate well (because knowing it all but not being able to pass the knowledge on or convince others will cause most of your knowledge to become inaccessible).

Notice that to be able to effectively rate a person or team against each criterion is itself something subjective sometimes, so you won't get a clear-cut answer no matter how you look at it... but I am sure that there are ways to use metrics for each one, though we all know the problem with metrics (people will game it), so yeah, it's difficult to figure this out. Just make sure you don't fall into the trap of judging people solely on subjective grounds though as our natural biases are quite crippling (see psychological studies about human bias) and will cause you to misjudge others, sometimes disastrously.

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, .net and golang to write the components.

This impresses me a lot how our lead can come up with such a design and make it work from paper to practice.

Who is John Galt?

As a master... I sit in front my computer and write program(s) from all kind (with and without refs)...

using either libs or not...

This is not what I think... This is what it is.

Gl...

Software Engineering doesn't exist in isolation.

You can't master Software Engineering without mastering interfacing with the rest of the organisation.

I don't care how intellectually pure your implementation is or how fast you deliver things. If it can't easily connect to, use and get used by the rest of the business, it's a folly.

A master of software engineering delivers what the business needs in the minimum time possible.

Some businesses care about maintenance. Some don't.

Some care about UI/UX, others with a trapped audience don't.

Some care about efficiency and optimisation, others don't.

You can't be a "master" until you have a sense of what your business is interested in. Not what it CLAIMS to be interested in, but really cares about.

It's been different in every company I've ever worked for.

Good luck.