Which means either I've learned nothing at all, or something changed in between.

For those who missed it (or didn't want to follow a link on the first sentence of an article): I'd had five projects going at once, my nervous system was fried, I was saying yes to everything without even looking, and it took me about a month to dig myself out of the PRs that came back. I concluded that we have to do less. Well, now I can juggle two to six tasks at once.

The models might have gotten marginally better, but that's not what changed. I was right that I had to do less, but I had the wrong unit. The problem was how much I was asking the model to do in each stride. And by lowering that amount I can keep more things in parallel actually moving.

Before any of the specifics, the thing all of it is built on.

So what is a stride?

A stride is the smallest thing I can ask for that gets me in the right direction from green (passing tests) to green. I do have a final destination in mind, and I share that with the model, but a stride is really the smallest directionally correct step I can take. In practice that's usually one behaviour, and the test that drove it.

Of course, I'm building on the shoulders of giants here, and GeePaw Hill's Many More Much Smaller Steps is what inspired this. Stop here and go read that, I'll wait, and it's worth it! The final trigger was a conversation we had on A Junior, A Senior and I with Tim and Paul.

I'd rather bound a stride by time, the number I care about is the minutes between meaningful interactions. But the model can't feel time. If I ask it for "about ten minutes of work", it hands me a feature. It can count lines though, and 40 is a size it can both hold and check itself against.

Here's the shape of one. Say I want a report to leave a blank rather than a zero when there's nothing to measure yet. The test comes first:

test "reports no median for a step where nothing was paid" do
  report = EffectivenessReport.new(rows: [step_with_no_payments])

  assert_nil report.rows.first[:median_days_to_payment]
end

And then the change that makes it pass:

- median_days_to_payment: row["median_days_to_payment"].to_i
+ median_days_to_payment: row["median_days_to_payment"]&.to_i

You'll notice that this stride is quite small. Not all of them are like that, but I want to stress that a stride is not necessarily a feature, it can be as small as a three line change. Most are around 40 lines, but I don't have many 200+ line diffs anymore. One stride is one commit.

Once the stride is done, it's up to me to decide where we're going next (although the word generator sure likes to make "suggestions").

But how do you run six at once?

One stride at a time is easy when you're in one lane. The reason I can be in six is that opening a lane costs me nothing.

claude-dev task <task-name> opens a tab, creates the worktrees if they don't exist, and lays out four panes: a claude session on the left, resumed if one already exists, and shells on the two worktrees and their shared parent on the right. It's tmux inside Ghostty, and you can probably reproduce it with other tools. That's the whole thing — I'm not really in need of a helicopter view.

I'll usually have two to six of those running. One of them is my actual priority. The others are things that need less attention from me: migrating legacy code, migrating specs. Sometimes something small someone asked for, a graph, some quality of life thing. When a new thing pops up, I reach for claude-dev task <new-thing> and pick the first stride.

Once a stride is done I get a notification, and I open the tab to be greeted by the diff. On the whole I'm interacting meaningfully with each task every 5 to 10 minutes, and each interaction lasts anywhere from 30 seconds to 5 minutes.

I'm steering the system, and yes, that's context switching all day long. The difference is what a context costs now: 40 lines and the test that drove them, instead of a whole branch I have to rebuild in my head.

The part I won't hand off

This is the part I don't want to hand off. The model is bad at it.

When a stride lands, two things arrive with it: the diff, and a suggestion for what to do next.

The review pane gives me the files that changed, a map of what else in the codebase references them, and then the diff itself. That's enough to see whether it's doing what I asked, and to the standard I expect. Since it's small, I can go through it quite easily and fast, and it doesn't take much out of me. From there I either approve, or I leave a note:

   def overdue?
-    due_on < Date.current
+    due_on < Date.current && !paid?
   end
 
-  def formatted_total
-    "%.2f" % total
-  end
+  def formatted_total = format("%.2f", total)

Scope creep like this is the most common thing I have to push back on. The note I'd leave, in the review pane:

the formatting change is unrelated, revert it and keep the stride to the one behaviour

Once I close the review pane, either I tell it I left a note, or I look at suggested next strides. About two times out of three I pick one of the suggestions, but not always the "recommended". Strides are small, so if they're directionally correct that's usually good enough. If I'm not convinced I tell it to do a different stride.

Throwing the conversation away

While I could deploy most strides as I go (they go or should go from green to green), ten minutes of CI per PR is enough to make me batch. So in order to deploy I bundle two to five strides together and create a PR at that point to trigger the CI and merge if green is confirmed.

One problem I had with this approach is that my context got bigger and bigger, and corrupted with unimportant artifacts (pushes, side conversations, etc). One thing that unblocked this is the introduction of cycles. A cycle is just that bundle: two to five strides, one PR, one merge.

Once a cycle is done, I have a /cycle command that will:

• run /handoff: gotchas and lessons go to memory files, progress goes to the plan, anything a reviewer needs goes into the PR description. Then it writes a handoff. Where this task is going, how I'll know it's done, what's green and what's pushed, and one next stride.

• close the claude session

• and run claude-dev cycle which starts a new claude conversation that reads the handoff, gives me a one line status and the next stride it proposes, and waits.

That buys me tokens, and it flushes two sets of temporary memory: the session's, and mine.

Some numbers, because you'll ask

The numbers I care about are the small ones: the median commit adds 59 lines, tests included. While I ask for 40, the model does overshoot a little. Nine out of ten are under 211. These are diffs I can parse easily, and correct on the fly.

Volume and PR count are probably the least interesting ways to measure "faster"... So here they are anyway.

Since the 1st of June, across both repos, I've made just under a thousand commits, over the 41 days I actually worked (the rest was holiday). In the same period 354 of my pull requests were merged, and at Recovr merging means shipping. So call it 24 commits and 8 deploys on a working day.

The number I'd most like to give you is the one I don't have: bugs in production. My honest read is that they're stable, maybe lower. That's a gut feeling and you should hold it against me.

With 8 merges a day, it's rare that I have a branch open for more than a couple of hours. That's the closest I've ever been to trunk based development, with all its benefits (low conflicts, code exercised sooner, etc.).

Which invites the obvious question: who reviews eight PRs a day? After the fact, mostly nobody. We use Ship/Show/Ask, and this way of working has taken full advantage of it. I review every line of code as I go (remember strides are small now) and in a trusting team formal PR reviews end up being quality theatre anyway. Ask is still there for changes that deserve another set of eyes.

And if you read all of this as "way more work", I've written this badly. I'm shipping sooner, not really faster.

If you want to try this

I'm not going to tell you to copy my setup. The tmux part is incidental and you'll want your own anyway. But if I had to rebuild this on a new machine tomorrow, there are five things I'd want back, roughly in this order.

• Small steps, as an actual rule. For me that's a skill file the model loads at the start of every session: what a stride is, how big it's allowed to be, and that it stops after each one. Everything else here is plumbing. This is the part that does the work.

• One command to start or resume a piece of work. Mine creates the worktrees, opens the panes, and either starts a session or picks up the one that was already there. Not having to assemble that by hand is most of the difference between running one task and running six.

• A handoff, and a way to cut the session. Where this is going, what's green, what's pushed, and the one next step. Then throw the conversation away and start the next one from that note.

• The diff, in front of you, automatically. Not "go and look if you remember to". It shows up when the step is done, with the files that changed, what else references them, and the code.

• A way to clean up. When a task is done, something that removes the worktrees and closes the window, and refuses if anything in there is uncommitted.

What all of it really buys me is permission to forget. Whatever mattered is written down by the time the session ends, so I don't have to carry it into the next one.

Last time I said the answer was fewer lanes. It wasn't, it was shorter strokes.

A clear direction, where to go,

I concentrate, I take it all in,

And so I start, without a stop.

-

It's ten AM, no time to breathe,

A single focus, reach my goal,

And so I write, it is a breeze,

My laptop, me, we are one.

-

In my head variables fly,

Functions appear out of thin air,

All the fluff is just gone by,

All my issues disappear,

Just look ahead, I am almost there.

What is that? A fly?

-

Disaster struck, where is my flow?

What was I doing, where am I?

All the variables, are they gone?

What was I doing, where am I?

-

The fly flew on, where is my flow?

What was I doing, where am I?

I have a test, somewhere I think?

What was I doing, where am I?

-

The clean begins,

All those small things,

That felt redundant,

Tests, refactor, clean.

-

They keep me grounded,

Like an anchor,

They get me back in.

And yet, it's never wrong,

It does give quick feedback,

And most of it for naught.

-

My code is impatient!

And yet, often impuntual,

For decisions long forgotten,

It gives me painful stabs.

-

My code is a bad teacher!

And yet, it teaches well,

On one single subject,

But, for that one, it excels.

-

And yet, I've been promised,

There is a golden path,

It sure would be great,

If all of them were right!

Sadly, that seldom coincides with the most urgent.

A solution to that is to carve a space dedicated to the important rather than the urgent.

At Recovr we realized a few months ago that we were consumed by the urgent.

Our solution has been to optimize for the flow of our main priority. We decide on a main priority when the previous one is done, and there is one person responsible for its continuous flow.

This has allowed us three things:

1- the most important feature is always visible and prioritized.

2- the most important feature is in constant movement.

3- we have (surprisingly?) more space for the urgent.

These don't just happen by magic, but rather a combination of factors:

• The visibility of the advance of the main priority ‘buys’ a lot of goodwill from the rest of the teams.

• Since the people that are not on the main priority can be interrupted, it's easier to tackle ad hoc emergencies

• The people working on the main priority fluctuate, this allows us to expand or contract capacity for ‘non main priority’ work.

Our rules for the main priority are quite simple:

• A main priority must have a DoR (Définition if Ready) with at least a MoSCoW priorisation.

• There is one person responsible for the main priority, and they can ‘recruit’ anyone from the team they need to make the priority move forward.

• The main priority takes precedence above other things, it cannot remain sitting in a queue.

• The person responsible decides how the work is shared/performed and communicates with the rest of the company.

We have noticed that the other teams are quite happy with this arrangement as it increases both flexibility to tackle urgent things and visibility on our next most important feature.

If you are drowning in urgent things, and have trouble advancing important work, I recommend you to try and set up a main priority.

When you tell someone that you work in an agile team, or that you want to be more agile, chances are that they hear:

We do Scrum-like things

That is good and bad.

On one hand, most companies will have some inflexible rituals, applied without thought. I am looking at you stand up!

On the other, at least they changed some things. (hopefully in a deliberate manner).

While your team’s way of working and personalities will probably not be uncommon, their combination and circumstances are probably unique.

As such, following a prescribed practice, static in time will not optimize for most important things.

What is important in software teams:

This is an opinion, but I hope it is a shared one.

Priorities that should be shared among all or most software teams are, in order:

• Producing software that solves our user's needs. (And makes enough money)

• Producing software that has few, if not none, defects.

• Producing software fast.

• Being able to adapt the software to changing needs.

• Being able to sustain it indefinitely.

There are other sub priorities, but I think they are encompassed by the above ones.

And your team might have other specific priorities as well.

How to address these priorities:

I understand it would be quite ironic if I were to prescribe a list of practices here that you must do after having complained at people following prescribed practices.

But people have been thinking about these problems for a while, good places to start would be to look towards Lean, eXtreme Programming, DevOps and the DORA report

What I would say is that to address these priorities you must be willing to adapt, to change how you work regularly, in small increments and with buy in from the team.

Something that worked for us is to have frequent retrospectives, that might work for you. But in any case, you must be able to change when something is not working.

Doesn’t Scrum address that?

[The practices I describe below have been addressed in the latest versions of Scrum. I will leave the original version below annotated with square brackets, as a self reminder that jargon matters and I should research things better. I invite you to see the scrum guide 2020 here: https://scrumguides.org/scrum-guide.html before continuing.]

I am not a Scrum expert. But everywhere I worked at, Scrum artifacts have existed. They might be a good starting point, but I don’t see them as an end goal.

The most common ones I have seen are:

• Some type of estimation/betting table [The Sprint Planning]

• A team cycle of two weeks (I refuse to use sprint) [a maximum of one month, but static in size]

• Daily Stand Ups, what you did, what you will do, what is blocking. [No mention of that format in the guide]

• Some type of cycle closing/starting [sprint closing and sprint retrospective]

These solve specific issues, and might be worth keeping, or changing, or removing depending on your circumstances:

Estimations/betting table

These usually are there to avoid scope creep, we agree on what we are going to do for the next two weeks, that way we can say no to those other things that want doing.

They are a good starting point, it at least gets you to establish some priorities.

In my limited experience they tend to show their limits quite fast. Bugs want to be debugged, our estimations/guesses are incorrect, etc.

Two week cycles with a close/start

The idea here is that you at least will have things to show after two weeks. To be fair, it’s at least better than longer periods. But I do tend to see a mad dash at the end to fit to the schedule. And things don’t always fit a two week schedule.

At least it gets people talking twice a week, as they are usually accompanied of some sort of retrospective.

Daily Stand Ups

I mean, sure, they might make you talk to your team?

It’s better than nothing, I guess?

They tend to go to a state where they feel repetitive because they are a chore and most people wont read from other people.

[As described by the scrum guide, they feel somewhat more useful]

So, no Scrum?

I don’t have too much of a beef with Scrum per se. I think it is a fine starting point. For some teams it might get them closer to where they need to be.

But, it is often implemented rigidly, when you want to teach someone you teach practices, as it’s harder to teach principles. So, people learn the practices, and they stay, they loose meaning, they start impeding further progress.

Start with Scrum if you want, just don’t stay there. (Or start with XP, or with watever, as long as you keep adapting)

So, how can I do Agile then?

[While I ‘pick on’ Scrum here, my critique can be applied to any framework you treat as if it was ‘the final form'. Most frameworks exist to address issues that are more or less common, but the work your team does and the way they work is unique. Treat them as a starting point and adapt to your circumstances]

You can’t do agile. But you can be agile.

Agile is a lot of things, it's vague for a reason. But it's about having the right priorities and changing the way you work to address them.

Pick a starting point, see if it gets you closer to the goals stated above and change and tweak as needed to adapt to today's circumstances.

I found an AI/LLM plugin that finally works for me. For you? Your Mileage Might Vary.

The tool is Augment.

I've been trying out Code Assistants, and getting extremely frustrated by them. They basically worked as a better autocomplete, but all chat functions got real frustrating, real quick.

The promise I was sold was that it could help me co-create code. And for me that was not a better autocomplete that breaks your code if you give it some free reign.

And for me up to this point, that was the experience. Clunky, breaking, extremely over eager and fundamentally dumb.

The hard part is not writing the code. And if “the help” is breaking things and adding work for me… Pablo not happy.

But, is Augment fundamentally different? For me, yes, in one central way:

It can run the tests! Iteratively!

The amount of ways in which it can break things is not only severely reduced. More importantly, the amount of times I have to tell it ‘you are wrong, you useless thing’ is severely reduced.

Now, I am sure the folks building it have made things so that in general it's better.

But the true game changer is being able to run tests.

It unlocks for me a speed in doing things that I didn't have before, I am still in the driver's wheel. And when I actually let go too much… I instantly regret it. But, I have, finally, a somewhat competent assistant that can do the tasks that ‘annoy’ me most: writing trivial code.

Granted, you need a really tight leash, it will try to do too much, a coworker was surprised that I had to tell it to only change X file every time, until I forgot and he changed 5 files at once.

But, it works good enough that for now it is a good experience.

A last forewarning I will leave you with. What our elders described as great ways of working: XP, always green specs, test first, small increments, etc. Are doubly true with this assistant. The steps might be a bit bigger, in part because the machine is overeager, in part because it allows for bigger ‘jumps’. But the principles still apply.

Maybe it sounds a little harsh, but a programmer who's been working professionally for five years has likely already revealed their potential. What you're going to get is roughly what you see. That doesn't mean that people can't get better after that, but it means that the trajectory by which they improve has already been plotted.

The above quote and its corresponding article from DHH, has instilled in me quite a reaction.

I'll start with the most obvious:

knowledge work is not a sport

It is especially not a US sport.

I make the above distinction since:

1. US sport associations have some convoluted ways you might get to play in one of their teams

2. He uses US sport examples in the article.

I want to get in the NBA

I will use the NBA as an example, since it is the US sport association I know best, but they all have a similar ‘story’.

If you want to have a career in the NBA, there is quite a straight path you must take*:

• Be good in school, best of the best.

• Get selected for college, be good, best of the best.

• At some point during college declare yourself eligible for the draft (teams will pick as in the schoolyard, in turns**)

• Get chosen by a team, the ‘better’ you are the ‘worst’ the team that picks you is.

• Play about 15 years

• Retire.

*: you could also play ‘overseas’, Europe or Asia prior to being drafted.

**: teams are assigned an order of picks and will each pick a couple young players.

Why the teams select players young.

There are a few incentives on ‘fighting’ for young players in structures such as the NBA.

First and foremost, that is when you are sure you can get access to talent you would not have access otherwise (and keep in mind that the young players have no say in the team they’ll play for)

You get talent at a huge discount. Contrary to what is stated in the article, you don't pay a premium for ‘potential’, you get a potential discount for skills.

A players physical attributes will decline with age, with peaks being reached around 28-29 years of age. That is about 6-7 years after most enter the league.

The differences

I would expect that if you are working in a knowledge field, you can see the differences with a sport league, but please allow me to state the obvious:

Your career will be longer

You will not have ‘only’ a ~15 year career, more typically, your career will last for 40 years, if you ‘loose’ 5 years, you have not ‘lost’ comparatively as big a proportion.

You skills don’t decline as sharply

You don’t depend on your physical attributes for knowledge work, and while cognitive ability might decline some with age. The decline is not as sharp as with physical attributes

You have more time for circumstances to change

While now might not be a good time for you to ‘grow’ or ‘learn’. Life does change, and circumstances do as well.

So, how potential?

Potential (understood as ‘growing speed’) is derived from curiosity and opportunity. So, if you want people to grow with you, try to hire curious people and give them opportunity to learn. At the end of the day, you will be paying people for their skills today, and contrary to what happens in sport, they are not tied to you so if your compensation stops being fair for their skill… Well, either you’ll renegotiate or they will leave.

They were in favor of having randomness in their objects, their main argument being:

If we have random values, eventually we are bound to find the edge cases.

I was against, my main argument being a flavor of:

Tests should be deterministic

My inability to better explain why has prompted this post to produce a though out explanation as to why.

Trust

Randomness in setting the context of tests makes our tests untrustworthy, and:

Tests we cannot trust are a waste of time, brainpower and computation (in order of decreasing importance).

We waste time having to run them multiple times.

We waste time having to manually verify facts the tests should tell us.

We waste brainpower trying to figure out if a failing test is a genuine regression or if it is just flakyness introduced by the randomness.

We waste computation, although with a lesser importance in my eyes, we do waste computation if we introduce flakyness.

Hidden information

If we rely on randomness to catch our edge cases, we rob them of the visibility and place they deserve. The next person to come through our tests won't know what edge cases we have faced, and won't know if they are tested.

Unless we log the objects in our tests, chances are the failure message will be really critic

If we are reaching for an object from a factory, we now have to know or lookup what values might vary.

Tests should be deterministic

In closing, I guess my 'one Line argument' remains the same:

Tests should be deterministic

But I sincerely hope someone will be convinced by the expanded arguments above.

Some subjects are inherently better to learn

Me - to a group of friends

Allow me to explain what might seem like a hot take:

2 things make a subject 'inherently' better, one is deeply personal, the other is a matter of applicability :

Deeply personal

If the subject matter holds no interest to you, be it for personal or professional reasons, that subject matter is inherently worse (for you)

A matter of applicability

I like to see subjects (I mostly read, but I believe it applies to subjects, not books) as having a "wideness" of applicability.

Very narrow

Very narrow subjects (think "Eloquent JavaScript" or "Practical Go Lessons") have a very narrow applicability, close to 100% of what you'll learn will apply only in situations where you use that language.

It's ok to investigate a bit to hone your skills, but won't be very transferable. They deal in very "short term" tactics.

Averagely narrow

If we expand the scope a bit and go for wider books, we have subjects that deal with a "universal topic", think subjects you could learn in a language you don't master, things like: TDD, Encapsulation, Refactoring, Patterns, Algorithms

These subjects still deal mostly with "tactics", but their scope is a bit expanded, the tactics are more long term, some get close to being strategic. You start to be able to use these lessons in almost any language.

Wide

Then you have more "holistic" subjects, in books I think of: "Pragmatic Programmer", "The software craftsman", "Modern Software Engineering", any book about Architecture, DDD

These will give you very transferable knowledge.

Situational

To finish the list, you have more situational books (think eXtreme Programming) where the knowledge is highly transferable technologically, but very team-context dependent.

What type of topic should I go for?

I believe the inherent worth of each of them might change over time and situation, but I believe that the marginal-gain curve flattens out faster the "narrower" the subject is. The 100th hour learning Ruby has less beneficial impact than the 100th hour learning testing strategies for example

I discussed my idea with some of my new colleagues and got some buy-in and time to execute the refactor.

I took about a week tinkering and delivered my PR, all the tests passed, and all seems okay.

And still, I have a nagging feeling of dissatisfaction with the work I produced. It works, I believe, fine enough and the solution is, if I might self-congratulate, elegant enough.

So, why do I have this feeling of dissatisfaction?

Please embark with me, dear reader, on a small introspective journey while I try to make sense of these feelings. With some luck, we will all learn something from the exercise (at the very least I hope I will).

The unease begins.

When reflecting on what created my nascent unease with my work, I believe I can pinpoint it to two things. One of them concrete, one of them more intangible.

On the concrete side of things, is the file changes count and the lines +-. I changed about 45 files and added ~2000 to remove ~200 lines.

This is A LOT, and made me pause when I realized it.

It also, I believe, contributes to the intangible part, explaining and self-reviewing my changes in writing felt very hard, not so much on a conceptual level, as on the sheer amount of changes.

Red flags(?)

Okay, so those things made me feel awkward, but are they red flags?

On a vacuum, yes, certainly.

But are the changes I made justified or am I justifying them to myself due to the sunk cost fallacy?

Goals accomplished (?)

I think, to make sense of all of this I need to separate the actual PR (and what I think the goals of a PR should be) from the refactor (and what I think the goals of a refactor should be)

Goals of a PR

In my opinion, a PR should accomplish the following goals:

• Be cohesive (success)

• Be easy to review (failure)

• Have a small diff (failure)

1 out of 3, and in my opinion not the most important success, so here I clearly failed (I'll reflect below on what I could have done differently)

Goals of a refactor:

• Make future changes easier (success)

• Make the code easier to parse (success)

In this, I feel like I succeeded, I believe the code is easier to parse and easier to change later.

Where did I go wrong?

I started the refactoring by presenting an idea to the team, which is not a bad thing in and of itself, but I believe I fleshed out the idea too much.

It also prompted me to start the refactoring by my 'wanted' result rather than step by step.

This had two consequences:

• My thinking was less flexible

• I branched out the oath by inserting my 'final' class and broke the tests for a week.

What I should have done differently

Giving a high-level idea of the changes is fine, but I fleshed it out too much.

More importantly, I should have done the refactoring step by step and starting from the existing code, making sure the relevant specs pass all the way.

This would have provided me with natural stopping points where I could have submitted several PRs instead of the monstrosity I submitted.

I will strive to explain here:

• What is a value object

• How to make a pure value object and use it in rails

• How to transform ActiveRecord objects into almost value objects

• Why and when could you use value objects

What is a value object

I deliberately choose not to look up a definition (in part so you, dear reader, can tell me how wrong I am) and provide the definition I have in my head.

A value object is an object that does not need nor have an identity, that can be substituted by another instance of the same object with the same attributes and that is immutable (as changing it would make it by definition another object)

So if we imagine a Money class, that implements a #value and a #currency attributes. Any <Money value=5 currency=€> Can be substituted by another instance of Money that has the same value and currency (after all, when you get a 5€ not, you do not care about the serial number).

This can be opposed to an Account object, that has #balance and #currency methods, in this case, substituting an account for another might mean allowing someone to withdraw money that isn't theirs.

How to make 'pure' value objects and use them in Rails

At its simplest, a value object is just a class with an overridden == method (well and ===). You could just do:

class Money
    attr_reader :amount, currency

    def initialize(amount:, currency:)
        @amount = amount
        @currency = currency
    end

    def ==(other)
        amount == other.amount &&
            currency == other.currency
    end
end

This is a value object in and off itself, but how do you plug it into your ActiveRecord object?

Taking advantage of the composed_of macro:

class Accoun < ActiveRecord 
    [...]    
    composed_of :money, mapping: { balance: :amount, currency: :currency }
end

How to transform ActiveRecord objects into almost value objects

Sometimes, we need our ActiveRecord objects to behave with certain characteristics of value objects, in this case, I will show you how to make an active record (almost) immutable:

class CarModel
    [...]    

    def read_only?    
    !persisted?   
    end
end

You could go further and also overwrite the == method if you wanted.

Why and when could you use value objects

All of this is well and good, but I gather part of the reason you are here, cherished reader, is to know when and why you would use value objects.

When

As stated previously, one of the key reasons to use value objects is when you only care about the characteristics.

You might also find yourself, attentive reader, with 'prefixed attributes'. A classic example of this might be address

For example, a Person had several related attributes like: address_street, address_number, etc

You can group all of these in an address object and enrich them with methods such as #full_addressand store all of those in a jsonb address column.

Finally, it helps you break god objects into more cohesive and reusable units

Why

It is safer as having these objects being immutable means they won't change in the course of your code, which is one less variable to take into account.

You can unit test these objects with more ease than a typical ActiveRecord object.

Finally, it allows you to give them larger behavior than you could if you represented the values 'only' with a primitive.

My sense of BDD after this book:

You get 'mostly' feature coverage, but as a byproduct, although it is a byproduct not of organizing the system but of exploring and defining the high-level functionality of your application.

It has several strategies to explain how to not get bogged down in infinitely running tests as well as how it evolved from TDD.

All in all, it seems BDD requires a bigger organisational 'buy-in' than TDD (and has also bigger promises). In the sense that I can TDD without anyone's but in, and maybe convince 'by example', but in the end it does not really matter that all the team TDD's. Whereas for BDD to be useful as described in the book, the whole 'team' (in it's widest sense, including even users) needs to buy in.

It's promises are quite interesting though, and present a cycle of red-green-refactor made up of a lot of red green refactors.

I think when I 'naively' tried it in the past, my main mistake was assuming that the cucumber scenarios should not be done by the tech team (in close collaboration with the stakeholders)

The promises of being able to better discover features and edge cases via examples while making collaboration with 'business' easier is quite appealing

After reading the book, if I am ever in position to try BDD again I would like to give it another go

This being a quick and dirty job, I did not write any tests (because I am my own worst enemy). After all, there are literally four screens and three use cases to test. Realistically I could test the three use cases in under two minutes.

My friend asked me for a small change, this being basically a greenfield project, it took literally 20 minutes to implement.

So, all good, I test the screen that I think is affected, go to the home screen just in case, all is good.

Great! I made a friend happy for basically no effort, world is wonderful!

Deploy....

2 minutes later I get a message "hey Pablo, do you know the search is broken?"

"Ah right! This partial is used here!"

If only I coule have done something to prevent forgetting to test something...

You know, something that is actually low effort and would not only save me 2 mins each change, but most importantly would no have allowed me to deploy something broken in an obvious way!

Dear reader, if you know something that would have helped here, please let me know!