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

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

#51

Post by abeppu » Wed, Jan 06, 2021, 10:25 PM UTC

When is "mastery" a meaningful concept for a field of endeavor? I think we wouldn't believe it makes sense to "master" physics or math, because the advanced work in those fields focuses on open problems. Even if one understands classical physics well, one cannot make specific predictions about medium-sized, low-ish energy systems like a double pendulum. Can anyone claim to be a "master" of an area in which there are such large known gaps in everyone's knowledge?

Though in software engineering we have a lot of prior examples of successful and unsuccessful projects, we also have lots of open frontiers. And in some ways, it's much harder to "know" that an engineering approach or paradigm is "right" than it is to know that a theorem is true.

How can we make types track the "important" invariances of a system? How can we convince ourselves that a distributed system can guarantee certain properties, or that a modification to that system doesn't break those guarantees? If I build a homomorphic encryption system as a service, how would I build debugging tools for it? Acknowledging the halting problem and its cousins, when can static analysis tools make useful, meaningful predictions about programs?

In the bronze age, you could build an impressive stone tower. Sometimes you could even make it stay standing. But I don't think there were any master civil engineers.

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

#52

Post by bokohut » Wed, Jan 06, 2021, 10:28 PM UTC

kube-system wrote: post #44

dumbfoundded wrote: post #20

IMO 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 enginee…

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.

"to think about a problem in a broader context" << this

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

#53

Post by snarkypixel » Wed, Jan 06, 2021, 10:35 PM UTC

Ironically, it's often when there's no mastery that you realize what mastery is. (I.e. when things just work, are shipped on time and are easy to maintain, there's not much fanfare about it)

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

#54

Post by 0xdeadbeefbabe » Wed, Jan 06, 2021, 10:49 PM UTC

throwii wrote: post #26

dumbfoundded wrote: post #20

IMO 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 enginee…

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?

Seems almost like you are talking about static vs. dynamic analysis of programs.

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

#55

Post by 0xdeadbeefbabe » Wed, Jan 06, 2021, 10:56 PM UTC

Someone who is good at mental models.

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

#56

Post by girzel » Wed, Jan 06, 2021, 11:34 PM UTC

Having an accurate intuitive assessment of how difficult a task will be, and;

knowing what to Google.

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

#57

Post by unsatchmo » Thu, Jan 07, 2021, 12:09 AM UTC

codingdave wrote: post #21

I don't think there is mastery in this work. I've been doing this for decades, and I still think my code from 6 months ago is crap, no matter how much I learn and improve. Mastery would imply that you can do it all, and do it right, on any project, and there is just too much change and evolution for that to ever be true. My goal is simply that I continue to improve.

Length of time doing something doesn't imply mastery. It can contribute to mastery, but only if you're always pushing your skill to the next level I think.

For example: I know people who have been skateboarding for decades and are just barely OK at it. How you practice matters.

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

#58

Post by bilkoo » Thu, Jan 07, 2021, 1:08 AM UTC

kube-system wrote: post #44

dumbfoundded wrote: post #20

IMO 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 enginee…

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

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

#59

Post by mikewarot » Thu, Jan 07, 2021, 1:08 AM UTC

I heard a story that Dan Day - Rose Hulman class of 79, once sat down and typed in a complete system of programs and it worked the first time.

Ward Christensen did it once as well, to the annoyance of my late friend Lloyd Smith, may he rest in peace.

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

#60

Post by arensc » Thu, Jan 07, 2021, 1:27 AM UTC

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 applications you will be building. SCRUD Architecture Apps Streaming Architecture Apps and Games which are usually a combination of both.

Software Systems from first principles are read and write systems. How do you represent that as a program and reduce the complexity?

How you view software engineering ? and explain it to others what is the method of representation you use to encode software as plumbing? is it text based? time flow graph node based? stack based ? binary based ?

Software engineering as a team sport, how do you get a bunch of developers to reduce the cognitive load manage the relationships and data in the code and how do you measure that like a science.

I am also sure there is a lot of valid advice here as well. This is how. I see it from a mathematical / science perspective that pushes pragmatic narrative.