Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

61–68 of 68 posts

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

#61

Post by ReDeiPirati »

Here's what is working for me:

- Never stop learning! Luckily, nowadays we have plenty of resources(HN, technical books, podcasts, etc...) we can use to improve Domain Knowledge on a subject, this is extremely important because it will create the hypothesis set we can query to solve problems later.

- Being resources constrained. Working with too many degrees of freedom is not only a common UX antipattern but also a way to kill creativity. If it's possible in your company, I strongly recommend doing technical customer support twice per month. Imho, this is a great setup to improve your problem-solving skills.

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

#62

Post by lol768 »

lexicality wrote: post #37
lol768 wrote: post #21

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…

To be honest, for me the point where you discover "this media query does not behave correctly on this device that I need to support" is where you stop digging and find a different solution for detecting pointing devices. It's very clever that you managed to discover a bug in OnePlus's version of Android but then what?

> To be honest, for me the point where you discover "this media query does not behave correctly on this device that I need to support" is where you stop digging and find a different solution for detecting pointing devices.

It enabled me to go back to the customer and explain the problem and make the informed decision to not continue work on the problem. The fact is that the broken OnePlus devices (not all of them, and not all the time) represent a very small proportion of the devices we need to support.

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

#63

Post by tanseydavid »

patrickthebold wrote: post #12
archeantus wrote: post #10

Things got a lot better for me when I realized almost nobody gets to the best solution on the first try. Cobble together an ugly and hacky solution that you can confirm solves the problem, then iterate and iterate until you clean it up well enough to ship it.

Or just ship it, and write a ticket to clean things up 'later'.

Funny and sad, because it is true. This practice is very commonplace.

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

#68

Post by ajb »

mpfundstein wrote: post #54
ajb wrote: 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?

Oops, forgot this thread. The short answer is:

- In bayesian search theory a good (sometimes optimal) approach is to maximise information gathered per unit effort

- In debugging, a step can vary by several orders of magnitude in amount of effort required to check a theory (eg, from 'type ls' to 'spend several hours implementing a theorised fix/tracking framework/etc)

- Consequently, the probability of a hypothesis can be quite low and still be the optimal thing to check first, if the effort to test it is also low.

So, the 'one weird trick' is to look at all the evidence you can look at very quickly, even if the connection to the problem is tenuous. 95% of the time the tenuous ones don't pay off, but when it does, you're colleagues are like 'WTF? how did you think of that?' and as advertised, you look like a genius.

Post reply on HN