Comment by baron_harkonnen | Hacker News Reader

Comment by baron_harkonnen | Hacker News Reader

Parent Full thread

baron_harkonnen

My experience has been that the value of very senior technical staff is not that they solve "extremely high level" technical problems but they are very easily able to see how what appears to be a complex problem is isomorphic to a much simpler, easy to solve problem.

The difference between expert and advanced/intermediate technical staff is that the advanced engineer has an understanding of complex solution and mistakenly tries to apply them everywhere, so the net effect is to increase complexity. The expert typically sees simple solutions and method of resolving complexity and has a net effect of reducing overall system complexity.

Believing that the value add of experienced technical staff is to only solve really hard problem is likely caused by having too many advanced/intermediate people playing the role of experienced technical leads. All of the great technical team member I worked with always make call solutions simpler and easier to implement by knowing exactly what doesn't need to be done and what is essential.

Much of the last 2 decades of my career has been as much principal work as I can get, and everything I know says you smacked this ball out of the park.

First, if the title is real, then the term Principal carries serious weight, and hews as closely as possible to the best definitions of Principal Investigator (yah, academia has been busy making a mess of that)

More often than not, a good PI knows that all problems don't need the most powerful solution, some just need to go away. If a claimed principal is always applying the most complex solution everywhere, then they're bad at their job.

A good 1/3rd of my benefit is not going 'zomg - a hard problem' to my co-workers, its the exact opposite. And even when it is a hard problem, at least half the time then it's 'Don't worry - here's what Djikstra/whomever did to solve it'

I love advanced algorithms, and relish the chance to actually go try and make ones - that said, my main value is not that, its that some horrible new problem erupts, my job is to say, 'no, calm down. That's an old problem in a new suit'

That said, switch isomorphic to homomorphic - I'll give the seniors credit, they usually tag the isomorphic cases . :-)

Solving NP problems every day.

The fact that folks can't even agree on what constitutes a very senior IC is definitely part of the problem. I would consider what you describe here -- reducing complexity as opposed to increasing it -- a requirement of any senior engineer. I don't see this as the hallmark of a principal or distinguished engineer but rather one of the basic differences between a developer and a senior developer.

As my employer has tried to define the principal IC roles, I've actually seen the perceived qualifications of the original roles go down. IE, what would have been consider senior qualities are now principal qualities, and seniors need supervision. I believe it extends from the same root cause: not knowing how to get value out of a more senior role.

I had senior in my title at my previous organisation. Something I found hilarious given my years.

The reasoning seemed to be autonomy. Until they hired people who were senior by age but not autonomous.

Engineering titles are a mess and it causes real problems when moving to another organisation.

Something that explains this quite well (IMO) is the Dreyfus model of skill acquisition. You’re essentially talking about the difference between a proficient engineer and an expert, but I also think you’re suggesting there’s a 6th level: mastery.

The beauty of the model, to me, is in the separation of skills. Being an expert programmer doesn’t make you an expert in mentoring, or leadership, or architecture sometimes, and if the place you work has any flexibility with its career setup, there’s plenty of opportunity to branch out once you think you’ve maxed out your current tech tree.

... or you quit and get paid more elsewhere/go consulting/whatever ...

Would love to hear some examples of experts decreasing complexity and advanced engineers increasing complexity.

A hypothetical example would be one person spending a week or two setting up an extensive in-house Spark cluster to solve a problem that a second person in one day realizes can be solved on one machine using some clever shell scripting tricks. The former person knows a lot and may have been fully capable of the solution the second came up with, but they followed the wrong guiding principles in analyzing the problem and arrived at a solution of considerable complexity.

An alternate formulation of this would involve the second person above arriving at a new job, observing that they're using Spark on an expensive cluster to regularly perform a computation, and noticing that actually they could do the whole calculation on a single node using simpler tools.

You could answer that example problem just by being someone who reads Hackernews a bunch, since the "replace spark cluster with random unix tools" article appears here regularly. IMO, that doesn't really define being a principal engineer, it's basic.

I don't even agree that this is a defining quality of a principal engineer. This is part of our standards for a senior developer, and it's something we coach people on from the get-go.

Principal engineer: arrives at company, notices expensive Spark cluster, replaces with one server running shell scripts

Double digit-strong data science team: speechless

Thanks for the example. Once I did some analytics consulting with a stealth startup with some very talented engineers. One of them was usingusing rsync to replicate their data from their eng server to the analytics server, and I (not a software engineer, but familiar with shell) was initially like "that's it? You're just using rsync instead of <complex, paid replication tool>?" But it was the simplest and most straightforward tool for the job.

Designing a delta-sigma modulator.

Team engineers: we need a high-speed design with advanced adders and someone who can do the difficult static timing analysis.

Expert: No, you need someone who actually understands VLSI design who can interleave time and space in an algorithm. At that point, you can basically use a single step up from stupid-simple ripple carry adders. And if you use non-overlapped clock generators you don't even have to do static timing analysis. The biggest wins are in architecture, not implementation.

Yeah, 33MHz design in 125nm means VLSI like it's 1999.

There's Juicero https://blog.bolt.io/juicero/

Reply on news.ycombinator.com