Live data from Hacker News

Ask HN: What's the hardest problem you've ever solved?

news.ycombinator.com

31–40 of 124 posts

Re: Ask HN: What's the hardest problem you've ever solved?

#31
post #20

This is exceptionally hard to answer because for every problem I solve I tend to end up looking at my solution and thinking "That wasn't so hard. Why did it take me so long? Am I bad at this stuff?" To answer the question though, I think probably writing a robust web scraper to search events listings and turn them in to a sharable calendar. It'd be trivial these days but I did it in 1999 in Perl with regexs.

> "That wasn't so hard. Why did it take me so long? Am I bad at this stuff?"

Hah. Always. Hindsight bias and impostor syndrome are a fun mix! I remember writing a blog suite (with comments!) in Perl in the late 90s; back then, without S.O. and other knowledge-sharing beyond some Usenet forums, inventing the wheels as we went along... it was all hard.

Re: Ask HN: What's the hardest problem you've ever solved?

#33
Making a trainer for a game. For example: "infinite bullets". It would crash the game for weird reasons. I ended up patching many places of the executable to prevent the crash.

In the end I found out that I managed to write a crack for the game by accident :D Later on I inspected a crack from another team, it would patch the same regions!

Re: Ask HN: What's the hardest problem you've ever solved?

#34
In code: Naming things in a manner that makes the code readable. It's a constant challenge.

With cars: troubleshooting and fixing a ferrari 599 without the required factory diagnostic computer. You can't beat a multimeter and some elbow grease. It was a faulty flow meter.

In general: figuring out what to do with my life. It took me a bit but was worth the time. Now I can focus on doing that and just that.

Re: Ask HN: What's the hardest problem you've ever solved?

#35
An embedded CPU would sometimes latch-up when going to sleep. This wasn't seen during development, only reported in the field with very little in the error report, just something like "It stops working, reboot it works again"

Eventually we found the internal JTAG pull up resistances would not be sufficient at certain voltages / temperatures. So it wasn't latchup in the end but the JTAG would halt the processor.

We only found it after days of testing in an oven cycling temperature while stimulating a coil (RF field) close to the device while varying the supply voltage to cause the condition.

All the while the client is not happy that his devices randomly stops working, so we were under quite a bit of pressure.

And of course we only started looking at the hardware after we spent quite a bit of time thinking it was a software bug somewhere.

Re: Ask HN: What's the hardest problem you've ever solved?

#36
I think problems are hard when you are new to a domain. After you get some practice, nothing there is really that hard.

For me, the first hard thing was implementing this https://en.wikipedia.org/wiki/Dead-end_elimination#Generaliz...

Probably because it was the first algorithm I implemented with no reference implementation to look at.

The second hardest was a high performance proxy that can redirect to another proxy and can collect specific types of non-encrypted data.

Re: Ask HN: What's the hardest problem you've ever solved?

#38
I had the luck to have had to solve to though problems. Like in a performance analysis in the major telecom operator in an African country, finding many flaws in the infra-structure, circular DNSes (do not ask), and to top if all, their Internet reseller selling them the double of the real bandwidth, and to top it all, them having bridging enabled to all the country due to a vendor telling them "put this line on the central router". Or when a colleague wanted to upgrade technologies, implementing filters at the CPEs after reading DOCSIS RFCs on a cable company, and seeing the infra-structure upload traffic diving to less than half. Or picking up the Linux department and even before reimplementing all the servers, optimising servers that went from 9x% CPU utilisation to 10%. Or (re)implementing the middleware for 2 cable Internet companies, in which one of them had some functionalities in Java and I reimplemented in C to see some operations that were done in 1h being done in 5 minutes.

Re: Ask HN: What's the hardest problem you've ever solved?

#39
Going to list a few interesting problems that were easy to solve but the identification of the issue was hard.

* A test suite we wrote for a client's project before a massive refactor was stalling randomly, but would continue when you tried to diagnose the problem. Turns out their user creation code used /dev/random, and the system was running out of entropy and so the code was blocking. Moving the mouse or typing on the keyboard would add entropy, thus cause the tests to resume. Fix was to to use /dev/urandom for tests.

* Found a weird issue with an embedded network stack where a limited broadcast packets to more than 3 devices would result in only a response from a few of them, but directed packets to each device would work fine. Devices reported successfully receiving and transmitting when monitored over serial console. Issue turned out to be a bug in the ARP implementation where it would incorrectly store any ARP response it saw (rather than ARP responses the device requested). Given the embedded system has a limited ARP cache due to memory constraints, when multiple devices wanted to respond, they would all send ARP requests, and the responses would flush the ARP cache, so when the network stack wanted to send the response, it didn't know what MAC to use and just drop it on the floor. A workaround was to increase the ARP cache size.

Re: Ask HN: What's the hardest problem you've ever solved?

#40
Answering this question feels like the hardest problem I've solved yet... ;) Because, I don't know: I've never really thought "this one! THIS is the hardest!" You just iterate and things get more and more challenging as you build skills. What seemed hard to a junior tech doesn't seem hard to me as a senior tech now. It's all just engineering. It is all just sitting down, reading manuals or prior art, getting familiar with protocols or fundamentals, and building maps in your head until you understand something. Then building proofs of concepts and outlines; then, applying a bunch of troubleshooting principles; repeat until problem is solved. I've written academic papers this way, I've built streaming servers off esoteric industrial process-control database APIs, I've done process visualizations, I put a model railway online (before that was an out of the box thing)... and it's all the same: use what other people did, understand it, and then build from there.
Post reply on HN