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

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

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 441 posts

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

#11

Post by _asummers »

I wrote a tool[0] that converts Erlang style Dialyzer messages to enough of Elixir to where the Elixir formatter can pretty print it. This isn't an intractable problem, but the source tool does really bizarre things so the output so it wound up being really annoying to deal with the quirks. Still not quite done, but it's in a workable state to where messages can be dealt with individually when the errors are poor.

[0] https://github.com/asummers/erlex [1] https://github.com/jeremyjh/dialyxir

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

#12

Post by ozim »

bringking wrote: post #2

One of the hardest challenges I have had in my career is convincing our company to move to Continuous Delivery. 90% of the challenges weren't technical, but emotional. Shipping software comes with lots of feelings, fear, politics, etc. I had to personally work with various leaders across the org to help them through these feelings and perceived blockers. We aren't 100% there yet, but we are shipping numerous times pe…

That is interesting because I am still trying to figure out how people do CD. Of course I know CI, we have it all set up. But we still work in sprints with manual testing and release every 2 weeks.

I could spend time on marking features 'frontend only, low impact' which we could deploy pretty much the same day. Still there are quite some features that need bigger amount of work where they might be 'done' by dev but I am sure they are not actually done, because security, because error checking. It of course is usually that one dev has his not tested feature merged to develop and then also some other dev has production ready one, then if one feature is production ready, I would have to put also some time to make release and pick only changes for accepted change. I am not sure that additional work to check what we can release ' right now' will pay off vs just taking time for fixes on acceptance by people who were working on code and then release it (after 2 weeks o 1 depending how fast it is done in sprint).

So are you having people who work only on picking changes that are low impact, or working on making stuff production ready by picking from develop? Maybe you pick changes by yourself, or you just defer manual testing to end users and rely on automated tests unit/integration?

p.s. Funny thing with automated tests is they are good at keeping old stuff working but not for testing newly developed features where actual tester can test new GUI/ new features. If you have a lot of GUI changes you cannot automate first tests...

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

#13

Post by Aweorih »

My company is building a device which collects data from a car while you drive. We wanted to group those in "trips" on a very simple logic. If the device sends any data for the first time, start a trip and if there's none for more than 5 minutes, close the last trip. Problem was that the source of the time is coming from the device which had a lot of bugs (e.g. time was in future, time is from year 1970, time is not in order...). Management also decided that it's too hard to fix them on the device. At the end it took me 3 full weeks +/- to make it work. At the end I was able to convince the management that some bugs were too serious and required fixing

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

#14

Post by ratsimihah »

throwaway000021 wrote: post #6

To learn to listen to other people, instead of just waiting to talk - that's an ongoing problem. To understand what "controlling behaviour" means. To empathise, and see oneself from the eyes of others.

If only we were all as self-aware of this as you are.

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

#15

Post by BlockchainStock »

ICOs and DAOs both present difficult legal problems vis-a-vis the SEC and securities laws.

Where others have failed we believe we have developed a legal framework for both a non security/unregistered ICO and legal DOA.

To legitimize our legal position we submitted a No Action Letter to the SEC. Uniquely this is not just another legal article/arguement, because the SEC will not respond to a hypothetical No Action Letter.

In parallel to the legal concept we have launched a Delaware LLC which will follow through with the ICO and execute itself pursuant to a decision tree depending on the SECs response to our letter. The decision tree even includes a possible branch with a vote of the project supporters (the “51% attack”).

Our SEC letter and our Delaware legal documents are open source if you are interested feel free to request and we will send you links.

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

#16

Post by archagon »

I started with the glimmer of a hope that perhaps network sync could be made stateless, went down a months-long rabbit-hole of research, and ended up writing a novella-length article about CRDTs: http://archagon.net/blog/2018/03/24/data-laced-with-history/

So many days spent thinking, sketching, trying to swallow a concept that seemed far to big for my jaws—only to suddenly find myself on the other side, with this arcane knowledge fully internalized.

Going from a few wayward thoughts to a working proof-of-concept was the most professionally satisfying thing I've done. It felt like alchemy.

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

#18

Post by nthompson »

bjoli wrote: post #4

I wrote an inliner once. It might seem like an easy problem, but a proper inliner is a rabid animal you can just barely restrain on a leash. The simple part is making it work without clashing. The hard part is making inlining always be an optimisation with reasonable code growth with regards to compilation time and cache use.

That sounds tough. You also have a code size/speed trade off that must be managed. Where did yours land?

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

#19

Post by mooreds »

I was working on a calendaring system. We supported recurring events, and each event could also have a piece of equipment associated with it (one or more). Events could also be changed, either the current event or this and every event. Event start/stop times were stored in UTC, but the event was displayed in the users timezone, and could cross daylight savings time boundaries. This was done with a mix of javascript on the front end and ruby on the backend.

When first implemented, the equipment was reserved for the entire time of the event. A feature request came in to allow for partial reservations of equipment (we want to reserve space A for four hours, but equipment B for only the last hour and equipment C for the first two hours).

Solving it on initial event creation was pretty easy. The UX was difficult. But handling updates, especially across recurring events, in a way that was maintainable and correct was the hardest technical work I've done. I wrote a lot of tests.

The difficulty was compounded by the fact that this was a startup and I had no technical peers to discuss the issue with. The code implementing the work wasn't the cleanest either. I could have reached out to friends, but they wouldn't have had the understanding of the issue.

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

#20

Post by mooreds »

Aweorih wrote: post #13

My company is building a device which collects data from a car while you drive. We wanted to group those in "trips" on a very simple logic. If the device sends any data for the first time, start a trip and if there's none for more than 5 minutes, close the last trip. Problem was that the source of the time is coming from the device which had a lot of bugs (e.g. time was in future, time is from year 1970, time is not…

I worked on a similar car trip detection algorithm for a company aiming to stop texting while driving. Not easy at all!
Post reply on HN