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

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

#171

Post by ZephyrBlu » Thu, Jan 07, 2021, 9:28 AM UTC

gugagore wrote: post #128

DougWebb wrote: post #117

Earlier quoted context omitted.

I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal. A…

It seems like this value you brought in is "outside" the domain of software engineering, however. Yes, the solution ended up being found in software engineering, but the problem came from a business operation thing, no? (I wish you had gotten more thoroughly compensated for saving them a fortune.)

If your only skill is being able to write code, your skillset is relatively weak.

We are called Software Engineers, but what we really are is people who solve problems with code.

The important part is solving the problem. The fact we do it through the medium of code isn't that noteworthy.

If solving the problem requires knowledge from outside the domain of programming (Spoiler: it almost always does), then you learn what you need to from the relevant domain.

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

#172

Post by plutonorm » Thu, Jan 07, 2021, 9:33 AM UTC

arcticbull wrote: post #140

kostarelo wrote: post #139

Earlier quoted context omitted.

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 t…

If you are not being heard where you are it's very likely the culture is toxic or you are not respected. In either case it's time to leave.

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

#173

Post by ZephyrBlu » Thu, Jan 07, 2021, 9:35 AM UTC

mkinsella wrote: post #110

hiimtroymclure wrote: post #105

Earlier quoted context omitted.

> They are able to discern and avoid work that does not provide value (this is often their greatest skill) junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.

This is the biggest difference between a Junior Engineer and a Senior (or Staff Engineer). A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'

It's kind of a self-fulfilling prophecy though.

Most Seniors are driving the roadmap simply by virtue of being a Senior, and most Juniors have no opportunity to influence the roadmap because Seniors control the decisions.

Of course ideally everyone can contribute, but I think that's relatively rare.

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

#174

Post by Cthulhu_ » Thu, Jan 07, 2021, 9:36 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…

It reminds me of a guy I used to work with. He two-finger typed looking at his keyboard all the time, but the code he did end up writing was exactly what was needed. Consistency and quality was much more important than cold, hard "productivity".

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

#175

Post by ununoctium87 » Thu, Jan 07, 2021, 9:39 AM UTC

natenthe wrote: post #61

arensc wrote: post #60

Hey So I view Software Engineering as a multidimensional optimization surface where you have to optimize for a goal by choosing an axis and playing with those axis until you get a desired result. Mastering the language but understanding why the language was developed what problems it looked to address. Reducing the cognitive load of the design using the language. Understanding the fundamentals of the types of applica…

Is this a parody?

Maybe someone trying out a badly trained GPT-3 generator

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

#176

Post by kissgyorgy » Thu, Jan 07, 2021, 9:39 AM UTC

Uncle Bob Martin coined the term "Software Craftsmanship", you can watch his talks about the topic. I intend to follow it throughout my career.

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

#177

Post by plutonorm » Thu, Jan 07, 2021, 9:39 AM UTC

DougWebb wrote: post #117

hiimtroymclure wrote: post #105

Earlier quoted context omitted.

> They are able to discern and avoid work that does not provide value (this is often their greatest skill) junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.

I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal. A…

You have to be present in the meeting. All the places I have worked - and I have worked in many over 15 years - do not allow this. You need to be in a startup to be close enough to have this kind of impact. Agile just makes this situation worse. It's incredibly frustrating to be see the value you can add, but having no ability to make it happen.

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

#178

Post by kostarelo » Thu, Jan 07, 2021, 9:55 AM UTC

arcticbull wrote: post #140

kostarelo wrote: post #139

Earlier quoted context omitted.

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 t…

Absolutely, especially in bigger organisations where one part may be completely different in terms of how is organized and how is operating from another one.

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

#179

Post by EliRivers » Thu, Jan 07, 2021, 9:56 AM UTC

Amongst other signs, they make it look effortless by identifing problems long before they become problems and taking small steps now to make a better future in a few months time.

I don't see them engaged in "heroic" coding marathons to desperately get something fixed or delivered; they already fixed it weeks or months ago.

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

#180

Post by knadh » Thu, Jan 07, 2021, 9:58 AM UTC

Mastery is difficult to quantify, especially in terms of code or engineering cleverness. I think, what comes close, is the ability to get way more tradeoffs right than wrong, to hit an optimal balance. Tradeoffs in decision making when it comes to picking technologies or languages, or a certain design pattern, or an architecture, or UI/UX or whatever, when building systems. Small tradeoffs that may not look like much immediately, but pay off in the long term. Sacrificing a seemingly good feature now to avoid the pain of technical debt in the future.

Many of these traits are fundamental, universal, and even philosophical, than is general perceived, and transcend technologies and stacks, and to a large extent, time.

And yet, I think, the above traits can be described as good, and not really mastery in its truest sense, like in other disciplines like music or painting. Software engineering is way too diverse, fragmented, chaotic, and ever changing.