uv for Python is a game changer, better than anything else out there and solves a lot of the core problems with pip/venv/poetry/pyenv (the list goes on).
I feel like you can write some variant of this comment every few years and just add the previous "best" to the front of the stack of things it's better than.
> - Execs truly believe that culture and productivity are better in office (i.e., what they actually say in their announcements)
I think this is the reason, but its more nuanced than this. Management finds in-office employees easier to manage. They are more likely to attend meetings, participate in team communication, give status updates, etc. There's much less of a question around "is this person doing the work" if you can see them doing something that looks like work in the office. If you are blocked or are blocking someone, it's a tap on the shoulder instead of sending a message into the ether.
Management of remote employees is a huge information gathering exercise - very little of the above information is proactively surfaced to you, and instead you have to go looking for it. Frankly, it's just a lot more work for managers.
I realize the above may not be fair to employees, or that the perceptions of managers accurately resemble the truth - just stating what I think is going on.
Well, I'm curious how this management life improvement will manifest as they're also kicking out managers or at least forcing them to have quite a few more reports. At about 10 reports teams can't really be managed well.
> They are more likely to attend meetings ... give status updates, etc.
Weird. If I missed meetings and failed to give status updates (especially ones where my update was explicitly requested) my manager would go find out what the fuck was wrong with me.
> If you are blocked or are blocking someone, it's a tap on the shoulder instead of sending a message into the ether.
After more than four years of most software folks doing remote work, if your team hasn't established a solid protocol for doing IMs, voice/video chats, and email communications then your management has been fucking off and management deserves all the remote-communications failures they're getting. So, for the rest of this discussion let's assume that management hasn't been fucking off and you actually have a solid communications protocol.
If a coworker is regularly blowing off messages, then that's something that their manager NEEDS to know about. (And it's likely that if they're blowing off messages, they'd also be fucking off if their ass was in a company-provided seat.) However, if a coworker is failing to reply because they're working on something else that's more important then this is another thing that their manager needs to know about and consider reprioritizing your, their, or both people's tasks.
Frankly, I find the "get someone's attention with an IM (whether direct or in a team chat channel) or email" mechanism to be far, far, far better than having someone shatter my chain of thought by coming over to physically interrupt me. I know when I can't handle interruptions, so I can configure my software to not interrupt me. Others can't possibly know when I can't handle interruptions, so they can't help BUT to interrupt me during those periods.
The government also supports bombing the living fuck out of people on the other side of the world. Similarly, someone throwing 100m in the market does not unless they are taxed to do so.
Am I correct in understanding how firms like Jane Street work? They are a market maker - they run an exchange where buyers and sellers can transact. They can arbitrage these trades by connecting buyers and sellers where there is a price discrepancy. Something like that?
Almost always outside of crypto, the market makers and exchanges are different entities. Exchanges maintain order books- who is willing to buy or sell what, at what prices, plus a lot of rules about tie breaking, order visibility, "implied" prices (e.g. sometimes the combination of two products is logically equivalent to a third), etc. When orders "cross"- that is, someone is offering to buy at a price at least as good as someone is willing to sell for, the exchanges matches those participants and they are considered to have traded (though for a mix of technical and regulatory reasons, the trade actually settles two days later)
Market makers generally maintain offers to both buy and sell a product, generally ~all the time the market is open. For example, they might offer to buy up to 30 X for $0.99 or sell up to 70 for $1.01. If small buy and sell orders come in more or less randomly, the market maker will sell about as many X as they buy, for (1.01 - 0.99) a profit of 2c for each set of orders. The trick for a market maker is to offer the best price, so that they get any orders at all, while accounting for the risk that the person buying or selling from them (the liquidity taker) isn't just a random order, but is either market moving or correctly predicting the market is about to move- e.g. a market maker offering to buy a million shares of a X at $0.99 will lose a lot of money to someone who correctly predicted X is about to go to $0.70, and took them up on the full offer.
The big exchanges function much like a traditional exchange and Jane St, Virtu, etc all connect the same way (FIX) to make the market. Really crypto exchanges are just like FX markets.
Very little difference.
They light also be mining, but market making behaves the same as other traditional markets.
> Dietary risk factors (diet high in red meat, low in fruits, high in sodium and low in milk, etc), alcohol consumption and tobacco use are the main risk factors underlying early-onset cancers.
Are women under 50 who are now getting breast cancer really getting it because women are eating more red meat now than 1990? I don't buy it.
Breast cancer is generally thought to be caused by excessively high estrogen levels. There are other environmental and dietary factors that contribute to increasing estrogen levels..eating a burger is not one of them.
> Breast cancer is generally thought to be caused by excessively high estrogen levels.
If by "excessively high", you mean the normal range for pre-menopausal adult women, then yes. Otherwise, citation needed. Afaik, breast cancer is thought to be caused primarily by having breast tissue, and secondarily by the response of breast tissue to normal levels of estrogen. (People with higher estrogen levels than average tend to have more breast tissue, but that's more because they tend to have breasts than because of any impact estrogen has on the rest of the body – unlike people with lower estrogen levels than average, who tend to be men.)
And yes, estrogen blockers / SERMs are a good treatment for some breast cancers, but they don't eliminate breast cancer risk. Even cis men who have relatively low estrogen levels and hardly any breast tissue can get breast cancer.
This article buries the lede, but boy is that lede fascinating.
> Estrogen receptors are known to bind to certain regions of the genome when a cell is stimulated by estrogen. The researchers found that these estrogen-binding sites were frequently next to the zones where the early DNA breaks took place.
Estrogens are important for other things, so (what's effectively) menopause would be a rather impractical preventative measure for most people – but knowledge is still power. I'll have to read the paper sometime.
> Data from the late 2000s showed that the top 10 percent of American drinkers (approximately 24 million people) consumed an average of 74 alcoholic drinks a week, which means those with the most severe form of AUD purchase over half the alcohol bought in the country.
Like most of nutrition "science" the whole thing is a bad joke. There has never been a single high-quality study which showed a significant causative relationship between red meat consumption and worse health outcomes. All of the studies that I've seen have been observational, relied largely on unreliable patient-reported data, had small effect sizes, and failed to control for key confounding variables such as the healthy subject effect.
And what even is "red meat"? Are we talking about corned beef? Bacon? Venison? Grass-fed Argentinian beef? It's such a broad category as to be scientifically meaningless.
I think it's correlation -- people who eat a lot of red meat tend to eat a lot in general -- so it's just a proxy for obesity. That's the usual problem with studies of high protein diets, anyway.
Red meat studies, based on my googling skills a few years back, do not control for the cut of meat or method of preparation, so they are close to useless
I moved to NYC from SF about 4 years ago. I’ve faced a lot of culture shock and I’m not sure I’d recommend it. I don’t think NYC has what it takes to become an innovation hub, the way SF/San Jose/Seattle are. There’s a pervasive small-c conservatism here, an attachment to tradition in so many ways, that makes it tough for interesting, out of the box, uncomfortable ideas to take root. There are tons of lifestyle pros to living here (entertainment, food, people, transportation), but if you’re deeply interested in technology, innovation, pushing boundaries, etc, then you might not find what you’re looking for here.
1. Set an aggressive (but achievable) revenue goal for your first year. If you're having trouble figuring out what that might be, I suggest 500k ARR, because that will put you on a path to raising a series A. You should be able to hit this goal with fewer than 5 people in your first year. You should take a very hard look at your business and what's going wrong if you don't hit that goal.
2. Don't raise too much money for your seed. Plain and simple, you just do not need much money to build and validate your business plan. Whatever your number is, consider whether you'd really be much worse off if you raised half as much.
3. Start by providing professional services before you have a product. This will help you generate some early revenue, it will validate that someone is willing to pay for your services, it'll help you understand the requirements for your product before it's built, and most importantly, it'll help you build early relationships with crucial clients. Streamline these professional services by automating them with your early product. Over time, replace the professional services entirely with your product.
The role of a CTO at a startup (at any size company, but at a startup especially) can be very amorphous and depends on the needs of the business. Sure, a lot of the time the CTO is involved in the technical day-to-day ongoings of the business, but that doesn't need to be the case. If your business is struggling to find product-market fit, or close customers, or figure out product strategy, then your CTO might be preoccupied with those things instead of with technical tasks/management.
I'm hugely disappointed with OpenTelemetry. In my experience, its an over-engineered mess and the out-of-the-box experience is super user hostile. What it purports to be is so far away from what it actually is. Otel markets itself as a universal tracing/metrics/logs format and set of plug and play libraries that has adapters for everything you need. It's actually a bunch of half/poorly implemented libraries with a ton of leaky internals, bad adapters, and actually not a lot of functionality.
Agreed, I find myself having to think orthogonally to common sense whenever I try to use one of its SDKs. Nothing works the way you expect it to, everything has 3 layers of unnecessary abstraction and needs to be approached via the back door. Many features have caveats about when it works, where it works, how much it works, during what phase of the moon it works and how long your strings can be when Jupiter is visible in the sky.
That said, if we disregard the leaky SDK APIs and half-implemented everything, it does somewhat deliver on the pluggability promise. Before OTel, you had bespoke stacks for everything. Now there is some commonality - you can plug in different logging backends to one standard SDK and expect it to more or less work. Yes, it works less well than a vertically integrated stack but this is still something. It enables competition and evolution piece by piece, without having to replace an observability stack outright (never going to be a convincing proposition).
So while the developer experience is pretty unpleasant and I am also disappointed with the actual daily usage, from an architectural perspective it opens up new opportunities that did not exist before. It is at least a partial win.
Yes, I really agree, and I've gone through the same pain, but try using the alternatives that claim to be better because they have OpenAPI specifications [1]
The example shows you how to use the swagger tool, parse the OpenAPI spec [2], auto-generate GoLang glue code, call __one__ of those auto-generated functions and log a trace.
However, there is zero documentation, zero other examples, and I'm left scratching my head whether there's even one person in the world using this approach. I eventually ended up just directly using the service APIs [3] via REST calls.
OTEL is painful, but the alternatives are no better :( I really wish there's some interest in this space, since SLO's and SLI measurements are becoming increasingly important.
Prometheus text exposition format is de-facto standard used in monitoring. It would be great building an official observability standard on top of it. This format is much easier to debug and understand than OpenTelemetry for metrics. It is also more efficient, e.g. it requires less network bandwidth and less CPU for transfer than Otel for metrics.
It's a list of the behaviors you need to implement if you're rolling your own OTEL Tracer Span implementation, and not using one of the multiple available.
In contrast, OpenTracing's interfaces had hardly any required methods, so you had to do a runtime type-cast to the whichever implementation you were using in order to access anything useful on the Span like the OperationName.
Yes, all SDKs have a tracer you can just use. While you can technically create your own tracer, you're officially in Hard Mode territory - there's no highly extensible system I'm aware of that makes swapping core concepts (that already have a default) easy.
reply