balefrost

It looks surprisingly cozy.

When I read code, it's not a passive activity. I'm navigating and searching. Sometimes I bring up external documentation. In short, I'm interacting with my computer. For me, reading code requires typing.

Dan's general attitude is that crypto isn't revolutionary and isn't really trying to be. It's not trying to democratize money. It's trying to build a system with the same power dynamics as the current system, but with different people at the top of that power structure. His take is that crypto doesn't solve any of the problems with the existing systems and just creates a bunch of new ones.

My recollection is that he doesn't spend much time on the energy use (he touches on it but IIRC doesn't dwell on it). He does go deep into the "wild west" state of them. His attitude seems to be "wild west" isn't a transitory phase; it's the end state of crypto.

I don't think he says it in that video, but in a subsequent interview, Dan pointed out a danger with this and all deflationary currencies - they reward early adopters and people with a lot of capital. People who buy in late (either by choice or because they were simply born later) have a compounded difficulty in "catching up". He says he's worried about a future where crypto isn't an option and everybody needs to use it to some extent in day-to-day life. Moms and dads - or toddlers - who didn't "get in early" will be at a significant disadvantage.

---

Personally, my main concern is with PoW. It's fine to say that PoS will eventually replace PoW, but that's not the situation right now. PoW is wasteful by design, and that just rubs me the wrong way. It's great that miners tend to use more renewable sources on average than the average utility customer, but they're still using an awful lot of nonrenewable sources as well. I guess I just think about all the other things we could do with that electricity and it seems like such a waste.

My secondary concern is with the hype machine in overdrive. It feels a lot like the dotcom bubble to me - people making all kinds of wild claims about crypto, NFTs, web3.0, etc. Everybody so desperately wants it to be the next big thing because they smell an opportunity to make a buck. But it feels very cart-before-horse to me. It's not clear to me, for the kinds of problems that crypto is trying to solve, that crypto is the best solution to those problems. How many use cases really call for a decentralized, trustless ledger?

This article (https://thecorrespondent.com/655/blockchain-the-amazing-solu...) mentioned a couple of projects that got greenlit due to blockchain hype, yet either don't have anything to do with blockchain or else use blockchain in pointless ways - such as having a small, fixed pool of trusted mining nodes controlled by one entity.

When you rewrite history, Git makes new commit objects that have the same topology as the original branch topology. It also updates the branch pointer to point at that new HEAD commit.

History rewriting commands essentially just fork the repo at some point in the past and create an alternate commit history. The original commits still exist, at least for a little while. Git will eventually garbage-collect them.

By creating a backup branch, you're "pinning" those old commits. With the backup branch in place, after you run a command that rewrites history, you will be able to look at the commit graph and see the point where the backup branch and the rewritten branch diverged.

I used to do what you do until I learned more about how Git works internally. And Git's really not super complicated at its core. I think much of Git's complexity comes from the minutiae of the CLI options. (For example, when you want to delete something, do you use `-d` or an explicit `remove`? It depends on the command you're running.)

But hey, if you have a workflow that works, then you do you.

https://github.com/pluralsight/git-internals-pdf/releases

git branch blah_branch_backup

Later, if your merge gets completely messed up, you can do:

git merge --abort

git reset --hard blah_branch_backup

That final command will restore the current branch's HEAD to point to the same commit as blah_branch_backup.

This same pattern is useful for other dangerous commands, like rebases or filter-branch.

When you're done, just delete blah_branch_backup.

I'm US east-coast, suburban, and definitely not inside the SV culture bubble.

Not as the boat flies. To be fair, I know nothing about shipping logistics... but it seems like quite a detour to me.

Convince the 6 developers that they don't need more than 30s each during the "tech only" standup. Get the facilitator to aggressively chop long discussions (clarifying questions can be fine; discussions and debates are not). At least, move long discussions to the end of the standup so that people who aren't relevant and who don't care can leave.

Initially, my team's standups (I think 4 devs at the time) would be 15-20 minutes; we're now (6 devs) down to 10-15 minutes, probably 10s more than 15s.

I can't imagine there being much value from a daily, 30-minute, whole-team meeting with multiple stakeholders. Developers should perhaps talk to specific stakeholders... but those conversations should be focused on specific stories and probably should be done in much smaller groups. Heck, it would be fine to have 30 minutes of scheduled "office hours" time where specific developers can talk to specific stakeholders about specific stories.

Bring this up in retrospective. Point out that (nominally) 12.5% of every day (and likely more than that) is being spent on these meetings. Ask about what value people see in these long meetings and if there's a better way to achieve that value. Brainstorm other approaches and get the team to commit to experimentation.

Try, you know, actually standing up. On your feet. That's where the name comes from and it's to encourage people to be brief.

What has worn me down over the past few years is the constant refrain that we are "behind" and "don't have time" for a lot of things that appear to me to be essential. We've been in a mode where we don't really have time to explore options. And once we've made a decision, we rarely revisit it even as information changes.

I don't think this has anything to do with agile per se. One could argue that it's Scrum's fault, but even then I don't think you can lay the blame directly there. The point of sprints is to create frequent steering points. As new information comes up, let's make sure that we're still pursuing the correct course. But sprints can easily be misunderstood to be frequent deadlines that must be hit. There's some value there, but I think that misses the mark somewhat.

I think a lot of it stems from a conflict of personality styles. From what I've seen, some people like the treadmill - it gives them direction, purpose, and energy. But for somebody like me, that treadmill is more of a grindstone.

I fully recognize that "public interest" can be twisted in all sorts of ways, but I agree with the GP comment that taking land from some people to give it directly to other people does not conform to my understanding of the spirit of the eminent domain law.

Is there a transcript / blog post version of this 30 minute video? I don't think so.

It probably depends what you're comparing to.

Yeah, since FPGAs essentially implement combinatorial logic, and hard CPUs are also implemented in combinatorial logic, you gain no benefit from directly "porting" the hard CPU to the FPGA.

But, if your hard CPU is a microcontroller that can only process say 8 bits at a time, but you really want to process say 256 bits at a time, it might be more efficient to use an FPGA to build a soft CPU whose architecture better matches your problem. In that case, you should be able to do more work per clock cycle with the FPGA.

That's arguably "increased parallelization", but what I'm talking about applies to sequential algorithms.

Of course, in that case, maybe you chose the wrong microcontroller. Maybe a full CPU would be a better choice, or maybe there's a DSP that can be adapted to the specific use case.

it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU

Sure, that makes a lot of sense at the high end. I'm thinking of problems more in the embedded space, where FPGAs might be a bit more attractive.

One other benefit of that is you maintain object identity. I don't think that Scala's wrappers do that.

I don't know the entirety of the tax law, but I believe that you're supposed to make estimated tax payments quarterly.

https://www.irs.gov/businesses/small-businesses-self-employe...

Is that an actual law, or is it just that some implementations of the pattern are deficient? My impression is that the actor model was originally envisioned as being applied to a machine with hundreds or thousands of processors.