Previously have used https://github.com/pdf2htmlEX/pdf2htmlEX to convert PDF to HTML at scale, could potentially try and parse the output html to markdown as second stage.
Agree regarding the details - I'm guessing unrelated given the indictment was over a year before the collapse "On Jan. 13, 2022, a federal grand jury indicted Gad"
Last company, no tests for the first 6 months. Current company after 2 months, have some unit tests for complicated parts in place, will start writing tests once bugs are resolved.
I guess it really depends on what your company is doing, experience of the team and the language/tech you are using.
technical perspective, ignoring business perspective: resolving the bugs by writing tests is excellent advice, especially once a component is sufficiently complex. get regression tests in place first, so you can sense how may new unknown defects a "fix" for a known defect is introducing. Michael Feathers' book "Working Effectively with Legacy Code" describes one approach.
somewhat political perspective: if the org doesn't value testing or software quality, wait until there's obviously a business need to lift quality. E.g. the CTO is saying things such as "constant defects in component X are destroying most of the value of our product", users complain that the Y feature keeps getting broken in successive releases, customers refuse to renew subscriptions or upgrade to a new version until Y feature works reliably. Then propose the plan to improve QA by setting up an automated regression test suite, to allow refactor-to-test of the offending code to happen in a controlled, low risk way.
Agree with this totally, additionally if you are unsure if you will proceed with an idea with no users, getting something done and receiving feedback as fast as possible is better than doing it perfectly the first time.
That said at my last company after 12 months we hired a few engineers so we had to transition to requiring tests for new functionality. This was just to stop regressions and make sure we could continue moving quickly.
I partly agree with you, but I also think that using debugger/stepping through code/test manually will take longer times in most cases. And it's time wasted that does not produce anything "permanent" - unlike tests.
Co-founder of HowdyGo here, would love any feedback people might have.
I built HowdyGo because at a former company I founded, we had a small addressable market, high-value leads, and unfortunately very long sales cycles.
Our customers needed time to build trust in the product we offered and that meant it was a necessity to have actual conversations with them, not text chats.
Have a chat with me or my co-founder here or by heading to the link and clicking on the widget!
