I have thoughts about LLM coding, and they might be slightly different than other people, so buckle your seat belts dear readers and let's wade through some slop together.

LLMs as a general tool

LLMs are a chatbot, they do chatbot things, and when using them you must remember that they strip away most of the intention of whatever you wrote.

Even though most people try to convince me that the written discourse on the internet in general (and LinkedIn in particular) was already truly uniform, I am quite certain that:

• It was not.

• You did not use to get dumber reading it.

And writing text is supposed to be the thing they excel at!

Seeing the subpar text they produce should make anyone wary of using them for any serious purpose.

A few newsletters I read quite avidly in the past have become intolerable as an LLM takes a sentence that might be interesting and turns it into five paragraphs.

While it might not be yet capable of turning a blog post into a book (we were quite good at that before), it certainly can turn a sentence into a (bad) blog post.

And all that with all the convenience that fast food has. It's fast, it's 'repeatable' and in a world where volume already spoke louder than quality, it is drowning any original thought that might have emerged before.

But it is impressive, and it plays very well to our laziness. I have a podcast, and I don't like marketing, of course I have been tempted more than once to tell the LLM to write some copy for me.

Abstracting cost from output

One thing I must give kudos for is that the abstraction between the cost and the output is marvelously achieved.

In it's more utilitarian view, we don't know (and don't think about) how many tokens are in our subscription, not how much money a token costs, nor what a token is, not how much energy a given token might consume. We don't even know how many tokens any given request will consume.

The above makes it so we don't know if there is a viable business on top of LLMs as a general tool. It might be worth producing an ungodly amount of slop at 200 a month, but there is a number where that is not true. And we don't know what the final price will be.

We don't know either what the energy consumption of all of this "work" is other than "high". I believe in part it is due to it being a complicated subject, and in part that fear is a good marketing tool, for example saying we might have blackouts due to LLMs or that we will have to open a nuclear power plant to power a data center sells.

But there is a more insidious cost being abstracted away, and that is attention, and while attention might be all you need, attention is being destroyed.

First and foremost is the fact that as soon as it becomes apparent that something was spewed out by the machine, my eyes (and I suspect yours) immediately gloss over the rest of the content.

Not less important, by clicking the metaphorical "make longer" button, your idea gets diluted into "it's not this, it's that" and other weird sentence constructions.

Finally, you are probably not paying attention to your "writing" anymore, after all the computers never lie, or never used to lie, and you told it to turn your idea into long form writing "using your voice". How can you be sure your voice is not eerily close to everyone else's voice?

They can't write, can they do something else?

Although the hype machine wants to convince us and sell us today on what LLMs might be able to do in the future, I do believe there are some things it does reasonably well today, at today's subsidized price.

One of the things it does reasonably well is the opposite of 'make this longer'. It is capable of ingesting a fairly large amount of information, in a reasonable time and give you a watered down but mostly sufficient summary. As long as precision is not something you need from it.

You do need to be aware that it had been trained mostly on internet text, so it "wants to give you" actionable advice, and strategy. And it is easy to be fooled into thinking it can think and actually provide advice and analysis.

It also can code, mostly...

But I can code faster now!

Congratulations, after 750 words you finally are at the part that reveals my hypocrisy and that probably interests you more.

I have not opened my IDE to type code in a while. And I think I am mostly faster, but there is a lot to unpack here.

I can give a prompt to the LLM and it builds an app for me

No you can't. If you are not a software engineer, and don't understand the code it is producing you might be able to fight it until it builds something really simple thst mostly works. But you are most probably building a website, that website is pretty simple and you were overestimating the complexity of what you wanted to build.

That is not to say that it is not useful, and it might allow you to create some bespoke webapps for really niche problems, but you can't vibe code your way to solving a problem at scale. Since I can't prove a negative, let's say that with the miriad of people vibe coding the next unicorn, one would expect at least one or two to get some traction.

But my whole organization can now create a PR from a slack message, we are all 10x engineers!

No you are not. But thanks for telling me, I'll make sure to avoid your software for a while.

In the worst of cases, you are creating an intolerable amount of bugs and pushing unreviewed and unintentional code out into the wild.

In the best of cases, the people that know best how to structure and tend to your code are now stuck babysitting a codebase getting filled with half baked ideas.

Code is quite meaningless, but I will presume you have some sort of software you are trying to sell. The functionalities you do not build into it are as important as the functionalities you do build into it. Every piece of functionality you write is a desire path that you are paving other, and if you don't put intention and attention into it, you will end up paving the whole field, getting your users lost in what they try to accomplish and trying to plug holes in a surface area that is untenable.

But it gave me code and now I can scrape recipes of the internet and repurpose them for SEO farming

Yes, I am quite sure it did. But if you have followed along... At what cost? And for what?

But I am a software engineer, and I don't use my IDE anymore! And I am faster?

I am in the same case than you, and I do think you can be significantly faster when assisted by an LLM for coding, but I have feelings again. The rant continues!

Faster?

Faster is really hard to pin down, I know it might seem disingenuous but what do you mean by faster?

1. Do you produce more code by volume?

2. Do you have a shorter cycle time?

3. Are you creating more PRs?

4. Do you deploy more frequently?

5. Are you adding more functionality more frequently?

6. Are you adding functionality that you could not before?

7. Are you seeing a smaller volume of bugs in production?

All of these are ways to measure "faster" and I would contend that some of them are more interesting than others. Especially Volume and PRs seem to be quite worthless to me.

If I submit myself to that questionnaire today, I would answer:

1. Do you produce more code by volume?

   1. Yes

2. Do you have a shorter cycle time?

   1. Yes

3. Are you creating more PRs?

   1. I was, I stopped

4. Do you deploy more frequently?

   1. Yes

5. Are you adding more functionality more frequently?

   1. Somewhat

6. Are you adding functionality that you could not before?

   1. Yes, at least considering things that where not realistic before

7. Are you seeing a smaller volume of bugs in production?

   1. Mostly yes

So I do think I am faster now, but I would not say I am twice as fast as before. There are also some systemic issues that must be tackled in order to be faster.

Asynchronous Code Review, for the despair of many, are a default in our industry, and while we can create a higher volume of code and PRs, we are transferring a bottleneck downstream. And it is a bottleneck that creates a lot of problems, from context switching, to conflicts creeping in the different branches.

You will do too much

If you decided to start doing your engineering from a CLI instead of an IDE, I believe you will have gone through this phase.

Hey! I want to add the possibility to link slack and my app to notify people of changes

Chatbot creates a worktree and churns along...

Hey! I also want to be able to login by taking a picture of my face

Chatbot creates another worktree (some times in the correct place) and churns along...

Hey! Actually I also want to add fingerprints so people can login when they pick up their phone

Chatbot happily tells you yes, creates a worktree and churns along...

Of course all of this goes in parallel and your nervous system is fried and overworked so you are saying yes to everything without even looking. But you do remember to tell it to review itself from time to time

A few hours or days after you have several PRs, probably massive, they read like rants written in code and you need to review them all.

It took me a month to recover from that and actually manage to merge the PRs (at least those I did not discard). I hope this does not sound familiar, but I am quite certain it will.

Reining it in

So, we have to do less, it is not tenable to have 5 projects in parallel. It is a lesson apparently I (and I suspect you) needed to learn again. I am still faster, granted, but now I only swim in one lane instead of trying to encompass the whole pool at once.

I also have realized that we need to contain the Rants it produces in code. We need to constrain it so that it does not spew forth a whole app every time you tipe something in your IDE.

Paul's dotfiles are a great starting point when you want to rein it in, they do shorten cycle time* (*If you are doing TBD), I am still faster, and I pay more attention.

I do feel like I have to babysit the LLM in very predictable ways.

Feedback loops or lack thereoff

One of the reasons I believe LLMs are performing adequately for software engineering is that (most) of the industry has accepted the need for short-ish feedback loops, from Tests (ideally first) to static checkers, going through CI.

And that harnesses and helps the LLM iterate. But some of them are 'hard feedback' and some of them are judgement calls.

LLMs are really good at following hard feedback, they will churn along (most times) until the test goes green, or the static checks pass.

They are really bad at making what I am calling judgement calls though.

A symptom of that is their constant refusal of doing the Refactor part or Red - Green - Refactor. And I believe it is because they don't have a hard gate. Refactoring or not is a judgement call, and so is loading skills dynamically.

As such, you will have to constantly babysit the LLM to do those tasks, and absolutely cannot trust that it will do them. No matter how many times you have written that it should!

In the same vein, you cannot believe it when it says it has reviewed it's output, it does not have the capacity to think critically, and reviews are judgement calls.

Finally, the LLM can give you a mostly correct assessment of a situation, but it will again, and again make a 'recommendation'. And that biases your thinking. LLMs are not fit to make recomendations and when having them sumarize the situation of a part of a codebase or a work in progress, you must remember to be at the drivers wheel.

For very long we have been trained to 'click' yes when prompted, your default position when using an LLM assistant should be 'no' and think through why it should be yes. This is made harder by the fact that it is not trivial to distinguish when the LLM is in need of a decision (e.g. should this function be split in two) or is just not able to perform a decisionless task without explicit agreement from you (e.g. running the tests)

If we disregard (and it is a big disregard) the economics of LLMs, for them to work as well as they should we need to create as many hard gates around them as we can, they are relentless at making something go from red to green, and I do not believe we can base ourselves solely on the tests for that part.

But in the meantime,..

Old is new again

There are practices that help in creating smaller chunks of work and in keeping feedback loops short, hard and manageable.

It seems a lot of people are rediscovering them and renaming them (with the age old fight of Agile vs Waterfall getting a new battlefield). But we have known them for quite a while.

• Strive to have tests for the LLM to but its head against (and review those thoroughly if the LLM writes them).

• Test behavior rather than implementation.

• Have every 'unit' of code do one job and one job only.

• Reduce conascence throughout your app

• Do not rely on asynchronous code reviews

• Work in small chunks that go from green to green and can be deployed independently

Most of these principles and practices have been extensively written about. Notably I would recommend you read at the very least

• TDD by example (Kent Beck)

• The original article on Software teaming by Woody Zuil

• eXtreme Programming (Kent Beck)

• Refactoring (Kent Beck and Martin Fowler)

• Conascence

And watch:

• TDD where it all went wrong by Ian Cooper.

They feel good, they are fun to imagine, they make us feel very smart.

They give us a sense of beginning and a sense of ending.

They make us think that we are future proof and that, since we found the good solution we won't need to change anything.

But:

They delay the moment where we add value to our software.

They force us into a path where we have zero to no value until the whole plan is executed.

The highest value is added at the end of the line, if not, we could forego most of the plan.

The solution, and our code will tend to be more brittle.

We will still have to change it once people start using it.

So:

Don't pick an exact destination and break it down into small chunks.

Pick a problem, ask yourself how you could solve it in a day.

There might be another problem later, do the same.

Add value fast.

Software teaming commonly refers to the practice of having a full multifunctional team work on one feature at a time on the same machine. It is also known as Ensemble Programming or Mob Programming.

Why do it? - Motivation from a team lead perspective

In order to understand why I pushed my team to experiment and try Software Teaming, I think it would be useful to understand the challenges we are facing when working asynchronously from my perspective.

Our team is composed of 5 people separated in 2 Front End Engineers and 3 Back End Engineers. A typical feature will include a Front End Ticket and a Back End Ticket.

This leads to a state where:

• Rework can and does happen frequently.

• There is a layer of coordination that needs to be added between the Front End and Back End Engineers.

• Switching costs are high.

• The waiting time for each feature is high.

Having the team perform as a team instead of a collection of individuals solves most of this issues, but also presents with an opportunity for other benefits, namely:

• A reduction of the bus factor.

• A potential to have everyone expand their knowledge of the whole stack.

• A higher overall level of care on our code.

• A more rounded perspective of our solutions.

Challenges you might face if you decide to try

While I paint what I hope is a pretty appealing picture above, if you want to try Software Teaming withing your organization, you should be aware of the challenges you might face.

First and foremost, it is a hard sell. You will be optimizing for throughput rather than output, and it goes against the traditional way of measuring performance.

It goes against an ingrained perception of the developer as the ‘sole genius' of a development. Individual progress might feel slower, as no member is fully responsable of the code, but the team is.

It can be more tiring to work as part of a group, as you don't fully control the rythm, and the level of social interaction is higher.

Finally, there might be a feeling of loss of control and loss of agency. As, while working in a group you will, most times, influence rather than decide. For the same reason, you'll have to be mindful of everyone being able to influence the group.

In Practice

The theory is all well and good, but what did it mean in practice?

Our setup

We, the five engineers worked as a tem for three days a week for three weeks. We did so in person, as we tried to do one day in remote but our remote setup made it harder.

We had one screen, one keyboard and one computer for the team on the ‘teaming’ days, and we roughly did turns of 20 minutes each as typists.

The ‘mandatory’ teaming hours were from 10 to 12 and from 14 to 16, but in practice we did whole days of mobbing.

Pain points

Our setup was not ideal, as we used a team members computer and screen, as such they were locked in the mob wether they ‘felt like it' or not.

The skill separation between Front End Engineers and Back End Engineers made some parts a bit painful when a lot of the focus was only on the backend or only on the frontend.

There was a sentiment of isolation from the rest of the company, and ‘secondary’ things were harder to keep track of.

There was a sentiment of ‘not being the most conductive setup to learning'.

Gains

The feature was in constant progress, even when not the whole team was there, wether due to emergencies or illness.

There was no waiting time, the code review was done on the spot, and we deployed (but did not release) at least daily.

We were able to change the shape of our API and make judgement calls on the spot, which allowed us to keep progressing the feature.

There was a noticeable improvement in the skills of the participants, the first days we would have to dictate the Backend to FE engineers and viceversa, later days we could express ideas as the team and have the typist mostly execute them.

We were stuck at several points, and having a wider range of skills allowed us to tackle the issues in a more effective way. Although, I must note, that a shared frustration at being stuck is not easier to bear than an isolated frustration at being stuck.

We all know the tradeoffs and choices that were made, as well as how and why our code works the way it works.

Tweaks I would make

I think that while the team being multifunctional has its interest, this exercise necessitates that people have a fair knowledge of the whole stack. While I think that time can solve the issue, it is none the less a hurdle you will have in segregated FE and BE teams.

The setup, can make or break you, if you decide to give it a go, you should pretty soon have a dedicated computer, keyboard and screen (a big one) to allow members to leave the group when they need to do individual work.

Will we do it again?

Tl:dr: maybe.

After three weeks of working mostly as a mob, we have decided that the challenges were a bit too big for the team.

We did take some lessons from this new try and might try again in the future.

As an individual, in a vacuum, I am now convinced that this is the most effective way of producing software. But it necessitates a high buy in and conviction from management and the software team.

Yes, another sport analogy… but one I believe is fitting.

What does it even mean?

I heard of this concept as related to basketball initially.

A floor raiser is a player (or concept) that raises the lower level you operate at.

On the contrary, a ceiling raisers will raise the highest level you can operate at.

In a software development team, I think of these concepts as:

Floor raising => We are better within our ‘possibility space'

Ceiling raising => We expand the horizon of our ‘possibility space’

How does it relate to software?

While the decisions are, at it's simplest, much more intuitive in basketball, I believe a good software team is first and foremost a team.

And as such, other than the obvious ‘you are as strong as your weakest link'. There are practices you can adopt to raise your team’s floor (and a couple of hints on raising its ceiling).

And I will focus more on the floor, because contrary to basketball, ‘peaks’ matter less than ‘valleys’ in software development.

In the long term, the productivity of a software team will be determined by its valleys.

Raising the floor

So, what can you do to raise the floor? And how can we measure the floor of a software team?

The floor

The baseline measure I will consider for a piece of software is:

• Ease of change,

• amount of defects,

• the software works as expected

In the scope of a team:

• Deploys per period,

• defects per deploy

• time to fix defects

Apart from the practices described below, hiring a senior or raising the seniority of your team will raise the floor of your team.

Practices

Test Driven Development

This is I believe one of the biggest floor raisers, and one of the easy pickings.

Code designed with Test Driven Development, is easier to change, produces less defects and can be deployed continuously.

Short lived branches

By reducing the overhead of reviews, and the size of code reviews, you again, by design raise the floor of the team. Trunk Based Development, while needing of quite a few preexisting conditions, is even more effective at that.

Ensemble/Pair Programming

By reducing the feedback loop: the review happens ‘as you code'. And, helping maintain a higher base level of care. Coding in group helps elevate the floor of a team.

Thin vertical slicing

By creating thin vertical slices for your projects/features, you lower the risk of any one slice, you facilitate the review process and shorten the feedback loop.

Retrospectives

By having frequent retrospectives (the 6 thinking hats framework worked quite well on our team) you open the door of adapting your way of work. This will allow you to progressively raise the floor of your team.

Raising the ceiling

The ceiling

The ceiling is derived from the capabilities your team has. What domains they can work on and for what types of technological problems they can intervene effectively.

How to raise it

If the technological or domain proficiency of certain members of your team grow, the ceiling will move up.

There are two obvious ways to achieve that:

• Hiring a specialist,

• forming members of your team in new technologies or specialist subjects.

Conclusion

At its limit, the productivity of a software development team is determined by its ‘floor’ so when thinking which practices to introduce to your team, think which would be the most effective floor raiser.

The floor is also, the limit where you can have more impact in the long run. Although you can have bursts of impact on the ceiling.

We have been doing a retrospective every two weeks at Recovr, and this is what is working great for us:

Structured and Timed

We are using a variant of the 6 thinking hats.

We spend 2 minutes on facts and figures, 4 minutes on positive thinking, 4 minutes on critical thinking and 4 minutes on solution thinking. We then leave ourselves some time to decide on at most 1 adjustment to make until the next retrospective.

We have a time keeper and a person writing everyone's points on a whiteboard.

This is how a typical retro might look in the end:

Thanks to that structure, our retrospectives are usually between 30 and 45 minutes long.

One adjustment in isolation

The idea is not to change the whole way we work at every retrospective, but rather to make at most one adjustment per retrospective.

For example we realized we had too many items ongoing, so we added a rule that anyone could only have a maximum of three items in review or in progress.

We also decided to try our hand at Ensemble Programming after a retrospective.

No listing of what was done

We do not go through each item of the period, what was done and not done. We found that it rarely leads to insights, and the few insights are not really actionable.

As such we speak about the period as a whole.

Don't debate what goes to the board

If a person of the team feels something is worth saying, it goes to the board without discussion, there can be an explanation, but doubt is not cast on it.

The place to debate the different things is when we look for the adjustment that should be made for the next period.

This allows us to not get bogged down in the particulars and react to the more general patterns emerging.

High buy in

The structure, and the fact that in the end an adjustment is decided as a group, provoques a high buy in from the whole team in the adjustment to be made for the next period.

Conclusion

Try your hand at doing frequent retrospectives today, keep them structured, keep them short and have he discipline to only make one adjustment.

Bit by bit it will improve how you work, and will find what works for your team at each moment in time.

Our latest experiment has been 3 days of Ensemble Programming. And I loved it, so let me tell you what ensemble programming was for us, what worked well and where we could still tweak it.

Ensemble for us

From what I gathered talking to people around me, Ensemble programming means different things to different people. So here are the rules we had for our first ensemble day and how the rules ended up for the last day (three days later).

First Day

On the first day, we heavily influenced ourselves by the book Code With the Wisdom of the Crowd.

Roles: We decided that there would be two roles: the Typist and the Rest of the ensemble. The Typist's responsibility is to transcribe the ensemble's intentions.

Timings: We started with every typist being at the keyboard for 15 minutes

Retrospectives: We decided to have regular retrospectives throughout the three days; these informed the changes we reached for the other days

Second day

After a retrospective on day two, we discovered what seemed most problematic on day one: We got off topic and lost half a day chasing our tails.

As a consequence, we decided to add another 'rule' which was:

Structure: We can only advance following a to-do. If we run out of to-do items or we need to deviate, a new to-do must be created

This allowed us to advance with more purpose on our second day.

Third and final day

On our last retrospective, we realized that the timings for the typist were too short, and the switching machines cost too high in proportion.

To fix that, we decided to increase the timings for the typist from 15 to 25 minutes. Here is how the rules looked in the end:

Roles: Typist and Rest of the ensemble. The Typist's responsibility is to transcribe the intentions of the ensemble.

Timings: 25 minutes on the keyboard for each of us. If we must discuss something for a long time, the timer is paused.

Retrospectives: regular retrospectives

Structure: A to-do must always be up-to-date and active to advance.

What worked for us (in my opinion)

Retrospectives

Within the three days we had three retrospectives, one at the first half day, and in the morning of each of the other two.

This was the most impactful thing we did, it allowed us to have each day improve on what we had built the previous day.

Breaks

We forced ourselves to take breaks quite regularly, especially after we finished the first day knackered. This allowed us to be fresher and more efficient during the working parts.

Level of care

I found that the level of care and attention to detail was higher as a group than as 5 distinct individuals.

I attribute this to the fact that as a group, someone's care was always high, even when it decayed on someone else.

I believe the end result of what we were coding was something we can be prouder that if it was coded individually.

Learning

We are organized as a team with a distinct front and back end. In order for this to work, we decided to have the front and back work together.

This meant that we not only were learning how to work as a group, we were all also all learning a new language.

Everyone had quite an open mind to it, and recalling our first rotations and our last ones, the instructions went from dictating the specific syntax to more general we should do X.

Flow and coordination

One area where we definitely gained a lot of time and quality, was in the coordination among the front and back (and more generally the team).

If we wanted a shape to our API, it was decided on the spot by everyone, so we did not have to revisit things due to misunderstandings.

The same can be said about the architecture of our code.

Code and architecture quality

Since we were deciding things by committee, there were less sunk cost galàxies that come into play when a review is done after the fact.

What could still be improved (in my opinion)

Switching costs

Most of us preferred to work on our machines, and while it has advantages, mainly everyone working in a familiar environment, it does mean that there is an inherent cost of switching the machines and pushing/pulling the code.

We did find ways to make that s bit faster with each switch, but progress could still be made in that front.

Cost of the experiment

While I am convinced now that doing ensemble work regularly would be a net positive, this first experiment did have costs.

The big elephant in the room is that we spent 15 programmer-days for this experiment. At the end of the three days we did a budgeted work of ~8 programmer days. I believe the advantages in reduced coordination costs are well worth it. And with more ensemble experience, I believe the two numbers will get closer to each other.(Edit: after the fact I realized that it is quite common for us to miss our mark when estimating and being of by 50% so the amount of work produced was roughly on par)

The two other minor costs we incurred were:

On one hand, we ended the days quite tired (although less with each passing day).

On the other, since we were working in an unfamiliar way we were not as efficient as we could have been.

I am quite sure that the cost will lessen as we keep doing ensemble programming.

Getting stuck

I had the impression that we got stuck on minutiae a couple of times, especially when two of us felt quite strongly about one thing or the other.

I suppose there are a few ways to fix that, first that comes to mind is after X time, pick one direction and test it.

I look forward to see how this evolved in the future.

Conclusion

I believe the experiment was a net positive, not only is the code quality higher, I think that the 'time' we lost due to inexperience will be offset by the reduced coordination and review costs.

The team seemed quite enthusiastic about the experiment and we are working on integrating ensemble programming into the way we work.

If you, dear reader, have never tried it, I can only recommend you do, remember to adjust along the way and to keep an open mind.

Knowing this and thinking about them will allow to grow your knowledge and practices in a more comfortable manner

In this article I would like to examine and exemplify them separately in order to better understand their consequences.

The dependencies of Knowledge

Learning has dependencies, there is no point in trying to teach advanced algorithms to someone who has not a clue about recursion or that does not understand control flow.

And if you try to do so, you will quickly discover that you will have to take the time to teach those concepts.

This applies to most knowledge we need as engineers, and learning or teaching them in the "correct" order matters.

Another example that comes to mind is languages and frameworks. You can learn JavaScript by learning React, but your knowledge of both React and JavaScript will suffer from it. (Substitute JavaScript and React with CSS and Tailwind, Ruby and Rails, etc).

This affects both individuals and teams:

• Individuals because they should be conscious of it when learning, to see that if something is "too difficult" it might be because they are trying to learn it out of order.

• Teams because if you want to upskill a team, you need everyone to get on the same 'stem' of the tree of knowledge or be prepared to tailor the growth of each individual.

The dependencies of Practices

As with knowledge, Practices have dependencies. The clearer example of that is CI(Continuous Integration)/TBD(Trunk Based Development). In order to apply it, you must, as a minimum:

• Have good test practices

• Pair/mob regularly

• Be comfortable with separating integration from release

A similar story goes for test practices, let's take TDD(Test Driven Development) for example. In order to acquire that practice, you must already:

• Be comfortable with the practice of testing.

These dependencies are somewhat overlooked by proponents of the 'more advanced' practices and that can be problematic.

This has the same consequences both for individuals and teams:

Individuals and teams should understand the dependencies in the practices they wish to embrace in order to adopt their prerequisites.

A small out of bounds note on practices

The dependencies in practices also reveal themselves in the fact that some practices are anathema to others. I won't delve deep into this subject, but let me exemplify it by saying that you will struggle making git flow and TBD work at the same time.

Conclusion

• Know the dependencies that exist in what you want to learn or do.

• Go about reaching the destination in order of dependencies.

• Validate that as a team or individual you have satisfied the dependencies before moving to higher subjects

"Not really, I am in the middle of a project. I can take a look next week when I am done" responded Anna.

"Come on Anna, please it's just changing text, how long do you think it'll take?"

"Ok, Travis you are right, it's 5 minutes I'll let you know when it's live"

If you have ever been a developer at a small or medium company, you have been in Anna's shoes. What is more, you can probably spot at least a couple of issues with this interaction.

Just in case, let me list a couple here:

• Anna has been interrupted by something without context and in a setting where she is not inclined to ask any

• If Travis asks this, what is stopping Eva or Bob from asking for similar things

• Once Anna has opened that door, it's complicated to say no to the next ones

• A lot of small quick fixes might get done, but the (hopefully) important longer projects get delayed ad nauseam

I believe in this article I can introduce to you a way to solve this, with the bonus of aiding to assign responsibility to those 'shadow' tasks that need doing but are no one's task.

The idea

Deliberately assign some team time (grouped or individually) where high-priority, small tasks are handled.

Some examples (but to each their own) of tasks that might qualify:

• Low impact bugs

• Wording changes

• Feature tweaks

The history

Sadly I must admit that the origin of this iteration of our (non)-revolutionary idea is lost to the fog of time. But I do know that when I got introduced to it, it had been copied from someone else. In the following sections, I will walk you through how I was introduced to the idea as well as how it morphed over several iterations.

Once a week we all dance for the king

I was introduced to this idea when working in Paris at Study Advisor.

Every Monday, the tech team would spend the day as the 'fous du roy' (King's jesters) and would handle the little tasks and bugs of the week. Well, to be honest... The tasks kept accumulating, but at least the most urgent ones were being handled.

Sadly, this presented some problems:

• Small fixes could turn out to need more than one day to fix.

• Every week the tech team would spend at least one day 'not advancing' on their projects (that is 20% of the time)

• It was taking a toll on the tech team members to 'drop' everything once a week and work on something else.

• Other teams within the company might still wait a week or more to have their needs met.

The next iteration of this idea fixed the identified problems

This court needs a rotating jester

The solution we found to those problems was to have a rotating jester, so one member of the tech team would be the jester for the week (yes, the whole week). A board would centralize the requests from the other teams and the bugs with a perceived 'importance' for the team and the jester would be responsible for prioritizing and fixing or implementing the small things.

The idea behind this was that at the limit, the tasks would not represent a week's work, so the jester would be able to advance on their assigned feature as well during the week.

Higher impact bugs got added to the purview of the jester, as they would be the ones shouldering the weight of the interruptions on behalf of the team.

While this iteration solved the previously mentioned problems, it uncovered a rather big one, what happens when there are too many high-impact bugs or the jester is not the best person to handle an issue.

A jester is not enough, let's call Spoc(k)

The next iteration of this idea was slow to come, I had left the team at Study Advisor, and at the company I joined (Yago) there seemed to be less of a need for such a figure.

Little did we know that one day one of us would take a vacation and it would coincide with a rather nasty (but seemingly) low-impact bug.

At that time we discovered that our teammate was not only handling his fair share of work, but on top of it, he was handling all the little bugs and modifications.

In our discussion as a team, I brought forth my experiences as a king's jester and we proceeded to implement the next iteration of the idea, but this time we would be Knight's, more exactly Single Point Of Contact Knights (because backronyms rock 🖖).

The Spock would have the same responsibilities as the jester previously had, but we added the fact that their responsibility was 'making sure things got done' rather than necessarily doing it themselves.

The Spock would primarily work as a single point of contact for bugs and requests, and although primarily they would be the ones solving the issues, they could call on other team members if they needed help or if someone else was better suited for the task.

And here concludes (for now) our story of kings, jesters, and Spock 🖖

Summary of benefits

• Low visibility or ad-hoc tasks are no longer anyone's problem

• 'Business' is more satisfied with the tech team as the team is less of a blocker for 'easy' changes

• The bigger the team, the less proportional time is devoted to low-impact tasks

• Making it rotational (I recommend weekly) makes it take less of a mental toll on the team

Potential fallbacks

• If every small task is 'of the utmost importance' prioritization might be a problem

• If a hand-off is not put in place between Spocks, some small tasks might be done twice or lost in the transition.