6 ms·

A honey-badger[1] approach to problem solving. So many people let themselves be "blocked". Rarely are they really blocked, they simply want someone to tell them

by sulam 9y ago

A honey-badger[1] approach to problem solving. So many people let themselves be "blocked". Rarely are they really blocked, they simply want someone to tell them the answer. This one personality trait has been responsible for a good 40%[2] of my success I'd say. I developed this skill because I literally had no one to ask for help with questions when I was learning software engineering, but I think anyone can develop it by simply not giving up when they hit a hard patch. I'm not saying not to use Stack Overflow -- that's a great way to get through the hard patch. But one thing that happens repeatedly for me (and I suspect for everyone) is that I'll get stuck and no one has left a written history of how to solve that problem. Honey badger reads the code of the library they're using. Honey badger learns to trace the packets. Honey badger reads logs. Honey badger learns gdb and strace. Honey badger doesn't hope in vain for someone on the Internet to play the role of deus ex machina, because they don't have time for that. Honey badger Keeps Going. [1] https://www.youtube.com/watch?v=4r7wHMg5Yjg https://www.youtube.com/watch?v=4r7wHMg5Yjg [2] my personal breakdown: 50% luck, 40% perseverance, 10% ability to retain details

wcarss 9y ago
A related skill is being strategic about what really needs to be done right now. If you hit a roadblock, some people will just stop. Some will ask around and stop if there are no easy answers. Some will persevere until they hit their head so hard against the wall that the wall gives way. Some people will check if this is really a critical thing to accomplish right now, and just work around it when it makes sense. This can be the difference between 100% done, six weeks late, and 95% done on time, with a small outstanding improvement left to complete. It may even be easier to do when other work is done first. Sometimes you can't go around it -- then the honey badger does surely take the day! But I've found (and seen) a lot of success in asking yourself / a Product Owner if a feature can be delayed, or even cut.
- Animats 9y ago
  Yup, that's "agile". "Shit early, shit often."
  - wcarss 9y ago
    I don't feel "agile" is the same as being smart about scope cuts, or about shaving yaks that aren't in the way, so I'm left feeling that your comment was ...a bit of a shitty place to drag the discourse. :) In other words then, I'm more inclined to think of what I was saying as that it may be better to hold off on shitting at all if you're having a hard time, than to decisively shit your pants long after you've left the toilet.
  - collyw 9y ago
    I always thought that "agile" was "you're doing it wrong".
- ksk 9y ago
  Well, its the age old pragmatism versus idealism dichotomy. One isn't better than the other, except sometimes.
pmiller2 9y ago
The danger here is that you have to make sure Honey Badger's manager doesn't see him/her seemingly making no progress toward a solution. Honey Badgers might be solitary animals, but software engineers are social creatures.
nwhatt 9y ago
I came in here to post exactly this. It's hard to demonstrate but I will take time to listen to a candidate if they have a horror story about debugging something painful. Occasionally there will be a post on HN about someone who debugged a compiler bug or a even a hardware bug, and it lifts my spirits.
mitchell_h 9y ago
This is basically my only skill. I just don't stop google'ing for answers. If i run into something I just keep working until it works.
- softawre 9y ago
  I think most of the problems a honey badger solves aren't google-able.
  - shermanyo 9y ago
    Parent comment could refer to self study in a domain until they know enough about what's in front of them to better tackle the problem.
jbryson3 9y ago
I agree with this wholeheartedly. As an engineering candidate, how do I display these traits? As an interviewer, how can I test for these traits?
- majormajor 9y ago
  > As an interviewer, how can I test for these traits? This is one trick I haven't figured out. I can ask problems that require tenaciousness to dig all the way to the bottom. BUT motivations and incentives in a 45min interview and an ongoing job are very different. There's a higher reward in the job interview, and you know an upper bound to how much time it'll take. I've hired people who aced that, but then were pretty lazy day to day, even for looking up trivial stuff like "you submitted a python code review that wouldn't even run because you made a typo in the method name." Stories can help, but stories are (even assuming true and not borrowed) from a past version of the candidate which may not be the same as the present version. So I just do the best I can, but also recognize that I won't necessarily get a 100% perfect employee no matter what questions that I ask. But "pretty good" is about all you can realistically hope for, I think.
  - himom 9y ago
    You need to be your own honey-badger. :) There are two very important tests to consider hiring someone: - how a candidate handles feedback and negative situations like disapproval and rejection - whether they delegate thinking or take ownership of solving hard problems If they fail either, that’s a deal-breaker. Also, make the candidate pipeline as uniform, fair and repeatable as possible. - anonymizing resumes by masking pedigree, names, addresses, etc. - ask generally the same questions, while branching differently based on their responses - perform social and skills tests as similarly as possible ”Be the change you seek”
- chc 9y ago
  In my experience, a lot of interviewers will ask questions along the lines of "What's the trickiest problem you've had to deal with?" I feel like those kinds of questions are excellent for bringing up this sort of thing if the candidate is so inclined. If they go in a different but still not disappointing direction (e.g. coming up with a process for stable development an environment where requirements are constantly changing), you might re-ask with the focus more on problems encountered while coding.
volkk 9y ago
Great skill, but a far better skill is knowing when to give up and move on from the problem instead of wasting days on something while other backlog work piles up.
- ksk 9y ago
  Well that applies to every task, not just to problem solving. "Work hard" doesn't imply "neglect your wife and kids".
- stocktech 9y ago
  That's a good way to only be assigned easy tasks.
ashleyn 9y ago
I developed this skill because of a combination of social anxiety and wanting to keep my first job.
Animats 9y ago
It's a useful skill, but not a good career move. Early in my career, I used to fix bugs in a mainframe operating system. When I took a new job, I was given two stacks of paper crash dumps, each six feet high. I had to figure out what had caused each crash with paper and pencil, then fix the assembly code. It took me about a year to get the mean time to failure of the OS from a day to a month. Often, you can't find the problem, but you can find a point where checking code will trap the problem earlier. Slowly, crash by crash, you work backwards to the source of the problem. Eventually you can find the root cause. I got out of that after a few years and into the more theoretical end of computing, including proof of correctness. It was useful, though, to learn what makes software unreliable from the bottom. (This is part of why I'm so down on unsafe code in Rust. Rust has a good safety system. There are people with an attitude that "I'm so l33t I don't need the checking." They're not. They may create something which imposes a safety constraint on the caller, and later, someone else violates that constraint and creates a memory corruption bug. They write code which has an implicit undocumented invariant which is violated when someone else makes a later change. Those are bugs waiting to happen.)
AdamM12 9y ago
As someone who is an alt student, working as SFE while going to school at a traditional University, I've noticed the opposite of this mentality a lot. Expectations of being told how to do everything and literally getting upset when the prof doesn't give them enough. Will note though the guys who are also alt students, surprisingly higher than I remember/noticed when doing my first undergraduate, tend to not have this mentality and are usually the people I talk to when I am really having issues. Feel like this is something that took me entirely too long to learn or at least too long to realize that I needed to learn it. I'm sure I was the same way when I was 19-22. Just thought this comment stood out don't care to get into the failings of academia.
spacemanmatt 9y ago
I think my relative success comes down to one basic thing: When I learn new things, I focus on essentials first, and always. I gain normal skill like anyone, but I do feel like I retain the essentials better than the next hacker. I can't recall a time I've ever said, "oh, I used to know _____ but it's been too long." I've always been able to get back into old saddles. It's been like this most of my 25 years in the industry.
- spacemanmatt 9y ago
  Relevance: retaining essentials confers ability to honey-badger more things in more ways.
collyw 9y ago
I agree that these are useful ways of solving problem, but its rarely that anyone asks about that sort of skill in an interview.

by sulam 9y ago

wcarss 9y ago

A related skill is being strategic about what really needs to be done right now. If you hit a roadblock, some people will just stop. Some will ask around and stop if there are no easy answers. Some will persevere until they hit their head so hard against the wall that the wall gives way. Some people will check if this is really a critical thing to accomplish right now, and just work around it when it makes sense. This can be the difference between 100% done, six weeks late, and 95% done on time, with a small outstanding improvement left to complete. It may even be easier to do when other work is done first. Sometimes you can't go around it -- then the honey badger does surely take the day! But I've found (and seen) a lot of success in asking yourself / a Product Owner if a feature can be delayed, or even cut.

Animats 9y ago
Yup, that's "agile". "Shit early, shit often."
- wcarss 9y ago
  I don't feel "agile" is the same as being smart about scope cuts, or about shaving yaks that aren't in the way, so I'm left feeling that your comment was ...a bit of a shitty place to drag the discourse. :) In other words then, I'm more inclined to think of what I was saying as that it may be better to hold off on shitting at all if you're having a hard time, than to decisively shit your pants long after you've left the toilet.
- collyw 9y ago
  I always thought that "agile" was "you're doing it wrong".
ksk 9y ago
Well, its the age old pragmatism versus idealism dichotomy. One isn't better than the other, except sometimes.

pmiller2 9y ago

The danger here is that you have to make sure Honey Badger's manager doesn't see him/her seemingly making no progress toward a solution. Honey Badgers might be solitary animals, but software engineers are social creatures.

nwhatt 9y ago

I came in here to post exactly this. It's hard to demonstrate but I will take time to listen to a candidate if they have a horror story about debugging something painful. Occasionally there will be a post on HN about someone who debugged a compiler bug or a even a hardware bug, and it lifts my spirits.

mitchell_h 9y ago

This is basically my only skill. I just don't stop google'ing for answers. If i run into something I just keep working until it works.

softawre 9y ago
I think most of the problems a honey badger solves aren't google-able.
- shermanyo 9y ago
  Parent comment could refer to self study in a domain until they know enough about what's in front of them to better tackle the problem.

jbryson3 9y ago

I agree with this wholeheartedly. As an engineering candidate, how do I display these traits? As an interviewer, how can I test for these traits?

majormajor 9y ago
> As an interviewer, how can I test for these traits? This is one trick I haven't figured out. I can ask problems that require tenaciousness to dig all the way to the bottom. BUT motivations and incentives in a 45min interview and an ongoing job are very different. There's a higher reward in the job interview, and you know an upper bound to how much time it'll take. I've hired people who aced that, but then were pretty lazy day to day, even for looking up trivial stuff like "you submitted a python code review that wouldn't even run because you made a typo in the method name." Stories can help, but stories are (even assuming true and not borrowed) from a past version of the candidate which may not be the same as the present version. So I just do the best I can, but also recognize that I won't necessarily get a 100% perfect employee no matter what questions that I ask. But "pretty good" is about all you can realistically hope for, I think.
- himom 9y ago
  You need to be your own honey-badger. :) There are two very important tests to consider hiring someone: - how a candidate handles feedback and negative situations like disapproval and rejection - whether they delegate thinking or take ownership of solving hard problems If they fail either, that’s a deal-breaker. Also, make the candidate pipeline as uniform, fair and repeatable as possible. - anonymizing resumes by masking pedigree, names, addresses, etc. - ask generally the same questions, while branching differently based on their responses - perform social and skills tests as similarly as possible ”Be the change you seek”
chc 9y ago
In my experience, a lot of interviewers will ask questions along the lines of "What's the trickiest problem you've had to deal with?" I feel like those kinds of questions are excellent for bringing up this sort of thing if the candidate is so inclined. If they go in a different but still not disappointing direction (e.g. coming up with a process for stable development an environment where requirements are constantly changing), you might re-ask with the focus more on problems encountered while coding.

volkk 9y ago

Great skill, but a far better skill is knowing when to give up and move on from the problem instead of wasting days on something while other backlog work piles up.

ksk 9y ago
Well that applies to every task, not just to problem solving. "Work hard" doesn't imply "neglect your wife and kids".
stocktech 9y ago
That's a good way to only be assigned easy tasks.

ashleyn 9y ago

I developed this skill because of a combination of social anxiety and wanting to keep my first job.

Animats 9y ago

It's a useful skill, but not a good career move. Early in my career, I used to fix bugs in a mainframe operating system. When I took a new job, I was given two stacks of paper crash dumps, each six feet high. I had to figure out what had caused each crash with paper and pencil, then fix the assembly code. It took me about a year to get the mean time to failure of the OS from a day to a month. Often, you can't find the problem, but you can find a point where checking code will trap the problem earlier. Slowly, crash by crash, you work backwards to the source of the problem. Eventually you can find the root cause. I got out of that after a few years and into the more theoretical end of computing, including proof of correctness. It was useful, though, to learn what makes software unreliable from the bottom. (This is part of why I'm so down on unsafe code in Rust. Rust has a good safety system. There are people with an attitude that "I'm so l33t I don't need the checking." They're not. They may create something which imposes a safety constraint on the caller, and later, someone else violates that constraint and creates a memory corruption bug. They write code which has an implicit undocumented invariant which is violated when someone else makes a later change. Those are bugs waiting to happen.)

AdamM12 9y ago

As someone who is an alt student, working as SFE while going to school at a traditional University, I've noticed the opposite of this mentality a lot. Expectations of being told how to do everything and literally getting upset when the prof doesn't give them enough. Will note though the guys who are also alt students, surprisingly higher than I remember/noticed when doing my first undergraduate, tend to not have this mentality and are usually the people I talk to when I am really having issues. Feel like this is something that took me entirely too long to learn or at least too long to realize that I needed to learn it. I'm sure I was the same way when I was 19-22. Just thought this comment stood out don't care to get into the failings of academia.

spacemanmatt 9y ago

I think my relative success comes down to one basic thing: When I learn new things, I focus on essentials first, and always. I gain normal skill like anyone, but I do feel like I retain the essentials better than the next hacker. I can't recall a time I've ever said, "oh, I used to know _____ but it's been too long." I've always been able to get back into old saddles. It's been like this most of my 25 years in the industry.

spacemanmatt 9y ago
Relevance: retaining essentials confers ability to honey-badger more things in more ways.

collyw 9y ago

I agree that these are useful ways of solving problem, but its rarely that anyone asks about that sort of skill in an interview.