The scourge of "Claude said..." is rampant.
If you use "Claude said", it had better be in a sentence that is structured something like:
"When I did some digging, Claude said <thing>, so I looked into that and it looks like it might work based on <x, y, z>."
not
"Well, Claude said <thing> so you're wrong."
Claude says many things. Claude is very often wrong. Even when it's right, you should know why it's right.
Own your work. Don't delegate all thinking to AI.
More and more people are asking me about testing resources so let's put everything I've written in one post. Bookmark, share, and, most importantly, please read these.
The True Purpose of Testing
https://t.co/KwnelsWjhp
Developers often overlook the fundamentals and rush into writing tests without properly understanding what a test is and what is its function. No test is inherently useful just because it exists. Read this one to learn what makes it useful.
The Golden Rule of Assertions
https://t.co/3pZ5bcT3lo
There's a lot of debate over what makes a good test. In this one, I'm defining a short and objective way to grade a test's quality no matter the language or the tested system. This is, without a tinge of exaggeration, a game-changer in how you approach your tests.
Anatomy of a Test
https://t.co/yT1ihVfORT
Let's talk about the building blocks that make up any automated test. From JavaScript to Go and Rust—these blocks power tests everywhere. Know your blocks.
Implicit Assertions
https://t.co/WmpC4nN4Zm
Did you know there's a way to express expectations in tests without writing "expect"? Those are called implicit assertions and they are tremendously powerful because they help you express more by writing less.
Inverse Assertions
https://t.co/ItgBFRc5oz
Sometimes you need to assert that something did not happen. That can be tricky, especially if that something is asynchronous. The last thing you want are false positives. What you actually want is inverse assertions.
Making Use of Code Coverage
https://t.co/fr6BJ5BOxT
Code coverage has been an ongoing debate in the engineering circles. Is 100% code coverage in tests good? Bad? When should you strive for it? Why do people say it's harmful? I'm answering all those questions in this one and giving you practical tips on when to use (and not to use) code coverage.
Good Code, Testable Code.
https://t.co/Eenwjb25vV
You've gathered by now that some code is easier to test than the other. But why? Let's take a look at the characteristic of code's testability, what defines it, what is its relationship with complexity, and how to make your code more testable.
What is a Test Boundary?
https://t.co/iF5OoW3xsF
Automated tests rarely involve your entire system (yes, even the end-to-end ones have exceptions). There's often a place where you draw the line. The boundary. Learn what it is and how to use test boundaries efficiently to focus on the exact behaviors you want to test.
Be S.M.A.R.T. About Flaky Tests
https://t.co/CXK6um3mfJ
Flakiness is the scourge of reliability. If you've written a test before, you likely had experience with flakiness. But what is it at its core and what causes it? And how should you deal with flakiness?
Writing Tests That Fail
https://t.co/3HJauq4zRb
You write tests for them to fail. We all enjoy a green CI, but the true value of tests is when they fail. What matters is when and how they fail.
I see the resistance is increasing as I go. 🤣
Let me try to go through these somewhat linearly.
> he's selling a course
All of my teaching materials are now and forever free. I'm obsessed with effect systems and want them to win, because I think they're incredible. There's obviously a learning curve, but it's paid back many times over.
> effect is fucking garbage
We'll get back to this one 😅
> it's not typescript
I think they later discover it is TypeScript.
> it doesn't use the type system.
I think they later discover it uses the type system.
> okay, it's abusing the type system
I don't know what that means 😅
Type systems exist in order to enforce constraints based on static analysis. If anything, it is lovingly embracing the type system, caring for it as its never been cared for before, fulfilling its deepest and truest purpose (it's all very romantic, really).
> this should be in another language.
It actually was. Effect is based on ZIO (https://t.co/dqmmV25QXs). This is an effect system written in Scala. I was a core maintainer on this library for years. In fact, you can see a younger and rather out-of-shape me in a video on the home page.
I slowly came to the realization that TypeScript is the only way that effect systems have any shot at relevance.
So far it's working brilliantly. Many well-known startups and established companies are adopting it. I'm even engaged in a rousing bout of word combat with a startupful of lowercased and pixellated opponents. This has never happened back in my Scala/Haskell days, those libraries wouldn't have even crossed your radar.
> we sound super combative
I prefer to consider it sparring. You sound super sparring! It's invigorating. ✊😎🫴
> ts is an imperative language
JavaScript is a famously function-friendly language, having shipped with lambdas (function values) at a time when that was not at all common in mainstream languages.
JavaScript is also famous for React, which is a way of declaratively specifying user interfaces.
>
Did I miss anything? 😜
This week many people have asked me which courses should they take to take their cursor skills to the next level, and like really exploit all of its features.
For those of you unaware, @cursor_ai has launched a beautiful and impactful online course to teach how to write software using Ai models and tools. Not only that, the one taking point on this is the legend @leerob who has this rare ability to explain things in such a unique and entertaining way that keeps you focused the whole time while being effortless for you.
Take a look and let us know: https://t.co/H4pFy1ugkr
I've a new life goal, and that is to ensure that Effect Systems prevail. While Haskell and ZIO were my first loves, they're sadly, hopelessly marooned on their respective research islets.
The only choice is to fully commit to @EffectTS_. Which is, thankfully, extremely good.
I'm joining Cursor to teach the future of coding!
There are millions of developers learning how to use AI and they need pragmatic advice:
1. We need to teach new developers strong foundations, so they know what to learn, and how to solve issues when debugging.
2. We need to teach experienced developers how AI can automate the tedious parts of coding, or save them time reading docs and fixing bugs.
3. We need to help developers become even more competent. AI may end up writing most of your code, but you have to review, understand, and maintain that software.
This is why some experienced devs are having a great time with AI. They can ask for a pattern like "add an exponential backoff" instead of “make it more robust to errors” which may or may not work.
I want to help developers become an order of magnitude more productive, and help more people contribute to building software.
This is going to take a *lot* of education and retraining. So expect more videos soon, and if you have ideas for what I should teach, let me know!
Here's 13 API's you probably need to know about to get started with Effect.
Rest of it, you can JIT
---
Basics
Effect.gen (declare a function where you can yield* other effects inside)
Effect.fn (like Effect.gen, but can receive custom parameters)
.pipe (add modifiers to an Effect)
Effect.runPromise (run your effect as a promise)
Effect.all (Promise.all, but for effects)
Errors
Effect.try / Effect.tryPromise (wrap non-Effect code)
Effect.mapError (map the errors in non-Effect code to your custom error inside a .pipe)
Data.TaggedError (create a custom error)
Effect.catchTag (catch an error)
Dependency Injection
Effect.Service (declare an interface that can be later injected)
Effect.provide (provide an implementation of an Effect.Service to a .pipe)
FileSystem.FileSystem (inject a file system implementation later for testing)
What questions do you have about Effect that are not answered by:
1. Effect is to TS what TS is to JS
2. Use it for high-stakes backend projects
3. Turns your code into a huge ball of best practices
4. The education buy-in is huge, but worth it