lojack

I get it, you want to play devils advocate, but every example you gave solves a problem that isn't "real time cross border remittance and settlement". They either aren't cross border (Venmo/Square Cash), or don't actually result in settlement (TransferWise, Norbert's Gambit), or aren't realtime (Interactive Brokers takes 3 days to settle your account FWIW).

It’s also useful for transmitting money long distances when banks won’t do business and you want to avoid a paper trail (drugs). Fiat is perfectly fine for in person transactions, but not when distance is involved. You may or may not morally agree with it, but this is a proven use case.

Fwiw none of this is necessarily a breach of hipaa laws.

First, why not demo partially complete and/or staged but not deployed work? Tangentially, doing things to appease sales is a quick way to reach local optima and build a directionless product (same thing for customers). A good product person will take their requests, identify the problems, throw out things that don't fit the vision, and incorporate the important parts. Sales shouldn't be your drivers, they should be your eyes and ears.

"ASAP" isn't a deadline. It helps you understand urgency, but not importance. Don't waste your time with urgent unimportant things.

> Management generally doesn't care when code is done, they care when it's done and deployed.

I'd argue that these two are the same thing. I'd even take it one step further and say you shouldn't consider your work done until it is deployed and verified working. Thats why you don't deploy on Fridays.

> Fair enough, but I'll observe that in my experience deadlines and deploys are often strongly correlated.

For some code this is true, but not all of it. I'm sure every team is different, but most code I deploy either has no deadline or has a deadline more than a few days out. Of the remaining stuff, deadlines can almost always be pushed back if the work isn't done. Not ideal, but usually a possibility. No need to work over the weekend unless there's a hard deadline which can't be pushed back, which is (or should be) exceedingly rare.

I feel like you're conflating deadlines with deploys. If its ready to go on a Monday then I see no reason why you should hold off doing the deploy. If you have to work all weekend to get it ready to go by Monday then its probably because there's a deadline.

This is from a CVE that was released a little over a month ago.

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Premature optimization isn't bad, premature micro optimization is bad. You should also be thinking about optimization that results in better architecture and architectural decisions that make it easier to optimize in the future.

As an extreme example, if I thought my company was worth $40m and someone offered $20m in exchange for 10% of my company I would absolutely take that deal whether or not I needed the money.

The problem might not be that the company is taking a deal when they shouldn't. It very well could be that the investors are overpaying. It's also totally possible that this is a good deal if it helps the company get a bigger slice of the market because they can grow quicker.

The only helpful advise given to my wife was that she needs to put actual physical distance between herself and her mom. To move far enough away so she could limit in person interactions to a couple times a year.

Thats a lot of hand waving for something that wasn't trivial at all in the 60s and 70s.

I'd argue that for most people the value was only obvious afterwards.

To put email in perspective, early adopters had to choose between what they already knew and all the hurdles involved in connecting to the internet and using the new technology. There was also a good chance the people they were trying to communicate with didn't even have email. Outside of a few niche areas, email provided no obvious value to the vast majority of people for decades.

I still do some work from time to time, but I make sure its work I'm doing for my own personal reasons and no other work depends on that being completed. I also keep my technical skills sharp by pairing with team members, directing them on technical decisions, and doing code reviews. You've got to be careful with code reviews because they can come off as micromanagement to some people. Sometimes developers will specifically request a code review from me, and I'll take those. Sometimes I'll chime in if a decision needs to be made. Otherwise I try to only code review if I see something glaring that needs to change.

Is it though? I used to think that, but over the past couple years I've seen plenty of politics around governance of the future of cryptocurrency. Seems like everyone tried divorcing the two and ended up just creating a new state.

Dogmatic TDD is the best way to practice and learn TDD. If you don't do this then you _will_ inevitably learn bad habits. Once you learn how to TDD like this you will begin to understand when you don't need to be dogmatic, but that only comes with experience.

This is actually only a half truth. Emergency rooms are required to treat patients who need emergency care. They don't need to fix all ailments. If you have cancer they can turn you away, but if your organs are failing as the result of cancer they have to treat you. If you need a heart surgery they can turn you away, but if you're having a heart attack they need to treat you. For the most part, treatment is pretty much just making sure you're stable and can leave the hospital without immediately dying. This only applies to emergency rooms as well. Where you go to get surgeries is usually not the same place you go to treat an emergency condition. It might be affiliated with the same hospital, and might be attached to the emergency room, but it isn't itself an emergency room.

> The extent to which the intern’s work complements, rather than displaces, the work of paid employees while providing significant educational benefits to the intern.

The argument would be made that since the company is charging for work from unpaid interns to be fulfilled only by unpaid interns, it would be displacing the work of paid employees as opposed to complementing them. Of course, there's a lot more to it than just that going into the litmus test.

This sort of stuff happens all the time. Its surprisingly common for unpaid interns to operate in a grey area. Can't really say this company is doing anything illegal without actually knowing what the program looks like for the apprentices. Every company I've worked at has decided its better to just pay them something, even if just minimum wage, to avoid risk of lawsuit. I also just think thats the right thing to do.