1,167 karma · joined January 14, 2019
So then this becomes an exercise in cruelty, bringing a creature to life only for it to suffer a painful, short existence. Reminds me of Frankenstein, honestly.
https://github.com/PaulJuliusMartinez/jless
For when you aren't manipulating or querying json and just want a nice UI for exploring it.
When I see people argue that systemic racism is a driver, they're not arguing that there's a conspiracy directly targeting people of color. Rather, they're arguing that racism drives things that create conditions where people of color disproportionately suffer harm.
A classic example of this from several decades ago is redlining, which prevented people of color from moving into safer neighborhoods, and undermined the neighborhoods they were able to buy homes in. Settlement patterns have long-term generational effects, so while it would be incorrect to say that predominately black neighborhoods have higher levels of asthma, violence, poverty etc as a deliberate plot, it's absolutely true to say that those are consequences of direct racism from several decades ago.
I don't think this should be a particularly controversial point. Where I think it gets more controversial is two points -- 1. What redress, if any, should people downstream from historical racism have? They're still suffering the effects, after all. 2. What patterns and decisions are happening _now_ that will similarly have downstream generational effects?
I'm not going to even attempt to suggest answers to those, just hoping to illuminate the framing here.
I live about 13 miles west of the city as the crow flies, and its already suburban and not overly dense here, and just get more so west of here, still firmly within the metro.
Huh -- high-density London looks like.. Queens, NYC?
The term I've seen used is "bowlderize"
Not necessarily. I heard this about, I think "Ulysses," but probably applies to most published books -- there are almost always changes between editions (if a books goes through multiple printings), differences in printings between different markets (even if those markets are in the same language), notes the author may have written at home but didn't get published, notes the author wrote on the review copy that got left out of the published version or got misunderstood or misspelled or otherwise improperly published...
A "text" turns out to be a lot less definitive of thing than it may at first appear.
I point my telescope at a planet four light years away (I have super advanced telescope that can see these details), and use a worm-hole or other plot device to teleport instantly to that spot. Where do I arrive -- at what I observed, or at some point in empty space because I've just arrived at where that planet was four years ago?
If the former, I must somehow have traveled back in time by four years to arrive at the spot I had observed.
If the latter, I suppose we could instead say our destination is where we calculate the planet will be four years from now. Except that my travel time was instantaneous, so again either I've arrived too early and need to wait around for four years, or I jumped 4 years into the future (at which point that's not really FTL travel, just kind of stepping outside of time into some nether state for four years).
``` Once again in Roman Italy our situation is perhaps a touch better, although not particularly good. Because we have better demographic data for the rest of the free population and a better grasp on the mechanics of Roman agriculture, we can do something a bit better than blind guessing here (though blind guessing there has been in abundance), but not much better. Walter Scheidel walked through much of this math, guesstimating the urban enslaved population under Augustus (r. 31BC-14AD) at around 600,000 (based on an estimated breakdown of Roman social classes and estimates of how many enslaved persons each elite household might have) and another c. 600,000 in the countryside (based on rather more confident agricultural modeling showing the figure can’t be much higher than this without pushing out all of the small farmers and tenants we know from our sources there were) for a total of 1.2m probably representing the height of the enslaved population in Italy, coming as it does at the explosive conclusion of Rome’s long streak of rapid expansion in warfare.12 For an Italy under August between perhaps 5.7m and 7.0m that would imply an enslaved population of very roughly 15-20%, with a bit of wiggle room on both sides.13 This, we can be quite sure, is a significant increase from the earlier period so the figure for 225 BC and the Middle Republic must be lower, perhaps very roughly around 10%. Again, those figures are very rough, but I think Scheidel14 does a good job showing that something much higher, say, 30+% simply doesn’t make much sense given our evidence.
That actually is a useful conclusion, by the by, the full import of which I think has not been fully observed: while Rome has a reputation as the slaveholding society – and it certainly was a slaveholding society, make no mistake – those rates are probably rather lower than what we see in Greece, suggestive of an Italy countryside in particular that had more freeholding citizen small farmers than a comparable Greek polis. ```
[1]https://acoup.blog/2023/12/22/collections-how-many-people-an...
Work puts lots of items on my calendar -- recurring weekly meetings, kick off meetings, daily syncs, etc. And there's things I want to do, eg go to the gym, practice guitar, etc. I resisted putting the latter sort of thing on, because honestly I'm not a huge calendar person by default. Or todo person. I find it stressful and overwhelming. But I shifted my thinking to seeing the calendar not as a todo list, but as a visualization of things I believe are important. In that view, then giving my gym time a regular slot and putting it on the calendar gives it equal billing with all those work entries.
I've found this helpful and it has made me feel better about my calendar in general. It's not time management, or even commitments, but visible prioritization, with myself included as someone I prioritize.
The project I _had_ been on was central to the successful product line. I had built out a central part of that system and was proud of how well it worked and seeing the usage and revenue growth from it. The _new_ product was... changing the payment processing system we used for accepting credit cards. I mean, sure, a more flexible payment processing flow is a helpful improvement, but at a time of existential risk to the company, _this_ is what we should be focused on?
And actually, it was more than that -- the new flow had some kind of complex integration with a system provided by an outside vendor. And involved lots of sync meetings. Lots and lots of sync meetings. And every meeting would involve explanations by contractors (who seemed to multiply by the week) as to why we were behind schedule, and questions by me trying to get some documentation on the API I was supposed to interface with, and explanations of why the people on this call didn't have that info but I should set up a meeting with a different team of the vendor...
I assume there was some kind of kick back or other tie between the execs who approved this program and the vendor, as this project seemed more about pumping money out of a dying company and into this outside vendor than any kind of rational business strategy. I did move on after too long, and that previous employer is now officially bankrupt.
But it's not half of the city. NYC is more than Manhattan.
Though, thinking about it more, what it also tells us is that we need to be clear about what "the system" is. There are, after all, some systems that _do_ take nuclear blasts into account, or systems that take "physical breach by a hostile actor" into account.
Less dramatically, we make trade-offs all the time as to what we consider "in" system vs "out", and it's good to be conscious and explicit about them. We see this a lot in UI, especially web UI in terms of things like what browsers to support, whether we care about users' battery life or data cap limits, if we foresee ourselves running the system in a jurisdiction with different regulations around data collection and usage, etc.
There are two problems that tend to keep much software in what is essentially the "draft" stage, though. One, articulated by many on this thread, is that business incentives really push to "if it's working well enough, it's working well enough." And as some have noted, that's not necessarily a problem! We're, most of us, writing software for pay here, not for fun or personal expression. But! As engineers, we have more insight into if it's really working "well enough" (assuming that we, as engineers, have also taken the time to make sure we understand the product we're building). Things like performance, security, and maintainability are part of making sure it's "good enough," but our non-technical partners and stakeholders can't necessarily see this, and part of our role is to help them see this so that they are making truly informed decisions on if it really is "good enough."
Second, and I feel bad saying this, there's often a dearth of widespread technical ability to actually take code from "ok" to "good." I don't mean this in an elitist way of saying some programmers are just better than others -- I do truly believe that with proper support and mentoring almost anyone who wants to become a better programmer can (see my user name). But I think that as an industry, we actually do a poor job helping our colleagues advance and deepen their skill. The ratio of skilled programmers to new is too small, and of skilled programmers with ability and inclination to level up their junior colleagues even smaller.
That's a decision by business leaders, who by and large have decided that junior-heavy, cheaper dev teams are "good enough."
On the one hand, I'm afraid to say that I can't report any dramatic night and day difference. I do have in general more energy, better dental health, etc, but subjectively that all felt _slightly_ better, not click-baity better. On the other hand, I can report it hasn't been all that dramatic -- I didn't upend my life, made what really felt more like slight changes. Probably the biggest change for me was breakfast -- instead of carbs it's generally Greek yogurt, frozen fruit, nuts, and raisins (for sweetness), and coffee. I also check labels more -- who knew, for instance, that tomato soup had so much added sugar!
I take that as a win since, objectively, it _is_ much healthier to have less added sugars in my diet, and I got this gain without anything overly dramatic or disruptive. And it kicked off a gradual changing of other habits -- I got back to going to the gym regularly a few years after that, and have gotten better at keeping a regular bed time.
The tl;dr I'm trying to make here -- smaller, gradual changes do make a difference, are worth doing, and don't have to be dramatic (and are easier to stick to).
Layers of abstraction are powerful when they're tight and well-suited to their purpose (I'm happy to never think about memory allocation -- thank you garbage collected languages!), but when leaky or ill-suited can be very frustrating and make things harder or impossible.
It's hard -- probably impossible actually -- to build a "general purpose" abstraction layer that will work for specific purposes, but that's essentially the pitch of low code -- we don't know your specific use case, but we have a tool that will abstract away all the code previously tailored to that use case.
Now, in fairness, there's a lot of code that has too much accidental complexity in it. A good abstraction layer strips away that accidental complexity and leaves only the essential complexity that's specific to your domain and use case. But that's hard to achieve -- it takes skill and experience (and not just general experience, but specific to your domain experience) to achieve. Most companies don't have that available to them, and don't want to pay rates to build teams that do have that skill set and experience. Low code holds out the promise of being a short cut to that, but clearly if your own dev team can't manage it, the odds of a generic platform doing it for you is slim to none.
I'd been living in NJ for a few years before the pandemic and,just before the pandemic, had finally saved up enough for a down payment. We started looking summer of 2019, and were picky and not in a rush so were still looking when the pandemic hit. What this meant is I got to do a compare/contrast on my town's housing market. Right after everything shut down, there was no activity for a few weeks, but by spring things were restarting (with masking, or even virtual showings). What I saw is that inventory didn't increase -- maybe even decreased actually, as people weren't eager to move -- but demand became insane as people fled the city. Houses went for $50k or more over asking regularly -- the same houses we'd looked at the summer before and passed on because of shoddy construction or suspiciously strategically placed drywall in the basement.
I actually kept a spreadsheet to help me figure out how much we'd have to bid to have a chance without over bidding. We were finally successful in 2021, so got to take advantage of the super low rates, even though we ended up paying more up front.
Here's the summary stats I ended up with, sale dates 2020-06-25 through 2022-03-18
Square Feet Listing Price Sale Price List vs Sale List vs sale % diff
Mean 1,993.36 $568,002.74 $615,661.54 $52,770.80 9.67%
Median 1,872.50 $550,000.00 $610,000.00 $51,900.00 9.60%.
Max 3,700.00 $1,399,900.00 $1,400,000.00 $225,000.00 37.28%
Min 1,140.00 $300,000.00 $285,500.00 ($127,000.00) -19.54%
Quartile 25% 1,607.25 $495,000.00 $527,750.00 $14,750.00 2.78%
Quartile 50% 1,872.50 $550,000.00 $610,000.00 $51,900.00 9.60%
Quartile 75% 2,300.00 $625,000.00 $690,499.50 $91,250.00 16.72%