Ask HN: What has made you a better problem solver in software engineering?

Throwing away assumptions and trusting nothing, where it makes sense to do so. I've been burnt too many times by library bugs, framework issues and the other layers between me and what I'm actually doing. When I first started out I used to think that browsers such as Chrome were infallible and any problems had to be with my code.

As a result of being burnt, I'm happy to give up on logging and trawling through code in favour of just taking a PCAP and finding out what's actually going on over the wire. Or stracing my app written in a high-level language which runs in a VM. Sometimes you just want to see the syscalls.

I'm also happy to go digging in the browser's source code. I think my favourite bug to diagnose manifested as a visual issue with menus in a frontend framework. The menus were styled with some CSS, nested inside a media query:

    @media (hover: hover) {

These styles were only supposed to apply on desktop devices with a mouse pointer capable of hovering over HTML elements. The rules seemed to apply on some OnePlus devices though, with just a touch screen as an input device.

Getting to the bottom of this involved creating a test page to reproduce the problem, reproducing it in multiple browsers, digging into Firefox for Android's source code (yay FOSS) to find out how it implemented the media query, writing an Android app to reproduce the underlying data problem and eventually working out that it was a problem in the phone's operating system.

Some things that have helped me:

1. Look at prior art. Many problems have been solved before. It can be more fun to dive in and create your own solution, but looking for previous solutions first often saves time, results in a better solution, or may show you that you don't need to write the code in the first place.

2. Write down the problem you are trying to solve before solving it.

3. Solve the problem multiple times before committing to a final solution (if you have time). Unless the problem is familiar, your first solution will not be the best one.

4. Learn when to ask for help. This depends on the scale of the problem, but in general if you aren't making progress within half a day, consider asking someone else for their help and ideas.

5. Do rubber duck debugging. People who talk through problems aloud are better problem solvers and learners. https://www.teachervision.com/problem-solving/think-aloud-st...

6. Make documentation easily accessible. Some recommend spaced repetition like Anki (https://sivers.org/srs) to recall library functions and patterns. I've found that just having locally cached documentation in an app like Dash (https://kapeli.com/dash), Zeal (https://zealdocs.org/) or Velocity (https://velocity.silverlakesoftware.com/) to be a big help, especially if you don't just work with one language every day.

7. Do programming puzzles. I've found it helps a lot with software maintenance and other problem solving at the micro level. (It doesn't generally help with big systems design because puzzles tend to be smaller in scope than that, but a lot of our work is maintaining existing code.) I find https://exercism.io/ the best for this because you usually complete puzzles in the same environment you'll use for daily work (your text editor/IDE of choice), rather than in a web-based environment with limitations.

8. Consider courses like HtDP (https://htdp.org/2018-01-06/Book/ ) and the Clean Code series (Clean Code, The Clean Coder, Clean Architecture) for basic advice on structuring systems. Find others at https://mustread.tech/books

9. Make things. Keep them small in scope to begin with so that you finish some of them.

10. Surround yourself with brilliant people. Feeling like the dumbest person in the room is intimidating but you learn more.

11. Read and learn outside of the field of software. In the words of Feynman, “everything is interesting if you go into it deeply enough.” I like In Our Time (https://www.bbc.co.uk/programmes/b006qykl) and https://www.thegreatcoursesplus.com/ and https://www.masterclass.com/.

12. Look after yourself. Eat well, sleep well and exercise.

The book “Stop Guessing”.

Big picture: experience is the main way to get better at this. That, plus watching what more experienced folks are doing.

In terms of smaller strategies:

I think stepping back and asking "What is the real problem that needs to get solved here?" is very often the best thing to keep in mind when I'm stuck. Along with "How important is this, really?" These kinds of questions help you to evaluate whether a particular technical roadblock is actually worth solving, or whether perhaps it is not worth the time investment because some other solution (or just walking away) would be a better choice.

Also, I don't know if you need to hear the clichés, but context switching is a huge and important strategy for problem solving — whether rubber duck debugging, talking to colleagues, switching to another medium for thinking (like a white board), or just going for a walk around the block — these are often good ways to get unblocked.

Failing and redoing. On what doesn't really matter, I've found, just pick any area and don't be afraid to redo whatever you were doing.