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

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

#181

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

INTPenis wrote: post #153

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, .ne…

Just so. A lot of the problems have already been solved before anyone starts typing code.

It is SO common in this industry for people to literally not know what some software is meant to do, and just start typing code anyway. There's an entire software philosophy, "agile", based around that. If it IS known in advance what the software is meant to do, the quality of software that can be created is just astounding.

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

#182

Post by mechEpleb » Thu, Jan 07, 2021, 10:00 AM UTC

Cthulhu_ wrote: post #174

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

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.

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

#183

Post by mechEpleb » Thu, Jan 07, 2021, 10:05 AM UTC

plutonorm wrote: post #177

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…

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.

Can't have pesky engineers with their pedestrian technical concerns mess with the business decision makers' thought process. A good engineer takes whatever the creative, smart visionary comes up with and implements it down to the smallest detail.

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

#184

Post by phendrenad2 » Thu, Jan 07, 2021, 10:06 AM UTC

Mastery of software engineering means, given any task, you can do it, at any point along the fast/correct/cheap triangle gradient. In a corporate environment, you might lean toward fast and correct. In an open-source context you may lean toward correct and cheap. At a pre-funding startup, building an MVP, you may go with fast and cheap.

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

#185

Post by mechEpleb » Thu, Jan 07, 2021, 10:08 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.)

An engineer's job is to solve a problem creatively, not execute a rote technical procedure. The people who are just fed detailed instructions to execute are called "technicians" in the traditional industries. If you want to claim the title of an engineer, act like one. If all you can do is write code to spec, you are a technician.

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

#186

Post by friend-monoid » Thu, Jan 07, 2021, 10:09 AM UTC

phendrenad2 wrote: post #184

Mastery of software engineering means, given any task, you can do it, at any point along the fast/correct/cheap triangle gradient. In a corporate environment, you might lean toward fast and correct. In an open-source context you may lean toward correct and cheap. At a pre-funding startup, building an MVP, you may go with fast and cheap.

I think a better wording is “you can learn how to do it”; treading new waters is a daily task for software engineers.

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

#187

Post by jonathanstrange » Thu, Jan 07, 2021, 10:10 AM UTC

Masterful code has some kind of straightforward simplicity. Every function does one thing and does exactly what it is supposed to do. Everything is very predictable and boring. You can see from the code how clearly the programmer was thinking and how well the program structure was planned.

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

#188

Post by healsjnr1 » Thu, Jan 07, 2021, 10:23 AM UTC

conductr wrote: post #147

arcticbull wrote: post #142

Earlier quoted context omitted.

Part of what it means to be a senior engineer is that you have a mastery over the soft skills/people skills commensurate with your engineering abilities. Someone who knows how a bridge should be architected but cannot navigate the politics of city council necessary to get it built isn't much of a bridge builder. The importance of good politics cannot be understated. Politics in this case is roughly defined as getting…

While your bridge analogy is true, I feel it's even more valuable to have an informed view for what's on the other end of that bridge. If you work the politics and use all the right materials to build an efficient bridge that's great. But a wonderful bridge to nowhere is still a bridge to nowhere. I say this because as a finance guy, I've been on lots of projects that look great on a spreadsheet and marketing, sales,…

That sounds amazing, sadly in a lot of organisations that isn't how it pans out.

Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out.

The crux of this is that many of those people who carry the weight in decision making don't actually carry any risk or responsibility for delivery. Given the scale of engineering and time to deliver, by the time it comes to fruition they've moved on, so they never experience accountability for ignoring the advice.

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

#189

Post by conjectures » Thu, Jan 07, 2021, 10:29 AM UTC

arcticbull wrote: post #142

bedobi wrote: 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.

Part of what it means to be a senior engineer is that you have a mastery over the soft skills/people skills commensurate with your engineering abilities. Someone who knows how a bridge should be architected but cannot navigate the politics of city council necessary to get it built isn't much of a bridge builder. The importance of good politics cannot be understated. Politics in this case is roughly defined as getting…

Unfortunately this assumes that the politics of the city council is somewhat outcomes focused. If the mayor is intent on awarding the contract to her uncle no amount of 'soft skills' will help (and attempts to apply them may be counter-productive).

It's usually helpful to have an internal locus of control, and look for things in oneself (here, soft skills) that can be changed. However, sometimes reality just doesn't afford opportunities in a given situation. Accepting where that is that case means being able to extract oneself from a situation rather than wasting time on it.

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

#190

Post by habosa » Thu, Jan 07, 2021, 10:30 AM UTC

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 their will if they need to. At the same time, they know the difference between a great low-level solution and a shoddy hack.

  * Our industry is one of the few where we spend the majority of our time fixing our own mistakes. We call these mistakes "bugs" but they don't just appear, we produce them. The best engineers produce fewer bugs than they fix and rarely end up in a "whack a mole" situation where fixing one thing breaks another thing.