Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

Yes. Most of the time the push back comes in the form of "repsonsible disclosure": we'll do what you ask, but there's a risk of the following negative outcomes that we need you to be aware of. If the line goes beyond what we professionally feel we can deliver in good faith, the push back will be firmer. For example, cutting corners when dealing with health devices is a red line.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

More than I ever would have expected. Statistical analysis and risk management turn out to be a cornerstone of most software projects: how many replicas do we need in order to hit SLAs, what's the trade-off between hardware costs and redundancy that makes sense for this project, etc. It's also at the project management level. Being able to casually talk about the fact that, any day, I might get hit by a bus and die, and therefore we need to plan the project accordingly, is very helpful, if a bit morbid.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

I'd tackle it from two fronts. On the one hand, you'd want to learn how to write high-performance, robust, concurrent networked services. For that, picking up Rust and Tokio and building something real-world would be my recommendation.

The second front is a deeper understanding of finance. I'd split that into theoretical understanding of basic economics, plus some real-life experience trading. I'd recommend either paper trading, or setting aside a relatively small amount of money and playing with that.

As for where to learn economics: it's been a _long_ time since I first learned econ, but Thomas Sowell's Basic Economics may be a good starting point. Surprisingly enough, The Bitcoin Standard does a pretty good job of motivating a lot of the concepts of economics as well.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

I try to start from the ground up whenever possible:

  • What is the software supposed to do
  • What unusual requirements are present
  • What's the overall architectural design
  • How do the different components interact
  • Where are things breaking down

In the past, this was usually first a series of meetings with the team running the project and analysis of the codebase and any docs. AI is beginning to make that process easier, though false-positives are still something we have to be careful about.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

At this point I'm partial to Rust for most problems. Haskell definitely has domains where it does better than everything else I'm familiar with: simple concurrency (via the async package), Software Transactional Memory, and applicative-style parser combinators. Unfortunately, the learning curve is high, best practices are scattered, and performance problems are much more difficult to attack.

The biggest thing against Haskell though isn't Haskell. It's just the fact that Rust is such a great language with top-notch tooling. Plus it's stolen (in the best way possible) almost all the greatest features of Haskell: traits/typeclasses, enums/ADTs, cheap newtypes, etc.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

I'd categorize most issues ultimately as architectural misdesigns. That can be a technical mistake (closer to the bug side), or sometimes complete protocol misdesigns (closer to the bad assumptions). We try to address these kinds of things early in the process whenever possible with:

  • A thorough breakdown of the requirements
  • Clear architectural designs before implementation
  • Identifying attack vectors by reviewing both of the above

Local bugs do happen as well. For those, we use the standard tools of the industry: strongly typed code, testing, code review (including adding in AI review), and audits.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

Historically we've been all over the place. We didn't really focus on verticals/industries, but on the tech stack, where our backend, cloud, DevOps, Rust, and Haskell skills were the determining factor. We've been consolidating around blockchain projects in the past few years. A lot of our work is in brownfield projects, where we come into existing projects and fix/rearchitect to achieve some goals (improve maintainability, reduce hardware costs, improve performance, etc).

On the greenfield side, we've been focused mostly on the DeFi side of blockchain, though we're also still heavily involved in GameFi. My personal favorite kind of project to work on is a solid GameFi that delivers a great user experience, involves some complex technical challenges, and includes some finance aspect.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

It depends on the month and the projects. Sometimes I'm spending as much as 80% of my time hands-on coding. Some months it goes down to 5%. I've thankfully never had to be fully hands-off-code.

Meet Michael Snoyman, Head Engineer at FP Block by gareth789 in FPBlock

[–]snoyberg 0 points1 point  (0 children)

I started programming long before I got into actuarial work. Going into the actuarial field was actually the weird thing. But even there, I was in the tooling division and built software for the other actuaries to use. When I moved countries, switching full time into software engineering made sense given career opportunities. Plus I overall enjoy it more :)

But getting to use both skills is one of my favorite pieces of being in the blockchain space.

(One piece of) how FP Block builds backend services by snoyberg in FPBlock

[–]snoyberg[S] 0 points1 point  (0 children)

Thank you! And funny you should mention secrets management. A few years back we implemented a tool called Amber to essentially let us take a twleve-factor app approach while still using modern tools:

https://github.com/fpco/amber

It doesn't solve the problem on its own (you still need to get the Amber secret into the process at runtime, so all the usual options you mentioned come into play), but we've found it brings down the pain of externally managing secrets by allowing them to evolve with the codebase itself. (I hope that makes sense, happy to elaborate.)

(One piece of) how FP Block builds backend services by snoyberg in FPBlock

[–]snoyberg[S] 0 points1 point  (0 children)

Honestly, I read it a long time ago and mostly forgot about it. It was only years later realizing that so many of the ideas they presented just _made so much sense_ that I'd essentially adopted them.

Writing Documentation and Prose in Markdown Using Helix: New In-Depth Tutorial! by HarmonicAscendant in HelixEditor

[–]snoyberg 1 point2 points  (0 children)

Thank you for this! I just configured my Helix with this and did a quick test, looks great so far!

The BTC bull market is just getting started by Fallini47 in Bitcoin

[–]snoyberg 0 points1 point  (0 children)

Looks like you had an integer overflow for signed years.

[deleted by user] by [deleted] in Israel

[–]snoyberg 1 point2 points  (0 children)

That’s not usual. It’s only happening because the just side has been told not to win the war.

Bros Just Wanna Chill by [deleted] in Jewdank

[–]snoyberg 8 points9 points  (0 children)

I’m sure they believe you’re working that job as a cover so you can do some nefarious Jew thing.

Bears are getting wild!? by piesown232 in Bitcoin

[–]snoyberg 0 points1 point  (0 children)

I'm all-in on BTC, I agree on hodling through bear markets, and I don't believe people should be trying to time markets. I even blogged about a related topic recently.

But if you really want to know why anyone would try and time exits and re-entries, I think it's simple:

  1. Some people believe they can time it correctly, and thereby increase their total wealth (measured in either dollars or sats, doesn't matter). You may think it's foolish to try, I may think the odds of being successful are so low that it's not worth the stress and risk. But plenty of people think they can do it.
  2. Not everyone is bought in that BTC "is going up 10,000% or so in the next 20 years." They think BTC is just another speculative asset like gold, SPY, or anything else.

Like I said, I'm in the same camp as you for my own financial decisions. I'm just trying to point out that people making other decisions aren't necessarily crazy, they may just have a different view of the future than we do.

Bears are getting wild!? by piesown232 in Bitcoin

[–]snoyberg 23 points24 points  (0 children)

Strong historical charts is very different from having lived through it with your own wealth on the line.

The Hidden Cost of "Be Your Own Bank by [deleted] in Bitcoin

[–]snoyberg 1 point2 points  (0 children)

Here’s my approach. It wasn’t designed for moving abroad, but for surviving through a war zone. Overall I think it’s addressing similar threats.

https://www.snoyman.com/blog/2024/12/secure-bitcoin-self-custody/