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

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

#231

Post by olikas » Thu, Jan 07, 2021, 1:49 PM UTC

J-dawg wrote: post #196

habosa wrote: 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…

I had a similar experience early in my career. To me it was eye opening to see some masters keep investigating problems without getting emotional. I learned how not to care about the time it takes to figure things out, but to start and carry on. This way given enough time, almost all problems are solvable. The time pressure doesn't change this fact.

In case of a time pressure, I just focus on workarounds instead of analysis. Once the problem is no longer burning, it's up to the project priorities to investigate the root cause.

I also learned that panic never solved any of my problems, so when I notice that I am moving into panic mode, I stop for a minute and cool down. This is a skill that can be learned.

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

#232

Post by mstipetic » Thu, Jan 07, 2021, 2:09 PM UTC

JackMorgan wrote: post #209

mstipetic wrote: post #193

Earlier quoted context omitted.

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

I think that's an artificial split. Management is not only about HR busywork, it should also include all the things you've mentioned in the leader category.

Is it an official title? I keep seeing it everywhere now, everyone is a "leader." What exactly does it mean? Do you proclaim yourself a leader, is there some vote on it?

From my perspective it's completely meaningless and usually ego stroking.

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

#233

Post by jononor » Thu, Jan 07, 2021, 2:19 PM 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.)

Business is not outside the domain of software engineering. "building the right thing" is more important in engineering than "building the thing correctly". If the proposed solution or problem to be solved misses the mark, most of the potential value has been lost, and excellent execution will not be able to recoup that.

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

#234

Post by Daub » Thu, Jan 07, 2021, 2:22 PM UTC

A simple requisite of mastery in any domain is age. Not to say that young people can't be brilliant and impactfull at their craft. But such qualities fall more rightfully described as having flair. The difference between mastery and flair is that the former is more reliable and stable.

As an art teacher, I have seen many young artists go on to have great careers shortly after leaving school... but most of them burn out or fail in one way or another. Conversely... their aged teachers have acquired character, depth and stability but have in the process lost their wildfire.

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

#235

Post by PaulHoule » Thu, Jan 07, 2021, 2:24 PM UTC

bedobi wrote: post #122

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…

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.

I worked at one place that was a basket case and finally started to push back. The HR person seemed shocked that I was concerned with the business value of a project, but i had people telling me i wasnt worth what i was being paid -- I could show the next assignment had $0 in business value so if i spent more than 0 hours on it I'd just be digging myself a hole.

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

#236

Post by PaulHoule » Thu, Jan 07, 2021, 2:25 PM UTC

robertlagrant wrote: post #200

disgruntledphd2 wrote: post #195

Earlier quoted context omitted.

It depends on the organisation, to be honest. For instance, in my experience at a FAANG, the issue was often that a new technical solution was proposed, architected and built before any business/market people got involved with the result that loads of amazing, brilliantly architected and completely useless projects got built. (My favourite time was when a (really smart, to be fair) software engineer rediscovered the…

If you have a load of smart engineers, sometimes it can be a more successful strategy to just build something than to pay EY £250k to do market analysis, get a load of execs bought in who then will "make it work" even if it shouldn't, or kill it off even if they shouldn't, and then finally get a committee-written spec handed over to be built in a rush.

The FANG method of software dev is extraordinarily expensive, particularly at the G.

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

#237

Post by thelastinuit » Thu, Jan 07, 2021, 2:26 PM UTC

permille42 wrote: post #29

"Who is John Galt?" Mastery could most closely be viewed as a state of enlightenment. To the non-enlightened it will appear to be dismissive and lazy. There are a variety of positions one could take once reaching enlightenment: 1. Domination. One could choose to be controlling of the entire field and use it for selfish benefit. 2. Dismissive. Once you reach the pinnacle it becomes apparent that both humanity and the…

It reminds me of the Way of Tao

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

#238

Post by hyperpallium2 » Thu, Jan 07, 2021, 2:27 PM 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…

(just unpacking) Prediction of value, initially and over time, requires market analysis.

Given that, predicting which projects will produce that value, and which designs will accommodate future additions of value, is engineering.

I still like Parnas's On the Criteria to Be Used in Decomposing Systems into Modules, where the choice of "information hiding" requires predicting what is likely to change - and predicting value.

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

#239

Post by revskill » Thu, Jan 07, 2021, 2:31 PM UTC

Problem solving skills. It doesn't matter if your tool is the best, it only matters which tool is suitable for the job.

So the master to me is the one who knows which tools for which job !

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

#240

Post by conductr » Thu, Jan 07, 2021, 2:47 PM UTC

healsjnr1 wrote: post #188

conductr wrote: post #147

Earlier quoted context omitted.

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

True. I’ve witness all of these things as well. I’m not implying that organizational decision making is perfect if only it had better technical people providing inputs by any means.

Again as a finance guy, this is a major skill I have attempted to develop for myself/team. When projects spin up, I’m typically at forefront and involved in every project technical or not (controlling the purse strings). Many finance guys are know it all’s TBH. They build their ROI models, etc. and making dozens of assumptions it’s then treated as gospel. For some reason, it’s valid to ask “why is this project underperforming our expectations” but it’s often taboo to ask “did our expectations even make sense”. I try to change that where it exists too.

All to say, people like me find people at the onset of the project to gather inputs. If I know you as well versed with track record of valuable insights, I’m more likely to reach out early. If I have worked with you at this stage and you your input is just one of “we need specs/tell us what to build and we can build it” you’ve not added any value to the conversation and I’m likely to not include you next time because I know I just need to bring you specs once project is approved and that’s a different conversation for another day.

This is why I say “business partner”. Being able to understand your company, the politics within, how decisions are made, where you can inject value along the way. These are all traits of people with fast career growth in slower growing firms. You transform from Programmer #13 to people knowing and respecting your name. This is important in talent reviews, etc.