I think this is true for engineers as well! I enjoy getting to know the "theme" of my favorite coworkers over the years. There was:

* The fellow who always looked for the simplest hack possible. Give him the most annoying problem, he'd pause, go Wait a minute! and redefine it to have a very easy solution. He typed very slowly, but it didn't really matter.

* The one who truly loved code itself. He would climb mountains to find the most elegant, idiomatic way to express any program. Used the very best practices for testing, libraries, all that. He typed very fast.

* The former physicist who spent all his time reading obscure mailing lists on his favorite topics. His level of understanding of problems in his domains of interest was incredible.

I could go on and on! It's such a fun taxonomy to collect. All of these friends were marvelous at solving their particular flavor of problem.

As for myself, I like to think that my "trick" is to spend a long time poking at the structure of a problem. Eventually the solution I was looking for doesn't matter anymore, but the tools I developed along the way are pretty useful to everyone!

▲

philipov an hour ago | parent | next [-]

For me, it's tracing code/pipelines to figure out how a result was produced, typically in the context of that result being wrong somehow. Go To Definition is the most useful function in any editor.

I'm always surprised by how frequently colleagues don't think to do this and are left helpless.

	▲	tibbar an hour ago \| parent \| next [-]
		This reminds me of my further theory that everyone needs one 'heavy' and one 'light' technique. The 'light' technique is something that often works well as a heuristic and can be an effective unit of iteration. The 'heavy' technique is something that you can fall back on in difficult cases, something that can reliably solve hard problems, even if it's slow. Sometimes the heavy technique is: just ask someone else. ;)
	▲	cyberax 21 minutes ago \| parent \| prev [-]
		Another example: debuggers. It's amazing that a lot of new developers don't know how to use them at all! I'm not even talking about using the command line gdb, but just the basic "Set Breakpoint" feature and attaching to processes.

▲

tibbar 2 hours ago | parent | prev [-]

Here are a few more.

* The (brilliant) infrastructure engineer who described his modus operandi as 'I read stuff on Reddit and then try it out.' This engineer is now worth, as a conservative estimate, in the neighborhood of $50 million. So maybe more of us should be doing that.

* Another infrastructure engineer, also very effective, who made a habit of booking an external training session (sometimes a series, weekly) for how to set up and integrate every piece of technology we used.

* An engineer (this one is quite famous, and we have only interacted professionally a few times) who simply wrote the best comments in the world. Every method was adorned with a miniature essay exploring the problem to be solved, the tradeoffs, the performance, the bits left undone. I think about those comments quite often.

As an addendum, though, I will say that the best engineers overall all shared a trait - they kept trying things until they got something working. That alone will take you pretty far.

▲

malux85 2 hours ago | parent [-]

“The most successful people have failed more times than you have tried”

	▲	tibbar an hour ago \| parent [-]
		Yes. I like to think that all of the people above could have solved most of the same problems, albeit in wonderfully different styles, but what really guaranteed success was a commitment to just keep at it. Edit to add: Still, the styles matter a lot! For one thing, they greatly influence which problems each person is interested in. Also, the style you solve problems with colors what your final output looks like, which is perhaps more obvious in engineering than in mathematics.