Live data from Hacker News

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

news.ycombinator.com

41–50 of 290 posts

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

#41
post #26

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?

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.

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

#42
post #26

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?

Sticking around long enough to see a big mistake bite you is sometimes better for your growth than swapping jobs.

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

#44

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.

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

#46
This is of course a matter of opinion, but for me, seems like there are three sides to this:

1) Knowledge of the core theories of computers: core ideas of computer architecture, good understanding of computational complexity (how long a program will take to run), networking...

2) Knowledge of software technologies: Python, Javascript, Java, C, Docker, Functional Programming, Object-Oriented Programming...

3) Knowledge of software engineering concepts: Software architecture, software process (agile, requirements gathering, testing), software complexity (and how to minimize it through good architecture and processes), general engineering principles (redundancy, fault-tolerance, solving problems early in the dev process...).

To me at least, the one that is neglected the most is the third one, "software-engineering concepts." Being able to think about systems at a high-level and well at the detail-level is one the most useful skills for an engineer.

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

#47
Example masters: John Carmack, Jeff Dean, Bram Cohen. What do they do? I think they're all extremely effective at getting things done. So be smart, hard working, and laser focused on shipping.

A long time ago I saw a good talk by Jonathan Blow wherein he made a point that really resonated with me. The point was that to get good at programming you need the experience of shipping a lot of programs and thus you should optimize your career around shipping as many good programs as you can. Contrast this with the common advice of being an expert in databases, or distributed systems, or OOP, or testing, or something like that...

Edit: found the talk: https://www.youtube.com/watch?v=JjDsP5n2kSM

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

#48
post #26

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?

OP is giving a problem solving framework, it's not tied to specific solutions or tradeoffs. It's more of a method for thinking through a solution.

In more detail, the steps go like this.

Find as many solutions to a given problem as you can. Bad engineers run with the first solution that comes to mind, letting confirmation bias drive them.

Evaluate each solution for its costs and benefits. Imagine two steps in the future when the solution is implemented. What pains are there?

Search for creative new solutions that create win-win scenarios. That's riding the solution curve.

Given all viable scenarios, compare the costs and benefits against the quality measures for your specific context. Some projects value speed over precision. Some projects value performance over extensibility. Some solutions are easier to change later than others. This is choosing a specific point on the solution curve that best fits your context.

You can apply that method of problem solving to any problem, large or small. You don't need a ton of experience to practice it.

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

#49
post #25

Highly competent in at least 3 languages; general understanding of 5 others; good written communication and presentation skills; able to create gui; understanding of distributed systems and networking; unix command line; can at least rebase in git

Why on earth would number of languages have anything to do with it. That doesn’t make sense. Parochial number of languages doesn’t capture the idea of understanding multiple paradigms, low level / high level, type system considerations. A person might have zero experience except Node.js yet still show high mastery of functional programming, mixed OOP, design patterns, compilers, etc. Setting any threshold on language…

It’s just a simple and objective yet general measure of mastery

If you have these skills there is a very high likelihood that you can do most other things that are thrown at you

Most of the other answers have all these high level wishy washy specifications, I thought I’d take a more brass tacks approach.

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

#50
I recently got a masters in software engineering, not that this means I've mastered the discipline, but I think it set a decent idea of what is important.

Here's a incomplete list of topics that I is worthwhile:

Creating a data schema (sql, no-sql, api based, whatever). This seems simple and obvious, but it becomes very hard very fast, especially when you need to model a complex subject that you know nothing about. Consider being hired by a hospital to model their records, or an insurance company. You need to talk to many people and understand how everything they say and do relates to everything else.

Project management: You may not want to be a project manager, but you should familiar with scrum, agile, waterfall, lean, and kanban. At least you can have an informed opinion when you argue for or against how things are done.

QA: You should know how to write a test plan for a large feature or application. This includes unit tests, manual testing, deciding what areas need more effort because getting it wrong is very bad and what is less important. This may include security and performance testing.

Architecture and design: How would you design a new application? How would you add a new feature to an existing application? How do you communicate this design to a team or many teams?

How to evaluate new things like languages, tools, libraries, technologies, etc. This isn't just reading a couple blogs, this is doing small scale test, proof of concepts, looking at the code to an extent, getting opinions for others you trust.

Finally, communicating. Software engineering is a team sport. You need to know how to write design documents, test plans, maybe architecture plans, progress reports, etc. If you can't effectively communicate your designs, plans, or even why someone else's thing is bad or good, you won't be able to convince others that you are right. And remember, you need to not just convince your peers, but also non-technical people, such as managers, VPs, and many other.

Post reply on HN