I've seen a rumor going around that OpenAI hasn't had a successful pre-training run since mid 2024. This seemed insane to me but if you give ChatGPT 5.1 a query about current events and instruct it not to use the internet it will tell you its knowledge cutoff is June 2024. Not sure if maybe that's just the smaller model or what. But I don't think it's a good sign to get that from any frontier model today, that's 18 months ago.
Why do you think that what I wrote implies they are static?
I didn't say that recursion and caching are the opposite of dynamic, I said they are essentially orthogonal concepts to it.
Generally speaking, dynamical systems are systems that have some sort of dependence on time [1]. In dynamic programming we have an optimization/decision problem in which time plays an essential role. The optimality is measured with respect to the whole time evolution. Bellmann showed that you can break this intertemporal optimization down into individual time steps.
So the key observation of dynamic programming is how to turn an "all times at once" problem into a "one time at a time" problem.
The reason that Hamilton's name shows up next to Bellmann here is that physicists and mathematicians (Lagrange, Hamilton, Jacobi) figured out that you can do the inverse: You can write the dynamical equations of physics as an intertemporal (all times at once) optimization problem. This has been one of the most influential ideas in theoretical physics _ever_, especially after Noether's theorems leveraged this structure to connect symmetries and conserved quantities. In many fields of theoretical physics you no longer write down differential equations to model a dynamical system, you write down a "Lagrangian", and mean that your system follows those trajectories that minimize the integral of the Lagrangian over all time. So the central ideas of dynamic programming are extremely tightly related to physics and dynamical systems.
Edit: After reading a bit more I think I understand why people focus on this. The algorithmic examples with shortest paths sort of show the point. To me the core point of Dynamic Programming is before you start thinking about recursion or memoization. It's when you establish that you have optimal substructures:
what is dynamical is that the subproblems depend on each other, in the way that what happens at time t+1 depends on what happens at time t, or, more to the point, what is the optimal decision at time t depends on what the optimal decision at time t+1 is. If your subproblems are ordered by time, then of course you don't need recursion to solve them, you just iterate over time steps, hence my confusion.
I'm taking a free course in CUDA programming on Udacity at the moment that's co-taught by a guy from NVIDIA Research and a professor from UC Davis. If you're looking for something that starts from the basics and is really easy to follow, I highly recommend it.
Ugh. Of course the Enterprise Architecture rears its ugly head here.
Just here to say that you can quickly build a robust feature with only OpenAI's APIs, redis, a text file for the prompt you parameterize (versioned), and a little bit of glue code (no LangChain). You can add instrumentation for observability around that like you would any other code.
I would wager that most enterprise use cases don't need most of the tools listed in this article, and using them is complete overkill.
Over the years, it's gotten me consulting gigs and the occasional job offer (amidst other projects).
Today, it sends a decent chunk of the traffic and sign-ups to my startup, Wafris -> https://wafris.org
OP's asking for a strategy with these, and the advice I'd offer is to treat them like assets. You make these various side projects to learn something, take the extra 20% of time to package it up buy a domain, and spend $10 on a logo or something to make it a little more like a project and not just a repo.
If it's not something directly usable like this, take some screenshots and collect them into a gallery on a personal site.
You stack these assets over time (and like my example above), they pay off over years in all sorts of ways.
I work at a FAANG and it was absolutely astonishing to find out how often this happens.
You can make a long, impactful career by just being "the guy who adds log statements throughout the codebase and reasons through it", doing this at even a simplistic level has always shown me an astonishing fix to some long-standing issue.
n.b. It also attracts a ton of political fun. People's first order reaction is denial, and it only gets worse from there. Absolutely no one except 1-2 colleagues will see it as "oh we should fix that", and at least one person will make sure your boss' boss' boss is CCd on an email with a nice version of "no he's just insufficiently concerned about {concurrency, memory management, take your pick}" Just wait it out quietly when that happens, do not engage or complain. If nothing happens and you're never asked about it by leadership, but your peers ask, make plans to move onto another team.
Reading Ben Lynn's Haskell website was one of the things that got me out of a rut with learning Haskell and showed me how expressive, yet concise it is. There's a lot of advanced and beginner Haskell resources but not much intermediate. I highly recommend his Haskell series, Lambda Calculus series[1] and (my favorite) compiler for Haskell series[2].
It's as if SICP were redone in Haskell in the 21st century.
I keep giving this advice on how to significantly increase your chances of getting to the interview stage.
Most candidates really only submit a resume. The chances of getting to the interview stage with this approach are almost zero.
Because everyone does this, you can easily stand out. Simply answer the following 2 questions briefly in plain English.
1. Why do you want to take this role?
2. Why are you a good fit for this role?
Example:
1. I've read through your website and documentation and are truly inspired by your vision. Especially that you're working and X thing really got my attention as I know that Y and Z are super important for the customer segment you're working on.
2. I have previous experience in this field and wrote an open source library to solve some of the issues you might be facing (link).
Simply out, show interest and explain why you're a good fit.
I've had too many candidates who never checked out our landing page (https://wundergraph.com). We're doing a lot of innovative stuff in the API segment. If you apply for a job with us and you don't have an opinion whether you like what we do or not, it's really hard to gauge interest.
The question I'm asking myself is. Why should I read your CV when you didn't bother skimming through my landing page, docs, or open source repository. What's the purpose of sending a CV when I have to do all the hard work?
If you are interested in hyper-scale event processing but you want to learn it from first principles, I strongly recommend following Martin Thompson's talks. Here is an example of one on cluster consensus:
After digging through all of this material and playing around with LMAX Disruptor & Raft, I have been able to develop a really good understanding of how to build these sorts of systems on my own. Fun constraints like "Only one thread actually mutates anything, and its the same one over and over" make for incredibly elegant implementation opportunities. Not having to constantly hunt down exotic thread-safe data structures means that you can focus on building actual value.
Latency is the biggest devil you will dance with in this arena, so almost everything you do will be oriented around mitigating that effect. Latency both at the network and inside the CPU/memory/storage. It applies at every level.
A little more theoretical, but for programming language, there's "Programming Language Pragmatics" which covers imperative, functional, logical PLs and everything needed to make them run from runtimes, linking, virtual machines etc. It's not as demanding or in-depth as e.g. the "Dragon book".
A few shorter books have come out that try to touch different approaches that I've liked: "Seven Languages in Seven weeks" -- and the series has also gained 7 databases, concurrency models and web frameworks.
Finally, there's this anthology where OSS authors described what they did in their applications, so there's a ton of practical information http://aosabook.org/en/index.html
Leetcode premium -> do all the problems for the company you are targeting, sorted by most frequently seen in the last 6 months. Then, you will know what your weak points are (mine were minimax and disjoint set problems), and you can go through questions tagged with those topics. Aim to complete at least 60 problems, you should feel fairly comfortable with any Leetcode medium grades, and DFS implementation. Leetcode hard questions are good challenges which could expand the way you approach problems, but in my experience, did not show up much during onsite interviews.
Also, "completing" one problem in the context of the above does not mean being able to solve it the first time without checking the solution. It means possibly struggling with the problem for 20 minutes, checking the answer, and making sure you can do it the next day without looking at the answer. YMMV.
Assuming you have some experience building simple single-node systems:
- Read Designing Data Intensive Applications. As others have said, it's a gem of a book, very readable, and it covers a lot of ground. It should answer both of your questions. Take the time to read it, take notes, and you should be well set. If you need to dive deeper into specific topics, each chapter links to several resources.
- Read some classic papers (Dynamo, Spanner, GFS). Some of these are readable while some are not-so-readable, but it'll be useful to get a sense of what problems they solve and where they fit in. You may not understand all of the terminology but that's fine.
That should give you a strong foundation that you can build upon. Beyond that, just build some systems, experiment with the ideas that you're learning. You cannot replace that experience with any amount of reading, so build something, make mistakes, struggle with implementation, and you'll reinforce what you've learned.
Backend is vast, and this helps you build a general sense of the topic. When you find a topic that you're really interested in (say stream processing, storage systems, or anything else), you can dive into that specific topic with some extra resources.
> I understand Postgres the best, and would love to know why these and others exist, where do they fit in, why are they better over PSQL and what for, and if they are cloud only what's their alternatives....It seems all of them just store data, which PSQL does too, so what's the difference?
A lot of that depends on the way you're building a system, the amount of data you're going to store, query patterns, etc. In most cases, there are tradeoffs that you'll have to understand and account for.
For example, a lot of column oriented databases are better suited for analytics workloads. One of the reasons is for that is their storage format (as the name says, columns rather than rows). Some of the systems you mentioned are built for search; some are built from the ground up to allow easier horizontal scaling, etc.
If cache coherence is relevant to you, I strongly recommend the book “A Primer on Memory Consistency and Cache Coherence”. It’s much easier to understand the details of coherency from a broader perspective, than an incremental read-a-bunch-of-blogs perspective.
I found that book very readable, and it cleared up most misconceptions I had. It also teaches a universal vocabulary for discussing coherency/consistency, which is useful for conveying the nuances of the topic.
Cache coherence is not super relevant to most programmers though. Every language provides an abstraction on top of caches, and nearly every language uses the “data race free -> sequentially consistent”. Having an understanding of data races and sequential consistency is much more important than understanding caching: the compiler/runtime has more freedom to mess with your code than your CPU (unless you are on something like the DEC Alpha, which you probably aren't).
If you are writing an OS/Hypervisor/Compiler (or any other situation where you touch asm), cache coherence is a subject you probably need a solid grasp of.
These are forums with extremely helpful members. The format is different than Stack Overflow's "Question/Answer". It is built on the "Post/Thread". You can have threads that go on for 40 pages and span a year, when someone is doing a project, and these magnificent creatures will accompany the users with feedback.
One thing I've done when starting to do PCB is submitting the design to electro-tech-online.com asking for feedback and how I could improve it. You'll have people there with decades of experience go through it, make actionable suggestions on the design stinks and why they're not good.
You can also share a project you're doing as you are doing it, and they can help with the brainstorming/ideation and implementation, they would ask questions and question assumptions.
If you write firmware for microcontrollers, they can also chime in and help you refine the code. If you get into that community, you'll be on a fast track because you'll have people who can do that in their sleep help you in the nicest way.
PCB Design:
You can get yourself CadSoft EAGLE or KiCad, print the tiny documentation in a booklet format, then read the whole documentation, page by page, annotating it, trying every functionality. Making routes, ground pour, layers, with commands and with the mouse.
Dave Jones' "PCB Design Tutorial"[0], will also be very helpful.
Soldering:
Check out Dave Jones' multi-part videos on soldering[1][2][3]. Part 3 is for surface mount, don't bother with that just yet.
Electronics
Depending on where you're starting from.
Absolute beginner? Take a look at Tony Kuphaldt's "Lessons in Electric Circuits"[4]. It is split into multiple volumes (DC, AC, Semiconductors, etc...)
Somehwat beginner? Take a look at "The Art of Electronics" by Paul Horowitz and Winfield Hill. It's one of the books one has to have just in case civilization is destroyed.
Fun trivia: The chapter on transistors explains them by introducing a figure called "Transistor Man". That figure was drawn by Edward Purcell, which you may have heard of from CPMG (Carr-Purcell-Meyboom-Gill). He also won the Nobel Prize for the discovery of the Nuclear Magnetic Resonnance.
You can get an electronics test board like [5] on which you can experiment circuits without soldering them, and with fewer flying wires. The ones that have the screws that hold power input are nice. Then you can buy a bunch of operational amplifiers, LED, logic cates integrated circuits, resistors/capacitors/inductors and play with that.
A bit more advanced or not:
- Texas Instruments' "Op Amps For Everyone"[6]
- "Op-Amp Concepts" by Greg Kovacs
- "Op-Amp Applications Seminar"
In depth:
- "Troubleshooting Analog Circuits", by Robert Pease.
More in depth:
Application notes from manufacturers to get ideas for designs.
But to sum it up:
- Getting on dedicated forums
- Getting the test board and components (to tinker)
- Getting software for PCB design (just for the design)
- Share the design on forums to improve fast
- Print the board at a PCB shop
- Solder the components following the tutorial
- Learn more and more and go deeper at every phase after every win
So you may first start by getting components and assembling them on the board to make a circuit work, then designing a PCB for them and soldering them to make a working "prototype", but you will also learn more reading the books, exchanging with others, reading application notes or resources from manufacturers.
I read a Murakami novel in high school, 1Q84. The protagonist is a math teacher who talked about math in a way that I had never seen before. I'd been told I was "good at math" beforehand(for whatever that means, I'm not a fields medalist or anything), but for ~6 months after reading that book, I was _really good_. Like, suddenly I did not have to do any homework in my sr. year calculus class. I loved sitting in class and watching my teacher work through problems, and it seemingly imprinted directly into my brain, because while doing no homework I could still ace the exams while writing with a pen (no erasing and re-do'ing with a pencil). All because of the way this fictional teacher from 1Q84 talked about math.
Has anyone else had an experience like that? (With math or other things?)
I've used all of these so I might be able to offer some perspective here
In an ELT/ETL pipeline:
Airflow is similar to the "extract" portion of the pipeline and is great for scheduling tasks and provides the high-level view for understanding state changes and status of a given system. I'll typically use airflow to schedule a job that will get raw data from xyz source(s), do something else with it, then drop it into S3. This can then trigger other tasks/workflows/slack notifications as necessary.
You can think of dbt as the "transform" part. It really shines with how it enables data teams to write modular, testable, and version controlled SQL - similar to how a more traditional type developer writes code. For example, when modeling a schema in a data warehouse all of the various source tables, transformation and aggregation logic, as well as materialization methods are able to to live in the their own files and be referenced elsewhere through templating. All of the table/view dependencies are handled under the hood by dbt. For my organization, it helped untangle the web of views building views building views and made it simpler to grok exactly what and where might be changing and how something may affect something else downstream. Airflow could do this too in theory, but given you write SQL to interface with dbt, it makes it far more accessible for a wider audience to contribute.
Fivetran/Stitch/Singer can serve as both the "extract" and "load" parts of the equation. Fivetran "does it for you" more or less with their range of connectors for various sources and destinations. Singer simply defines a spec for sources (taps) and destinations (targets) to be used as a standard when writing a pipeline. I think the way Singer drew a line in the sand and approached defining a way of doing things is pretty cool - however active development on it really took a hit when the company was acquired. Stitch came up with the singer spec and their offered service is through managing the and scheduling various taps and targets for you.
I've read that book and others. NSTD is both extremely good and extremely bad.
TLDR: It's a great book if you can ignore his attitude. And ignore every negative thing he says about Ivy MBA programs and their books. He is simply wrong about them.
The good:
The methods advocated in the book are somewhat "simple" to remember. This is because he focuses on what will work 70-80% of the time, whereas other books tend to also target the remaining scenarios, creating bloat and complex methods.
This is probably the best book when it comes to the psychological aspect of negotiation. The other books do have it, but tend to focus more on the rational aspects.
The bad:
Writing style can be very offputting. An incredible amount of boasting. A lot of it is justified, given he was one of the FBI's top negotiators. But he goes well beyond it. He starts the book describing how he walked into a Harvard class on negotiating and completely dominated the other students with his negotiation prowess. And he goes on and on about how he beat the Harvard students. Really? In my warped view of the world, I thought it was a given that a Harvard student new to negotiations should be able to beat the FBI's top negotiator.
This was beyond pathetic. It's as if Roger Federer wrote a book boasting about how we visited a tennis academy and managed to trounce everyone. What an achievement!
The anti-academic bashing is strong, and quite unjustified. Throughout the book he boasts that his techniques are way better in the real world than what the academics/Ivy schools teach. Umm... no. I read the Ivy school's books before reading this one, and roughly 70-80% of the techniques in NSTD are the same as the ones taught in MBA programs.
I've noted many parts of NSTD where he makes a false claim against the Ivy Books, or where he claims the Ivy Books don't teach Y. One day I intend to write a detailed review on a blog somewhere listing all his claims, and next to each one quoting one of the Ivy Books refuting his claims. It's just very dishonest of the author to criticize other books this way.
(And no, I don't think any of the Ivy Books actually suggest splitting the difference as a good strategy - I recall one even saying it is an option, but mostly if nothing else is working and your BATNA is not good).
Finally, some good books talk about different negotiation strategies based on your relationship with the person. When you don't care about the other person (e.g. haggling in a marketplace), the strategy you would use differs very much from one where you value the relationship (e.g. business partner). He doesn't really distinguish, and it's not surprising given his background where most of his professional negotiations were one-off.
Please be careful when using his tactics with people you want to maintain good relations with. They work well the first few times, but some of them really start to annoy people. One of my managers left our team and was replaced by another one (new to managing). The new manager used some of these techniques, although she had not read the book (especially the continual "How can I do that?" questions). She was relatively successful in the negotiations, but it damaged a lot of relationships. 3 people eventually moved to other teams.
If one is looking for additional books to read, I recommend:
- Bargaining For Advantage (not very prescriptive, but this is the best one to make someone interested in negotiations and want to learn more).
- Getting Past No. You probably should read Getting To Yes before reading it, though. GPN has some overlap with NSTD regarding the psychological side of negotiating.
Getting To Yes is often recommended. It's decent. My only caveat is that it is not as broad as BfA, and because it gets recommended all the time, a lot of people feel GTY is "sufficient". When it fails for them, they abandon the whole discipline thinking they're just not cut out for it.
Not specific to negotiations, but I recommend as well:
- Influence. Many books (including NSTD) invoke this book.
- A good book on communications (e.g. Nonviolent Communications or Crucial Conversations).
A lot of negotiation techniques are derived from these two topics, and they'll make a lot more sense if you've read them.
Finally, regarding salary negotiations, there's actually a really good one in the book, which is the flip of what is usually taught. The conventional wisdom is that if you can't get your desired salary, negotiate on other things (work environment, work from home, hours, vacations, perks). He flipped it around. If it seems they won't match your salary, keep asking for benefits/perks that are somewhat reasonable, but you're confident they can't provide them. The company will usually say "Sorry, we can't provide that perk, would a $x increase in salary do?"
I haven't tried it, but I can see it would work - most large companies have a limited set of variables they can tweak, and cannot customize much for a single employee. So they compensate by increasing the offer.
Well, the best way to learn is to actually do something. Create a small service in your favourite framework. Something really small, an echo service will probably suffice.
Then stop "developing" and switch on "Ops mode".
Automate:
- builds (build & packaging scripts)
- deployments - try all 3 major approaches:
- push deployment: running a command on a central server that orchestrates everything (Ansible, Salt, chef-solo, ...)
- pull deployment: agents running on your target server, that pull the latest changes (Chef, Puppet, ...)
- immutable infrastructure: VMs or containers that are never modified, only recreated (CloudFormation, Docker, ...)
include database updates in your deployment orchestration and possibly include even environment pre-warming/pre-caching
- functional tests, especially fast smoke tests
Add:
- high availability/load balancing (Nginx, HAProxy, Apache, Elastic Load Balancer)
- detailed technical monitoring and graphing (Nagios, Zabbix, Cloudwatch)
- availability monitoring (Pingdom)
- a status page (can't give you a decent example; you can build your own, but host it somewhere else than your main "app")
- log collection and shipping (Splunk, Graylog)
Basically, for almost everything I listed google options and pick an "Ops stack". Then implement that as best you can.
Oh, and by the way, while working on the "Ops stack", only "develop" things in support of this Ops work in your "app".
I do not have advice directly addressing your question about how to read, but I will say this:
A lot of this complex-dense-technical stuff is difficult precisely because it can get abstract. That is true for example in writing proper C for kernel development (your field) and physics (my old field) and chess (everybody's field).
My solution is to do lots of exercises and learn lots of examples before learning these big theories. Essentially I think learning is fundamentally Pain. You have to take on the pain before the learning can alleviate it, if you try to skip the pain then you have only a superficial idea of what you're talking about.
So like if I am learning Go, I am writing a command line Fibonacci calculator in it, then I am rewriting this ground-up with test driven development so that I can learn what testing looks like in Go, then I might try to build an HTTP server, then I might connect it to a database, then I might learn how to mock the database. Each of these tasks I am setting for myself needs to be answered by consulting tutorials and references, but if I just follow a tutorial I will not build true knowledge, I will just know how to do things when someone is holding my hand.
I don't see this mentioned by other commenters so let me provide another perspective. Namely, I think OP is doing it wrong.
OP claims to have done 400+ LC problems over a couple of months. Let me say it out loud here: this is simply crazy. It strikes me as an attempt to not learn how to tackle these challenges, but to actually brute-force through them. To anyone preparing for an interview: don't do this! Grab a book like Elements of Programming Interviews (EPI), maybe follow some online courses on programming puzzle patterns, and then start grinding LC. Maybe interleave grinding with learning? Your end goal should be to develop deep understanding of what you are doing, not memorise the solutions.
Also, while going through LeetCode, it is very important to realise that the problem classification there is a bit wild at times. Don't stress that you cannot solve a medium sometimes as they are mislabeled. I did mediums that could be hards, hards that could be mediums, and hards that were just impossibly hard. Typically a very hard problem is not something you should expect in an interview setting as most interviers* don't expect you to implement KMP on the spot. Doesn't hurt to know it and impress the interviewer with knowledge, but if you think memorising KMP is the way, you're mistaken.
* - there is still luck involved and you can have a crazy interviewer. It can happen, so just accept it and move on. Don't treat it as a personal defeat.
Source: I grinded and I had offers from most of FAANG letters.
So, I've read most of these. Here's a tour of what is definitely useful and what you should probably avoid.
_________________
Do Read:
1. The Web Application Hacker's Handbook - It's beginning to show its age, but this is still absolutely the first book I'd point anyone to for learning practical application security.
2. Practical Reverse Engineering - Yep, this is great. As the title implies, it's a good practical guide and will teach many of the "heavy" skills instead of just a platform-specific book targeted to something like iOS. Maybe supplement with a tool-specific book like The IDA Pro Book.
3. Security Engineering - You can probably read either this orThe Art of Software Security Assessment. Both of these are old books, but the core principles are timeless. You absolutely should read one of these, because they are like The Art of Computer Programming for security. Everyone says they have read them, they definitely should read them, and it's evident that almost no one has actually read them.
4. Shellcoder's Handbook - If exploit development if your thing, this will be useful. Use it as a follow-on from a good reverse engineering book.
5. Cryptography Engineering - The first and only book you'll really need to understand how cryptography works if you're a developer. If you want to make cryptography a career, you'll need more; this is still the first book basically anyone should pick up to understand a wide breadth of modern crypto.
_________________
You Can Skip:
1. Social Engineering: The Art of Human Hacking - It was okay. I am biased against books that don't have a great deal of technical depth. You can learn a lot of this book by reading online resources and by honestly having common sense. A lot of this book is infosec porn, i.e. "Wow I can't believe that happened." It's not a bad book, per se, it's just not particularly helpful for a lot of technical security. If it interests you, read it; if it doesn't, skip it.
2. The Art of Memory Forensics - Instead of reading this, consider reading The Art of Software Security Assessment (a more rigorous coverage) or Practical Malware Analysis.
3. The Art of Deception - See above for Social Engineering.
4. Applied Cryptography - Cryptography Engineering supersedes this and makes it obsolete, full stop.
_________________
What's Not Listed That You Should Consider:
1. Gray Hat Python - In which you are taught to write debuggers, a skill which is a rite of passage for reverse engineering and much of blackbox security analysis.
2. The Art of Software Security Assessment - In which you are taught to find CVEs in rigorous depth. Supplement with resources from the 2010s era.
3. The IDA Pro Book - If you do any significant amount of reverse engineering, you will most likely use IDA Pro (although tools like Hopper are maturing fast). This is the book you'll want to pick up after getting your IDA Pro license.
4. Practical Malware Analysis - Probably the best single book on malware analysis outside of dedicated reverse engineering manuals. This one will take you about as far as any book reasonably can; beyond that you'll need to practice and read walkthroughs from e.g. The Project Zero team and HackerOne Internet Bug Bounty reports.
5. The Tangled Web - Written by Michal Zalewski, Director of Security at Google and author of afl-fuzz. This is the book to read alongside The Web Application Hacker's Handbook. Unlike many of the other books listed here it is a practical defensive book, and it's very actionable. Web developers who want to protect their applications without learning enough to become security consultants should start here.
6. The Mobile Application Hacker's Handbook - The book you'll read after The Web Application Hacker's Handbook to learn about the application security nuances of iOS and Android as opposed to web applications.
With Vim 8.1, you don't even need a package manager, since there is one
built in. Just clone the Git repo into your
~/.vim/pack/vim-lsc/start/vim-lsc/.
This is a topic I'm very interested in. I have a few links (no books sorry), and would be keen to talk to you if you're interested (email in bio). I have had fantastic success with negotiating benefits and extra pay, just the other week I received 4 weeks paid paternity leave up front on top of an already generous salary offer. It is a skill worth having
In other news, I built and deployed a "2FA Mule" last weekend.
It's a stock android phone with no google account and no apps installed except for "SMS Forwarder"[1].
It is configured to forward all SMS to an email address via encrypted SMTP. This means that I can receive these 2FA codes anywhere I have Internet access - such as an airplane or newly arrived in a foreign country where my SIM card does not work.
The "2FA Mule" itself is plugged in at my office in a corner.
I'm not employing this for anything sensitive but it's interesting to consider that I can use SMS based 2FA while divorcing it from my day to day SIM identity ...
Seconding Hardcore History and The History of Philosophy without any gaps.
Adding Mike Duncan's (same host as Revolutions) The History of Rome.
Lots of substance in all 3 and continuous stories with conclusions you can learn from, and just enjoyable to listen to of course especially Hardcore History.
