Ask HN: What's the hardest problem you've ever solved?
We've all toiled and eventually solved some problem. Would be awesome to see some of the toughest problems HN community members have solved. Could be from any domain though it's better if the problem is somewhat technical.
123 comments
[ 3.7 ms ] story [ 125 ms ] threadI think React Native is super cool right now if its going to make nice UI easier and have good multiplatform support.
Basically it is one of those unfortunate cases where the first weeks makes everything look really promising (single codebase and all) and it is only after hard work of several months that you realize that there is no way you are going to win this battle.
Edit: Whoops, I realized this was ambiguous. I was using an iPad camera to track it and displaying the result as well as using the detection to trigger a camera shutter.
Didn't make it into my first paper, hopefully will end up in my thesis :)
At the time it was given to me it was a rough demo with no clear path forward to shipping. We had no metrics to tell how good it was, how good it had to be, or whether we were even making progress. We had no team of computer vision experts to work on core algorithms. We had no idea if the problem was solvable at any amount of power consumption. There were more than a few people within the company who thought it couldn't be done.
I want to be very clear about credit. I put this as the hardest thing I have ever done but I was only the manager in charge of the project. While I built the team and owned the problem, I did not write the code or design the algorithms. I had incredible people who did outstanding engineering work and researchers who advanced the boundaries of computer vision. It was a privilege to work with them and I am proud of them.
Tweak -> Compile -> build deployable package -> push to phone -> wait 6 minutes -> test on phone -> repeat....
Then the next hardest problem I found was implementing Genetic Programming in Python (year 2005) http://paraschopra.com/sourcecode/GP/index.php
It was fun but extremely hard for me (at that age!).
After that in 2008, I think the trickiest part for me was to write initial visual editor for Visual Website Optimizer. It involved reverse proxy and inserting JavaScript code into that reverse proxied page, letting the user visually edit the page contents.
Fun days. These days I hardly get to code, though last year I gifted my wife a website (http://wowsig.com) which was super fun.
[1] https://github.com/lunixbochs/glshim
[2] https://youtu.be/8ibx-2ZBLVg?t=76
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.
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.
My problem was a lack of javascript logic firing and the answer was to wait for document load. Simple, I know, but I had nobody around me (physically) that could help me and explaining the problem to people in forums seemed impossibly abstract, primarily because I did not understand what the problem was. It was the context around my code that I had to fix, but I kept looking in the code itself.
That was probably one of my first big "ah ha!" moments and these moments are one of the reasons I still love programming. Tenacity, luck and skill became irrevocably connected that day.
I've solved many other problems over the years, far tougher than this one, but maybe never tougher for me in a relative scale. If I had never solved that problem, I sometimes believe my life path would have been totally different.
Nowadays most of the problems I face have been solved by someone else in a slightly different context and searching for/implementing existing solutions is almost trivial.
The formula is how much protein, carbs, and fat to eat and the appopriate exercise of 3 half hour workout sessions a week. No supplements or anything else. Just food and small amounts of exercise to stimulate hormone response. This is way more complex than some tracker or calorie counter. It takes into account insulin spikes, metabolic damage assessments, glycogen storage, and much more. The hard part here was integrating ~10 different disciplines in various sciences. Everyone had a piece of the puzzle, but we had to put it together.
That is then fed into an app that can then pick foods for you based on your formula that is then constantly refined based on your results. We took 1000 people through test runs tweaking our code to get it right. Now it works for everyone that we put on it and actually uses the system.
Our next challenge is the psychology and habit forming parts of the app we have built.
Oh and of course competing with well funded competitors in the space, but at least nobody can claim our results because they just track things instead of allow people to really plan for health.
Edit: Since you asked, it's called mPact (for metabolism impact) and the corporate site is at http://mPact.io
Frankly, this sounds like taking a good idea too far. People around you will make assertions about objective reality that are beyond any reasonable doubt incorrect, sometimes dangerously so. Considering them wrong can be important to prevent harm to yourself, your family and your job or business. Beyond that, calling out people you care about on their being wrong can prevent harm to them and their respective families and jobs even if at first they hate you for it.
Empathizing with people who are wrong for understandable reasons but still being keenly aware that they are wrong seems to me like a much better long-term strategy.
It was the early days of SOAP, and I had been assigned the task of integrating my employer's software with a third party's, so that the applications could share data. This third party org was a wealthy, powerful mega-corporation; and my employer was, well, not. The third party produced a spec for the interface, expected us to follow it, and offered no help from there.
I built a solution. It worked on my machine. Solved the problem. All was right in the world.
I moved it to the test environment. It worked again. Demoed it for one of our customers, and everyone was pleased.
Deployed it to our first beta tester. One lonely employee working accounts receivable, tucked away in the corner of our customer's office.
It crashed.
I checked everything. I mean everything. There are still particulars of that little Windows 2000 workstation that I can describe vividly. Which programs were installed, which patches were installed, how Windows had been configured, how the firewall worked, I even got permission to install a packet analyzer. My employer only had a handful of customers, and the beta test machine was near our offices, so I was over there personally a lot over the following weeks.
We brought in the customer's network support people. They found nothing. They could see the packets leaving, and an error coming back, but couldn't offer more than that.
We brought in the best networking engineer in my company. He was stumped.
What really shook my confidence was knowing that competitors mine had gotten this interface working. This wasn't some half baked project that I could blame on someone else. Others had succeeded where I'd failed.
I practically had to walk across broken glass to get on the phone with the third party's development team, but with enough pestering I pulled it off.
The phone call involved me sitting at the beta test workstation and firing off a request so that they could view it hitting their servers live. The developer who I spoke with immediately spotted the problem.
You see, when you send a SOAP request, you send the date and time that you're making the request along with it. The clocks on the client and the server were too far out of sync, my requests appeared to be coming from the future, and so the server disregarded them with a blunt error. Interestingly, the workstation clocks at my company's office weren't too far out of sync, which is why it worked in one place and not another.
Stuff I learnt:
1. Third party interfaces require a point of contact at both organisations who can talk with one another. This is non-negotiable.
2. If you send an error message that reads "Error", you're a bad developer and should return your computer science degree to your university and demand a refund.
3. No matter how well written the spec is, something always gets left out.
4. Persistence maters more than anything.
Turns out the bias current node (external RBIAS resistor sets bias current) for PCIe was routed too close to an inductor for a power rail. When the CPU was warm, the power rail pulled more current, causing the inductor to ring more, causing the crosstalk on the bias net to screw up the PCIe subsystem and hang the CPU.
Found the issue accidentally on a layout change. Had to prove it by drilling out the via and re-routing the signal with wire.
- I worked out, on pen and paper, sorting networks on my own a few years before the Wikipedia article on them existed. I was looking for shortcuts in a Quicksort implementation. I hadn't read Art of Computer Programming yet, which is probably the only other place I would've been likely to read about it. It hadn't been covered in any of the other programming literature that I was devouring at the time.
- I wrote a variable interpolator in COBOL. COBOL has no string operators or anything resembling a string data type. This one was tricky. I was working as a programmer/operator at a school district at the time and the central hub of their IT was a Unisys mainframe that ran COBOL and WFL. There weren't any punch cards anymore, but everything ran as if there were; for any given job to run, say, report cards, you had to go into the WFL job and edit a two-digit school code in half a dozen places, in "digital punch cards", which would then be fed one after the other into COBOL programs. This was error-prone and I wanted a way to define a couple of variables at the top of the job file and then have everything work after that.
- I worked for a BigCo that used Remedy for its internal support systems. There were some latent training issues in the internal support department and support requests kept getting modified by unknown people, which would cause the requests to get mishandled and would irritate various other departments. I found a way to sneak some code into the Remedy forms system and I cobbled together a very rudimentary communications protocol between several forms so that all changes to any form got logged to another form, along with the user's id. Remedy had no loop logic at the time. That actually made it to a Remedy developer's group mailing list once and I was a big fish in a very tiny little puddle for a day.
- I reverse-engineered portions of the .dbf format that FoxPro uses, and wrote software that could convert .dbf files into MySQL tables. The date format was tricky. It was an 8 byte field where the first four bytes were a little-endian integer of the Julian date (so Oct. 15, 1582 = 2299161), and the next four bytes were the little-endian milliseconds since midnight. This is not documented anywhere.
Those are some of my favorites anyway. 30 years of programming, there's been some fun stuff along the way.