Live data from Hacker News

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

news.ycombinator.com

201–210 of 290 posts

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

#201

Earlier quoted context omitted.

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

Can anybody actually produce working code at the same pace as they touch type? Typing hardly registers as a factor when it comes to how long it takes for me to code anything, at least.

Depends on how often I’ve done something similar before.

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

#202
post #123

https://bellard.org/ Clean, well-documented projects showcasing demos that end up having huge impact. Some of these projects single-handedly spawned entire tech ecosystems. (see FFMPEG, QEMU, JSLinux)

Was about to comment with the same URL.

It's one "direction" of mastery. Software invention, at grand master level.

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

#203
The ability to master complexity.

A master will be able to understand the relationship between systems so he can reduce combinatorial possibilities and reduce complexity to a minimum.

In other words, a master will not shoot herself in the foot. She will also not let others shoot themselves in the foot.

Then, depending on what you do, you will need technical ability: -Understanding basic physics or economics or whatever you interface with your software. -Understanding of low level systems (assembler and C) -Understanding of different paradigms(objects, functional) -Understanding of very High level systems (Lisp, Haskell) -Understanding of serialization(parsing and binary) -Understanding communications. -Understanding data handling. -Understanding interfaces(like command line, desktop or Web). -Understanding standards.

But this depends on the particular work you need or want to do. You will be stronger or weaker in different areas.

But complexity handling is common to any area in engineering.

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

#204
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.

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.

There's another facet to this which I think is far more important that OP question of "What [exactly] does mastery 'look like'?".

The more important question is "how do you cultivate mastery?" How does your organization get to a place where people can develop mastery instead of the organization trying to create it instantly by hiring "the right people"? Regardless of what people may claim, hiring is not a solved problem. It's _really_ hard to identify candidates that are true masters at what they do (let alone getting them to quit their job and join your team).

By the same token, it's also _really_ hard for true masters to find a place that understands their value and, more importantly, will allow them to do their thing and provide career satisfaction. A lot of talented people are locked out of jobs because someone thought their career trajectory wasn't quite right/impressive.

Training and mentorship, however, are better understood and have lower stakes. It makes me think of Bell Labs. I know a couple folks who worked there who had very "unimpressive" backgrounds, they started as techs but rubbed elbows with stellar talent in a place that cultivated discovery and collaboration. Over time while there and in other places they were able to rise to principal design engineers, beyond what many who went to elite universities achieve. They credit their formative years in Bell labs with getting them started on their career path.

The thing is, Bell Labs didn't have an epically selective hiring process, nor was the compensation insanely high. They provided an environment that _attracted_ people with mastery and those who were passionate about what they do, they developed talent within their walls rather than trying to merely buy it or find it.

This was for electrical engineers, but the same ideas can apply to software engineers.

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

#205
IMO:

The ability to judge risk in terms of time and money.

The ability to judge the amount of security that is needed (a productive level that is still safe).

To think long-term, in terms of avoiding complexity buildup over time, and in terms of avoiding vendor lock-in.

To help others get up to speed.

To stay productive over time.

To stay open to learn something new.

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

#206
post #196
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…

It’s more a type of persistence I think. More junior people often ask me something along the lines of “How do you immediately know these things?”. But the answer isn’t anything magical. Generally one of:

1. I’ve run into the same or similar problem before.

2. I wrote the code that does this thing.

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

#207

Earlier quoted context omitted.

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

Can anybody actually produce working code at the same pace as they touch type? Typing hardly registers as a factor when it comes to how long it takes for me to code anything, at least.

Depending on what I'm working on, just dumping stuff to an IDE buffer at 70WPM can be 10% or more of the time something takes. Which is enough that typing slower would have a noticeable impact.

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

#208

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…

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

[deleted]

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

#209

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?

They're totally different words. I used to be an engineering manager with direct reports who wasn't really much a leader. Today I'm an engineering leader without any direct reports.

Leadership happens from the front and doesn't really have anything at all to do with year end reports and making sure everyone shows up on time. Management rarely does more than HR busywork. The way many engineering mangers work they often have skills so outdated as to be effectively non-technical.

Leadership can happen at all levels regardless of title. Leaders often are some of the most skilled technicians, able to have an outsized impact on both the team and the direction.

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

#210

Earlier quoted context omitted.

I fail to decrypt who TJ can be

TJ Holowaychuk, who has written some of the most popular Node.js libraries. Express.js is probably the one most have heard of. He now operates in the Go space in which I presume he also has some influence as well for OP to bother mentioning. I would say that his handiwork in crafting good libraries was a significant reason that Node took off like it did so quickly. This article from 2014 highlights just how many libr…

This might explain the 'we repurposed npm to manage go deployment' articles I saw recently ..
Post reply on HN