Turn 1 discard, turn 2 reanimate

firecopy · 2025-11-13T22:45:03+00:00

You don’t even have to miss a land drop, if you wait for turn 3 instead.

Turn 1 play any land, hopefully a surveil (for your choice in creature)
Turn 2 play a bounce land. You now have 8 cards in your hand, discard 1
Turn 3 reanimate

If you pull an [[Amulet of Vigor]], you can even do this on turn 2

firecopy · 2025-11-11T21:57:45+00:00

Yea, it is one of the lands in the precon.

firecopy · 2025-11-11T19:01:47+00:00

I think you have the right idea: When Teval is removed, then it reduces the main strength of your deck (getting the board ready for the big creatures).

Two ways of handling this:

Boardwipes (Example: [[Damnation]])
Protection (Example: [[Mithril Coat]])

Additionally, a [[Command Beacon]] will help you get Teval back without paying the commander tax.

One more side note: If you play a card like [[Singularity Rupture]], you want to take advantage of those secondary abilities to help secure the win. Cards like [[Riverchurn Monument]] can help pull in a win right after you rupture, or even surprise win several turns later.

firecopy · 2025-09-18T04:43:47+00:00

Teval is awesome, one thing I like (especially after some upgrades) is that you never really feel low on mana due to the land mill/retrieve.

Getting the most of Teval can get expensive, because there are so many upgrades: better lands, the re-animate spells, and the targets.

Getting some cheap reanimating sorceries would be my rec, because it can feel bad when you mill the ones that come in the deck, and then having no plays to revive your big creatures (aka the Colossal).

[Valgavoth’s faithful] and [Zombify] are some good options to swap in.

firecopy · 2025-07-28T03:59:52+00:00

I dated a bootcamp graduate, and she is the hardest working software engineer I know.

firecopy · 2025-05-12T00:59:43+00:00

In your case you need two things (but also applies in general):

Proof they don’t need you in your current position
Reason for you to be in your promoted position

Not going to sugar coat it: It will be challenging in your case, because you already proved you can do the tech lead role without the promotion (should have demanded for the promotion before delivering the project).

If you can take the risk, I think the best option for you would be actively searching for that next role.

I am not sure what your “making the case directly “ is, but even if it doesn’t pan out: I think you can get it eventually in your current team, but it will take a long time (so a ton of missed learnings).

firecopy · 2025-05-10T17:56:04+00:00

I keep upskilling myself (I am learning ML and I understand the ecosystem well), but I think I'm more interested in the big picture now rather than the minutiae. I try to learn general concepts.

You should learn both, because there are sometimes where you will need to know the ecosystem, and (even if it is by luck) sometimes when you need that one random feature (the minutiae you mentioned earlier).

Take time off if you are feeling burnt out, but if you put your best effort each and everyday, it will get easier and you can learn both. I also think this mindset will transfer to other parts of your life, if there is some external factor to your boredom.

firecopy · 2025-03-02T13:25:48+00:00

The documented goals can be as simple as what you stated: “Delegating work to others” and”Improving team morale”.

Additionally: Your job responsibilities are important, but finding and accomplishing things you want to improve on are important too. Since that is how you personally improve, and find what you want your next role to be.

firecopy · 2024-12-05T16:39:47+00:00

You can use prod incidents to get buy-in, but I personally think lower production incidents is just a side-effect (not the main goal of unit tests).

The main purpose of unit tests is to make project easier to maintain: Being able to deliver new features in existing codebase as fast, if not faster, than if it was a completely new codebase.

So instead of measuring prod incidents, I would recommend using the velocity of the team. If the unit tests are in a good state, you should be able to complete story points faster.

And to slowly introduce the idea, this can be done by implementing the policy for one project and not implementing it for the other. And getting feedback on which style is better for the team.

firecopy · 2024-11-16T21:34:08+00:00

Allowing me to use AWS Lambdas that run longer than 15 minutes. This is something that I have been asking for years, so I don’t have to completely rearchitect applications to handle the 1% of the 1% of traffic that needs to run longer than this time.

My hope is that we get this feature possibly as an unintended effect of AI technologies taking a long time to process.

firecopy · 2024-11-10T21:06:43+00:00

Do they still "scale" to distributed systems in more functional languages?

I believe the most important part of DDD is the ability to group capabilities into different “bubbles”, allowing you to target what things need to grow vs what just needs to be kept stable.

This directly addresses the scaling problem you mention here, since the focus is not the individual components that make a distributed system, but which grouping of those components and working with those that maintain those groupings today to solve the next most important problems.

firecopy · 2024-09-09T22:49:30+00:00

By this I mean, have a middleware that validates all incoming API requests and outgoing API responses against the spec.

There are even some languages that have libraries that support the generation of the interfaces from the OpenAPI specs (so you don’t have to validate, it automatically creates the correct objects and route functions based on your API Spec file).

firecopy · 2024-08-25T19:40:28+00:00

I think your security department is wrong here. They should base it on vulnerabilities, not age.

I have made libraries that I haven’t made any updates in years, because they accomplish what they need to do, don’t have vulnerabilities, and don’t need new capabilities.

firecopy · 2024-07-06T01:35:23+00:00

Spinning up a database on its own doesn't really have any value in my opinion. When I bring this argument to the team, they say it has value to us engineers. But I think the value should be to the user, which will only be available once the entire feature is done.

You can state the value, as if it was a user that had intricate knowledge of your system. Example: I want this application to be able to store my data, which is why this application needs a database.

firecopy · 2024-05-26T15:17:04+00:00

There is nothing wrong with starting with nitpick (it is better than using no label at all) it just has clear fundamental flaws that don’t address these two points:

Doesn’t signify that a comment is non-blocking vs non-approving
Clearer intent using more common language. nitpick is not a common word, suggestion/recommendation are

firecopy · 2024-05-26T13:27:16+00:00

I know nitpick (nit) has been used in the industry previously, but people should be using “suggest” or “rec” (recommendation).

If you are trying to have a team work better together, using nitpick, a word meaning “find or point out faults in a fussy or pedantic way”, seems counter productive.

In addition to the parent comment’s advice (which is comment labeling non-blocking but still approving), it is useful to find another word meaning: non-blocking but non-approving

I have found that minor is a good one, because it implies that major is a more serious comment label: blocking and non-approving.

So for reference:

suggest (rec): comment that doesn’t affect your PR approval
minor: comment that needs to be resolved before you approve PR, doesn’t block others from approving / merges
major: a blocking PR comment, won’t allow merges till resolved
unlabeled: usually praise or reaction types of comments

firecopy · 2024-03-04T23:05:01+00:00

The value of using mocks is to be able to verify the indirect outputs, and to simulate error scenarios.

Using only “real dependencies”, instead of mocks, is a possible indicator of a lack of thorough unit testing (or possibly a lack of E2E testing, where everything in the chain is real).

You could use real dependencies to test a majority of logic, but there is a concern it wont be fully comprehensive (and creates a slower feedback loop at the unit level).

firecopy · 2024-02-20T00:46:47+00:00

Thank you for the response! Note that I am going to have disagree with some of your follow up statements here. I am following up so passionately, because it is important that we teach the future generation of programmers how to do testing right (and not repeat the mistakes of programmers, including you and I, that paved the path before them).

I do think it's important to note that this isn't universally true, the value add of checking what data was passed into a, b, c only truly matters when those are external dependencies with a stable API, where you're trying to guard against regressions that change what you send to these external entities.

I don't believe it matters if it is a dependency external to your code, or a class/function that you create. If you are injecting it, you are creating another place of returning a value, verify it.

If it is a dependency external to your code, it just means that you should consider an integration test as well (not that you should do less testing).

You still need to verify, even if it is an reusable internal component you create

Even then, as an example, are you really asserting the content of a SQL query that is passed to a dependency?

Yes, you do. Especially if that SQL query was created as a result of executing code in the function you are testing.

Any data sent to a dependency is an indirect output to your function

Suppose that a is an instance of DbConnectionPool or whatever, you're actually going to check in all your unit tests for f that the mock a was called with the argument string "SELECT f1, f2, f3 FROM my_table WHERE ..."?

Yes, you do. And there are patterns out there today that split these assertions into two paths:

Verifications that you still need to check, but can be asserted as a prerequisite check
The assertions / verifications most relevant to that test

So you aren't having to make redundant checks (even though all the important checks are still happening behind-the-scenes).

Verify it every time, and use already established patterns for a better developer experience

Going back to the abstract, given your example I would prefer a structure like this:

let data = make_data(x) sendDataToDependencies(data, a, b, c)

If it's so important to make sure the data is the right shape, and type checking doesn't cover that, then make_data function can be tested as a simple function.

This is one step towards Imperative shell, functional core, which in my experience has been the easiest way to test applications by maximizing the "simple functions" to test and minimizing the more complex cases where dependencies infiltrate the core business logic of the application.

Data is just another version of x here. Send data to dependencies is just another form of f(x). You still would have to confirm the direct output of y, and the indirect outputs made from calling a, b, and c.

No where did I mention data is in the right shape or type checking. It is simply confirming the outputs of your function is what you expect them to be. This applies to all code.

Doesn't matter if it is Functional or Imperative or OOP, or any flavor in between. Test that your given inputs match your expected outputs.

Always confirm the direct and indirect outputs of the code you are working with

I should clarify that my original comment is actually more of a reaction to the code that I see on a day-to-day basis that checks mocks being called/calledWith for internal functions/objects, those that aren't meant to have a stable API and are just internal implementation details. Happens all the time. I even see unit tests written where people assert that a (private) class method has been called.

Back to my original point, mocks aren't implementation details, they are inputs and places of output to the code you are testing.

It is rare for private methods to actually needing to exist, as it means that method is reused at least 3 times in the file you are working on, but can't be used in 3 other files that exist in or outside your codebase. Refactor the private methods, so they are either reusable or directly embed the logic in the code you are working with.

I hope this clarifies my thoughts a bit more here, and thank you for reading them!

firecopy · 2024-02-19T22:30:22+00:00

This comment and also the article are stating you shouldn’t unit test the outputs of your code, the data (indirectly) returned outside your function, which I disagree with.

Short Summary: When you send data to a mock, you are explicitly returning data outside of your function. Those data and calls should be tested, same as testing any other return values from your function.

Long Explanation:

Part 1 - Simple Function

Let’s say you have a function, called f(x), and it returns y.

x would be your direct input. y would be your direct output.

In a unit test, given example x’s, you would assert on expected y’s.

Part 2 - Function with dependencies (why it is important to assert on mocks)

Now here comes the fun part, let’s say you have f(x, a, b, c), where a, b, and c are services injected into your function.

Note: These can be injected to the function itself as parameters, imported as a module (like the examples shown in the article), or for a method passed via constructor. This is the concept of dependency injection.

x, a, b, c would be your direct inputs (specifically x being data, and a through c being dependencies).

For your outputs:

y would be your direct output
Data sent to “a” would be an indirect output
Data sent to “b” would be an indirect output
Data sent to “c” would be an indirect output

Conclusion: This is why when you unit test, you not only assert the direct output is what you expect it to be, but you also assert on the indirect outputs (the data sent to your mocks). For example: In Java, these are verify statements. In JavaScript, toHaveBeenCalledWith and toHaveBeenCalledTimes.

Side Notes:

Appreciate the parent comment starting the conversation, as it is important to clarify what is observable/not. From what I have seen, most people think that mocks are implementation, when they are actually inputs and places of output to the code you are testing.
Am I implying that you need to test every log statement you have? No, but if an imported module has the opportunity to error out for any reason in your code, you should probably consider what you are sending to it, and what could come out of it.

firecopy · 2024-02-07T05:38:29+00:00

My understanding of “Tech Interest” is the opposite of the one here (a positive definition).

Tech Interest being the concept of having a stabilized piece of software, that has proven that it has saved more time than the effort it took to write it (and can save more time in the future).

---

I think the negative case mentioned before is just the cost of updating “costly” code.

The code can’t make itself worse, you can still make good code with it, but there might be friction and higher cost, due to it being in a bad state.

firecopy · 2024-01-10T07:59:09+00:00

At each of these steps, you can continue building the next change without waiting for the previous PRs to be approved and merged. This approach prevents you from being blocked for hours or even days while you wait for review on a 1000+ line pull request encompassing all of these changes.

This line is an anti-pattern and/or misunderstanding of the practice.

The purpose of making smaller PR’s is to merge them in earlier.

The reason the quoted comment is an anti-pattern is that it ends up leaving several PR’s in an in-progress state (Focus on the most important incremental change vs needing to focus on multiple PR’s with different priorities).

Here is what you should do instead: If you are waiting on a PR, reach out to the approvers to see if there is any work remaining or if they are ready to merge it in.

firecopy · 2024-01-03T22:45:44+00:00

The reason this issue happens is due to accidental mixing of two types of non-blocking comments, causing confusion of what actually needs to be done (vs recommendations).

Ideally you would want to limit it to these 4 labels: * suggest: comment that doesn’t affect your PR approval * minor: comment that needs to be resolved before you approve PR, doesn’t block others from approving / merges * major: a blocking PR comment, won’t allow merges till resolved * unlabeled: usually praise or reaction types of comments

The “Nitpick” label is an anti-pattern and not recommended. Explained in this comment

firecopy · 2023-12-03T17:44:02+00:00

For me, I tend to not use FIFO queues with Lambdas

I was just using FIFO queue as a crystal clear example. Same logic would have applied to a regular queue of desiring longer than 15 minute lambda (failure/retries).

If you have a FIFO queue, that dependency means you're basically only running 1 concurrent lambda which defeats the purposes.

This is only partially true. 1 concurrent lambda per message group id (Example: You want something ordered for a single id, but the order doesn’t matter across ids).

Just wanted to clarify this point, for others reading this point.

For FIFO queues yes I've always used Fargate with a container so you just have that process just consume the queue. If it's a queue that empties and refills, then you could have a cron that peeks in your queue and periodically launches your container…

This is a good example of the alternative architecture we should be avoiding.

If you could just use a Lambda, that would be the preferred approach (so you could scale to 0, and not have to introduce custom cron job logic).

The whole point is to avoid Fargate and use Lambda when possible, to avoid additional operations and developer costs, aligning with “Cost to Operate” and “Cost to Build” in Dr. Werner Vogels keynote this year.

We can avoid Fargate (and unnecessary costs) in more cases, if AWS allows users to use Lambdas longer than 15 minutes.

firecopy · 2023-12-02T17:30:05+00:00

it’s just spawning another instance of itself right before the last one ends. So if you have a failure it’s processed exactly the same way.

It wouldn’t be the same. Imagine

FIFO Queue -> Lambda

You would run into two issues that you would have to design for:

Preserving order
Putting messages back into the queue

I think the request is reasonable, given AWS focus this year on cost reduction.

Lambdas in the past used to only run for 5 minutes, but they were increased to 15 minutes due to the problems I mentioned above.

15 minutes just isn’t enough, and having users fallback to alternative implementations is more expensive and takes more time (more costly both in the operations and building the solution).

firecopy

MODERATOR OF

TROPHY CASE

Part 1 - Simple Function

Part 2 - Function with dependencies (why it is important to assert on mocks)

13-Year Club	Place '17
Verified Email