If the Fed "loses" money by buying high and selling low, it means dollars have been created with no mechanism by which they can be retired, because the Fed has no corresponding assets they could use to exchange them for. This creates permanent inflation/dilution of the currency.
Wouldn't this be extremely dangerous if a form of "plastic rot" was created? Things like PVC sewer pipes, or any long-lived plastic parts in cars/equipment could now degrade over time, which could create huge costs to find alternative materials. After all plastic is pretty useful because it is biologically and chemically inert.
wouldn't removing the GIL cause all sorts of sudden race conditions and regressions in existing python code? I think there is a valid argument to keeping the GIL just for simplicity's sake
you don't need consent but you still have to notify users of all their functionality, often this is done with a banner. Still a burden to everyone involved.
EU has laws that threaten millions of euros of fines for not having things like cookie banners. They are required by law for even the most basic user-customizations. And no allowing users to save state on your page is not unethical.
The most unethical thing about cookie consent windows is that website developers have to develop them in the first place. Cookies are fully opt-in from the client side, it would be trivial for a browser to have settings to ignore or adopt cookies based on preferences of the user. It is a total farce having these warnings, at great cost to developers and users alike.
This is pretty basic "running a business" stuff. If you think paying a few hundred to an accountant is a nuisance, you're probably not that serious about running a business anyway.
Seems like the writer hasn't actually seen that many episodes. Plenty of excellent sci fi episodes in addition to the less serious "monster of the week" ones. "Measure of a man" or "the offspring" come to mind.
I think its a sign of the times when super highly paid individuals like VCs have to navel gaze about what the "optimal" amount of time working should be. Business is fundamentally a competitive game and when the free money tap stops there will be a rude awakening.
Absolutely true. Hard truth for some but tenure at a big company working in some internal framework is often next to useless at another company with a different tech stack (thinking in a custom C++ library framework instead of thinking in well known open source frameworks). Some skills carry over (especially soft skills that are so often under-invested in by engineers), but some just don't.
Code review has been done "remotely" via Github or other online tool at every place I have worked, I have _never_ seen it done in-person. I also find that doing this in person would be incredibly time consuming and frustrating. The confrontational nature of code review is a good thing because people are able to focus and independently analyze how your code works. Its important to be nice but its also important to not take feedback about your code personally.
A secure, encrypted, containerized microservice to store personally identifying (pii) data (contact info, names, govt id info etc). The idea is for it to be a drop in microservice that can keep all PII in one place for compliance, security, and convenience.
I remember several years ago, I was considering pushing for some changes to our application to use a database like sqlite instead of a proprietary flat file format. I remember reading through the source and realizing how beautiful C source code could be, compared to the prop C code I was used to working on. That plus the constant improvement, stellar performance, and beautiful source code make Sqlite one of the top most gems of open-source software in my opinion. Huge props to Dwayne Hipp and the other contributors to this database which has enabled so many apps and products!
A huge problem with this industry is the inflexibility to pay current engineers LARGELY increasing comp each year. The thought is that there is a market rate for an engineer and that pay can increase with the market rate, but this is a fallacy. An engineer that has been at a largish company for 1 year is worth 20-30% more than the year they were hired because they have specific knowledge of the tech stack. Yet that engineer will likely be offered a 3-5% raise. An engineer with 3+ years might be worth 50%+ because they have developed the specific skills relevant to the job AND know the idiosyncacies about org politics and the nitty gritty parts of the codebase. Yet they will still only get a 10-15% raise. So that engineer moves on and accepts a 40% raise elsewhere. And thus we see the constant churn of highly talented engineers which is a huge drain on productivity for all involved.
This seems like a totally unrealistic and impractical way of organizing a codebase. Living, useful codebases under active development need to be searchable and well tagged rather than laid out in "chapters" in my experience. In most scenarios it is also not a great use of time to try and read through a codebase line by line from A-Z.
Thanks for writing this fantastic book. I think it is a must read for any software PM or engineer looking to "disrupt" healthcare. That chapter about paper-based workflows was really eye opening for me as someone who has never worked in that kind of environment.
I think another big area here is that regulations concerning medical software (such as the design controls needed for FDA Software-as-a-medical-device) are simply outdated and do not reflect software development best practices. Instead of things like testing, fast deploys, monitoring, redundancy, scalability, etc the regulations strongly push people to emphasize up-front specification and documentation, which takes an incredible amount of time and energy out of a project.
A lot of devs don't understand this, but can save a lot of time, especially when the code is all python. Especially if you questions are off the beaten track
The federal reserve was able to intervene in much the same way in the US post lehman by being a lender of last resort and getting credit flowing again. The bigger problem with the 2009 crash was the massive recession that followed as the economic sectors built up around the housing bubble struggled to recover. If China's housing bubble collapses, it could still cause a big recession there with high unemployment while the economy adapts/adjusts.
This is a really interesting idea. It would be very useful to be able to lego together some components and get a rough estimate of how it would scale and what the technical performance would be (to first order).
We should stop thinking in terms of "tech companies" and think of them in terms of "companies that use tech with a high degree of success". Ultimately any company that makes money is not a tech company because pure technology on its own does not make a business. Also, with the right incentives and management it is possible, although hard, for legacy companies to start using tech better to compete.