Ask HN: What 'deeper technical skills' make up a strong engineer?

[iamstupidsimple]

A lot of online software industry content is focused on junior engineers: algorithms and data structures, usage of SQL, etc... But I don't think we often discuss what really sets mid/senior engineers apart.

My list would probably look something like:

- ability to use a proper debugging stack (not just tests/printf, use of microbenchmarks for optimisation, systems tracing for services)

- optimisation of how their app interacts with the environment (kernel, network stack, cache lines)

- debugging beyond application level issues (e.g. ability to use core dumps, knowledge of how the JVM works)

[soren1]

Questioning the end-user value of technical decisions (or more broadly, aversion to complacency). It's easy to give merit to past decisions: "this feature is obviously necessary otherwise it wouldn't be there, even though I can't understand how this is useful to anyone". I believe a stronger engineer won't let this slide, especially if the feature is proving painful to support.

I've seen others (and have myself) supported costly features of questionable value. Sometimes a few conversations with product managers and customers have resulted in us entirely dropping a feature.

[robomartin]

Imagination. Problem solving. Ability/desire to learn. Non-dogmatic. Excellent communication skills. Exposed to and experience in a range of domains (this could be through hobbies, not necessarily work). Thrives --rather than crumbles-- when things don't go well. Not afraid to admit not knowing something. Not afraid to ask for help (in some ways that's about not being egotistical). Good sense of humor.

I could go on.

Notice I didn't mention any specifics (i.e., knows compiler xyz, can use 3D CAD tool abc, etc.). None of that matters. Virtually none of the tools and technologies I use today existed when I was getting started. A simple example of this are FPGA's.

What matters to me isn't what list of "tools and features" a person brings to the table but rather who they are and how they got there. Someone who has the right drive and approach can learn anything, and thrive. That, to me, is what makes a strong engineer.

A couple of decades ago I hired an engineer out of Intel. I though I was going to learn a bunch from him. Quite to the contrary. The guy had spent so many years living in a professional silo that he did not do well in an environment where you have to do more than one thing. At Intel all he did was design power supplies. He didn't even deal with suppliers and order parts, he had groups of people who did that for him. He also didn't do much in the way of PCB layout and did no embedded software at all. It was a very rough start with us. He required a tremendous amount of coaching. In the end what made him keep the job was a strong work ethic and the desire and willingness to learn.

[rramadass]

Well said.

A good attitude, persistence and willingness to "muddle through" Complex/Complicated/Foggy Requirements/Understanding to arrive at a solution is the prime requirement.

[Agingcoder]

A quantitative view of a system : how it scales, what's possible / not possible ( because of hardware, software, algorithms, etc).

Basically, by knowing quantitative bounds of your system, you can make much better / quicker decisions.

[a_square_peg]

I agree 100% - I think this ability to identify the bottleneck for the system becomes more important as you move up the rank because you don't need to be the one doing it but you do have to know what needs to be done.

[drooby]

Refactoring.

1. Being able to spot the point at which the cost of cleaning up convoluted and fragile code is lower than the cost of continuing to work with it. And evaluating that it’s worth the long term investment.

2. Actually being able to turn the ship around.

[FranksTV]

Also:

Knowing when the cost of cleaning up convoluted and fragile code is higher than the cost of continuing to work with it, and when it's not worth the long term investment.

[donutshop]

IMO, the ability to solve business problems without over complicating things.

[StopDarkPattern]

Incredible how many teams and companies let X, Y, and Z make things incredibly complex without there being a real need or delivered value.

[contingencies]

1. Recogition of all engineering problems as effectively human problems that must be tackled with an eye on the human domain (resources, time, people, maintenance, ecosystem lifecycles, dependencies).

2. Ability to comfortably and independently iterate within unfamiliar problem domains and reason about potential solution paths at varying confidence intervals.

3. Ability to break a complex problem in to multiple smaller problems and document the rationale and assumptions for doing so, with a particular eye to interfaces, maintainability and the human domain.

4. Writes clear documentation and enjoys it.

5. Errs toward solving categories of problems rather than instances thereof, but understands how and when to yoke this tendency.

[LatteLazy]

Ability to communicate clearly.

Ability to communicate clearly to a non technical audience.

[bsaul]

Being able to create a synthetic and graphical visualization of the problem they're working on.

Engineers draws plans of their problems, and use them as a starting point for discussion and thinking about design.

Everytime a software developer in my team fails to represent a problem graphically i know they're limited.

[sriram_malhar]

Having a clear set of expectations before debugging or profiling.

One of my colleagues from whom I learnt much used to put assertions instead of print statements and rerun the test suite. Sometimes those assertions were quite complex; they would do a few sanity checks of entire data structures.

While doing benchmarking or profiling, knowing to do back of the envelope calculations to know the minimum and maximum metrics, such as IOps, messages per second, the average queue lengths, database writes and so on. The same colleague above had it honed to a fine discipline. He had memory and cache and db query latencies in his head and could tell if and where something was not right.

[ozzythecat]

Ability to step back and look at features, constraints, and have strong opinions on:

“Are we working on the right thing?”

“Is this valuable to work on, right now?”

“Is doing what I am doing the most effective use of my time?”

“How cheap or expensive is it to support what we’re doing? Is feature X worth its cost?”

“Is there opportunity to simplify the solution? Should we reduce scope? How?”

I think in my mind, it’s not always about the tech stack or a specific technical optimization so much as thinking in terms of costs, trade offs, and most importantly, why do something.

On other thing is being able to work with legacy code or code written by others. If your immediate solution is to rewrite something, you lose some points with me.

[ericb]

Superior googling abilities.

I'm not joking.

[jasfi]

This is how to pose a question in a way that generates meaningful results. It goes beyond Googling and is definitely a great skill.

[bayareabadboy]

Substantial Linux knowledge. Comfort with cloud providers and terraform. Communication to explain trade offs and costs to non-experts.

[altdataseller]

I am someone who have managed and worked with bare metal servers my entire life, having never used AWS or any cloud provider.

[FranksTV]

Being senior also usually comes with some measure of specialization.

[hnrss]

I've never had to deal with core dumps or understand how the JVM works. Why are those worthwhile skills?

[Jtsummers]

"e.g." stands for "exempli gratia", which, in English, means "for example". Maybe dealing with core dumps or understanding how the JVM works hasn't been relevant to you, but for any competent (let alone "strong") engineer/programmer I'd expect them to have familiarity with a rough equivalent to those kinds of things for their own systems.