8 ms·

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 a

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.

nilkn 7y ago
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.
- cpitman 7y ago
  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.
  - Normal_gaussian 7y ago
    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.
- deleted 7y ago
  [deleted]
MarkMMullin 7y ago
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 . :-)
- rzzzt 7y ago
  Solving NP problems every day.
ljm 7y ago
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 ...
oarabbus_ 7y ago
Would love to hear some examples of experts decreasing complexity and advanced engineers increasing complexity.
- nilkn 7y ago
  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.
  - saberience 7y ago
    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.
    - nilkn 7y ago
      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.
    - foobarian 7y ago
      Principal engineer: arrives at company, notices expensive Spark cluster, replaces with one server running shell scripts Double digit-strong data science team: speechless
  - oarabbus_ 7y ago
deleted 7y ago
[deleted]

nilkn 7y ago

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.

cpitman 7y ago
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.
- Normal_gaussian 7y ago
  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.
deleted 7y ago
[deleted]

MarkMMullin 7y ago

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

rzzzt 7y ago
Solving NP problems every day.

ljm 7y ago

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

oarabbus_ 7y ago

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

nilkn 7y ago
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.
- saberience 7y ago
  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.
  - nilkn 7y ago
    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.
  - foobarian 7y ago
    Principal engineer: arrives at company, notices expensive Spark cluster, replaces with one server running shell scripts Double digit-strong data science team: speechless
- oarabbus_ 7y ago

deleted 7y ago

[deleted]