johnobrien1010

Working on a SaaS application that helps academic researchers conduct systematic literature reviews

This assertion seems light on sources. What evidence do you have to support your claims?

It seems prudent to me to not assume anything either way until you have more information

Wanted to point to the startup the author seems to be running, which is to sell insurance somehow tied to Bitcoin: https://meanwhile.bm/

For the record, that strikes me as seriously improper. Life insurance is a heavily regulated offering intended to provide security to families. It is the opposite of bitcoin, which is a highly speculative investment asset. Those two things should not be mixed.

Also, the fact that the disclosure seems to limit sales to being only occurring in Bermuda seems intentional. I suspect that this product would be highly illegal in most if not all US states, so they must offer this only for sale in Bermuda to avoid that issue.

Take whatever job you can now while continuing to look for your next role.

This. And by any job I mean any job. McDonalds, book store, what have you. A good friend of mine dropped out of Harvard sophomore year. She found work at the COOP, then CVS, etc. It was definitely better than going back to an unstable and abusive environment while continuing to job hunt.

Wayback Machine Link: https://web.archive.org/web/20250311184956/https://pages.cs....

USAID was established by an executive order and then also created by law by Congress: https://uscode.house.gov/view.xhtml?path=/prelim@title22/cha...

I haven't done it but it looks like an ESOP something you might to look into.

What business did you build around it?

I see. Thanks for clarifying.

In THEORY yes, but in practice, there are not a ton of journals I think that will actually publish well done research that does not come to some interesting conclusion and find some p<.05. So....

Yeah but without a hardline how would you decide what to publish?

Another reason that they should never have been allowed to ingest all the books in the first place. Without paying for the rights to use the digital form of the book, a use which is explicitly prohibited by the publisher, they digitized the books anyway. If they used it to train an LLM, and the LLM regurgitates near facsimiles of all the copyrighted works without compensation to the original rights holders, that seems like something that should be illegal.

All the arguments for where to place control over who decides what gets built IMHO are just political power grabs from one constituency or another. Different companies do it differently, and I'm not sure there is one best way. Any time engineering or product or sales or marketing want more power they come up with some reasons why their function should have more control in every company everywhere.

I don't think arguments that any function should always drive can be true, because who is best qualified to make those decisions is based on things like judgement, experience, domain knowledge, and customer understanding.

Instead of saying a specific function should have control, I think empowering the people who have been best a making decisions about scope should do it is the best approach. That can be engineering but that also can be product etc.

The approach is fundamentally flawed. You can’t query an LLM as to whether it has a theory of mind. You need to analyze how its internal logic works.

Imagine the opposite result had occurred, and the LLM had outputted something which was considered a theory of mind… Does that prove it has one, or that it was trained on some data that had something it used which made it sound like it has a theory of mind?

My fridge stopped working last year. We called a repair technician, who swapped out the whole PCB and charged us a few hundred dollars. In retrospect, I think it was one bad relay on the board...

Next time it dies I plan to try to find the defective relay, desolder and resolder it myself. Imagine how much better it would be if there was a read out with an error code on a fridge with easily removable relays you could unplug and replace. I know it is not a priority to make these kinds of things repairable, but I wish it was.

Which part of that is a pun?

Good demo videos: https://daylightco.notion.site/Eye-Strain-Free-w-the-Dayligh...

I think I must be looking at this wrong, how are "Photographic plates and film, exposed and developed, other than motion-picture film" the most complex product? Surely CPUs are harder to make than that? Maybe it is old categories and there is where new things like CPUs are found?

(2015)

[JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success.]

I agree with this (and the clarification in the paragraph just after this), but to my mind, those are different goals.

The goal of an MVP is quite different to the goal of refinement - in one you are determining if there is a market, in the other you are determining PMF via successive refinements.

Those would be different headlines, but headlines nonetheless. I see it as H1: "You can now rent VMs through an API" H2: "Rentable VMs available across our entire offering (not just the x2.small)" H3: "Cost-calculator available on our RVMs" H4: "RVM snapshot facility, first of its kind, now available" H5: "RVMs are transferrable between regions with no loss of data"

What you clarify was not something I considered - that each new headline one is working towards is, in fact, a new product. I only considered headline-oriented work in the context of a single product.

I think working towards a headline is a bad idea if the headline is a greenfield development, but a good idea when ensuring that the product is evolving to ideally fit the demands of the market.

[JO: Yeah, that makes sense. I can see that in the context of a single product. The examples the OP provided made me think of the headlines as being more mercurial and greenfield in scope, but that was an assumption.]

[JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]

What systems are you thinking off? I've seen ancient tiny MSDOS-based software used well into the late 2000s in spite of poor reliability of the underlying system. I've seen long-lived ERP systems have their bugs worked around by users over a decade.

[JO: That specific example that came to mind was a GRC system which I worked on years ago. The system was full of bugs, and a large insurance carrier wanted an enhancement. I forget just now what the specific enhancement request was. I do remember though that when I said "no", they said "Ok, then we are not renewing our subscription." I remember it vividly because I was surprised, that was the first time it had happened to me.]

I mean, right now I consulted on a small company extremely unhappy with their accounting software (quickbooks force-moving everyone to their cloud)) dismiss any notion of using anything else because "The users already know how to use this!"

[JO: Yeah, that can be a problem sometimes.]

[EDIT: I only somewhat agree with your points, but I upvoted your comment anyway because the ones I agree with, I feel are good points].

[JO: Thanks!]

Responses inline.

Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff.

[JO: I don't understand what you mean here. Are you saying the goals should all be appended with "and the customer buys it?" So, "You can now rent VMS through and API, and customers do?" In which case, wouldn't that be something that has to happen over time and cannot be delivered solely by engineering by an arbitrary date?]

After all, look at the example headlines:

“You can now rent VMs through an API”,

“we rolled out FSD autopilot”,

“Treasury is available in India”.

Those are all goals!

[JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success.

If you goal is "customer can now rent VMs through an API", my assumption is that to meet that initial goal a MVP will be delivered. My further assumption is that the MVP will not have all the features it will ultimately need to be commercially successful and so will need to be iterated on to be better than the alternatives customers have available to them. So, devoting engineering resources to the next headline and not iterating and improving the MVP would be a mistake. If you keep doing that, you end up with a bunch of half-baked marginal products, none of which is successful.]

"Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier.

[JO: I disagree. In the B2B setting at least, I've seen customers cancel because commitments to make minor enhancements for them were not honored. It is rare but it does happen. In addition, while customers rarely cite a specific bug as the reason to cancel, they often cite things like "bad UI" or "bad usability" or "lack of adoption", which IMHO is sometimes the way that customers articulate their experience and/or the results of working with a buggy product.]

I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business.

[JO: Can you tell me more about what you are thinking about here? In general, I think Microsoft is a tricky example to use, because they have something of a "natural monopoly", and unless you happen to be working at another company that also has such a natural monopoly, an example based off Microsoft may not be applicable.]

No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high.

[JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]

[1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher".

[JO: On that we agree; one of my engineering colleagues used to say, if you say everything is urgent, you are letting the other person decide the priority. A good PM should run interference between such customer requests to provide useful and realistic prioritization, otherwise there is no-prioritization at all.]

This is a joke, and the reason why is because even if you “deliver” a headline, you are unlikely to be “done”. It runs counter to the approach of incrementally shipping functionality, listening to feedback, and adjusting.

Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. This is a nightmare, because you end up working long hours on valueless work… and upset all your stakeholders by ignoring their urgent requests to deliver small fixes and enhancements to instead just do the one thing you said you would, even though it ends up being worthless.

I love the idea of the Framework Laptop 16 and an upgradeable GPU. My wife has a Framework 13 DIY edition and loves it.

My problem with the Laptop 16 is the price; it is ~$2,100. At least as a gaming laptop, you can get an equivalent GPU in more traditional gaming laptop for less money (compare the Acer PH315-55-79KT w/ an RTX 3070 @~$1,800: https://gpu.userbenchmark.com/Compare/Nvidia-RTX-3070-Laptop...).

I'm not sure it makes sense to pay $300 more to be able to upgrade the GPU... In theory, maybe? If in three years, if you can get a 100% better GPU for the laptop for just $400 that would be a coup, but I don't know if that is what is going to happen.

We have a ticket status in JIRA called "Parked". It allows us to capture the feedback so the stakeholder doesn't feel ignored. And if we get repeated requests, we can find it, bring it out of parked, and it starts to become a real thing.

There is the issue of dupes but it avoids the other issue, which is that if you hard decline too many requests from right after they are submitted, stakeholders may stop giving you feedback, which is a bad thing. So it is an unhappy middle ground (which is I feel the normal place which product management occupies. I could setup a small shop in the unhappy middle ground and sell souvenirs.)

(2019)

Was it this one: https://www.youtube.com/watch?v=OCFMX5z-ed4

If you detailed game you may enjoy DCS manuals as well: https://www.digitalcombatsimulator.com/en/downloads/document...

I think the implication is that he completely made it up.

Yeah, IMHO title should probably be has unprinted sections, not unprintable sections