Live data from Hacker News

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

news.ycombinator.com

51–60 of 68 posts

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

#51
Practice. A lot. Learn the whole stack (down to the hardware, understand failures modes and limitations of each layer).

Solve many different problems, make experiments and throw away code. Make connections between sub disciplines.

You have to have the attitude that if somebody understood this, then I can too, if nobody did, there's no good reason why I can't be the first one.

Fail a lot and learn. Think about every failure you had, but as a problem to solve not a comment on your value as a person/engineer. What could you have done differently? What were the signs that got you in that situation?

For tricky problems, what works for me is the obsess-and-let-go strategy. Work intensely on some problem for some time, if you make no progress, just let go of it, forget about it, do something else and perhaps your brain will connect the dots. Talk about the problem with other people. Explaining it and different points of view usually change your perspective enough that you are no longer stuck.

Also note that reading about something is not the same than doing it. You need to read and attempt to replicate, even if a toy version of the thing to better understand. Some things just take time an effort to seep in.

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

#53
post #39
post #34

Start at the bottom, make your bottom layers solid first. You can't reliably deduced anything about what your current problem is, if the things it depends on are flaky. Design by Contract. Understand it. Used it. Turn your asserts on always. Turn on all warnings that don't give false positives that your compiler / tools provide. Fix them don't mute them. Run around your code base and find every damn place where some…

My coworker is a fan of: try: something() # that throws nonfatal errors frequently except: pass "it saves time in development" they say. Good luck if something in that (non trivial) function call breaks. Ugh. Don't be like that. If you don't know the precise error, heres the solution (in python): except Exception as exc: log("{}: {}".format(type(exc).__name__, exc)) Bingo, you now know what to catch. Catch that error…

How can his code pass code review?

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

#54
post #14

Learn a little bayesian decision theory. Not because you need it for the solution of your problem, but because of what it tells you about the process of doing so. I've got a tongue-in-cheek presentation entitled 'How to seem a Genius at Debugging with this 1 Weird Trick' based on decision theory. One day I must write it up properly as a blog post.

So what is this 1 weird trick?

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

#55
post #51

Practice. A lot. Learn the whole stack (down to the hardware, understand failures modes and limitations of each layer). Solve many different problems, make experiments and throw away code. Make connections between sub disciplines. You have to have the attitude that if somebody understood this, then I can too, if nobody did, there's no good reason why I can't be the first one. Fail a lot and learn. Think about every f…

That's exactly the same advice I would give. Practice a lot and practice difficult things.

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

#56
post #34

Start at the bottom, make your bottom layers solid first. You can't reliably deduced anything about what your current problem is, if the things it depends on are flaky. Design by Contract. Understand it. Used it. Turn your asserts on always. Turn on all warnings that don't give false positives that your compiler / tools provide. Fix them don't mute them. Run around your code base and find every damn place where some…

> You can't reliably deduced anything about what your current problem is, if the things it depends on are flaky. Interesting, as a junior dev I always start thinking about the fun architecture stuff first and end up being slow to complete a project. I figure that deploying one place vs another is so different you want to deploy early and often for testing. Maybe I should just start getting the basic functionality and…

You need to start from both ends...

TDD to get the chunks of functionality you add rock solid..

A Walking Skeleton to guide your vision of where you're going... https://wiki.c2.com/?WalkingSkeleton

Each part you add must be rock solid before you move on to the next that depends on it.

That doesn't mean you have to do everything... merely make it solid and reliable.

Say you plan to depend on a subsystem that is going to do something wonderful and flashy.... but you don't need it right now, you just need to build the place where it's going slot in....

Then don't put your sketch of the wonderful shiny thing into your dependency tree, put a mock that might do nothing, but does nothing utterly reliably.

If you have something flaky firing bullshit events and rubbish into your whole system while you're trying to get the rest going... you're just going to hurt yourself.

You can add a feature toggle or chicken bit to switch the new shiny/flaky stuff in when you want to contemplate it, and switch it out when you're working on the rest of the stuff.

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

#57
Scientific method. I'm not being presumptuous.

When coming across a problem, I type out all hypotheses on a notepad.

Microphone doesn't work on app? Is it this device specifically? Is it the file system? Faulty recording code? Null pointer somewhere?

Then I find the simplest, hackiest way to (dis)prove the hypothesis. Be sure to narrow down the test as far as possible.

What a lot of people do is just bash random things, often the simplest hypothesis, repeat that same thing for half an hour, do something else, then repeat what they tried earlier. Or in somewhat tougher problems like pathfinding, where each hypothesis takes an hour to test, a lot of people get intimidated and procrastinate.

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

#58
Age. Without question, age has improved my problem solving abilities. I no longer expect to come up with an instant solution; instead I get to know the problem as best I can, then go and do something else. My subconscious will eventually deliver the optimal solution.

Interestingly, "eventually" usually means in the shower the next morning. From that I assume that I'm more receptive to flashes of inspiration while I'm relatively relaxed in the shower, and also that the real work of finding a solution happens while I'm asleep.

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

#59
post #58

Age. Without question, age has improved my problem solving abilities. I no longer expect to come up with an instant solution; instead I get to know the problem as best I can, then go and do something else. My subconscious will eventually deliver the optimal solution. Interestingly, "eventually" usually means in the shower the next morning. From that I assume that I'm more receptive to flashes of inspiration while I'm…

Couldn't agree more to this. Even having a small tea break or watching a youtube video for distraction helps a lot. I think its something about perspectives, we cannot focus fully on a given task and also look at it from a wider perspective or different angles at the same time, so taking a break and coming back gets focus on these angles which were earlier ignored. Kind of like "boxed thinking" which self help articles always talk about.

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

#60
post #15
post #11

Unpopular answer alert: Doing leetcode like problems on a semi-regular basis helps me a lot.

Just curious, in what way? Does your job require you solving problems like leetcode every some time?

It helped me a lot. I can write hundreds of non-trivial but well tested lines of code which passes all tests on the first try and is fit for code review in a couple of hours. I wouldn't be able to do that if I hadn't practiced competitive programming a lot.

This skill wont solve all of your problems, but if you have a lot of theories you want to test then your ability to implement them quickly is invaluable, and testing a lot of your theories is how you learn most of the other important skills related to software engineering.

Post reply on HN