Why feed pizza to developers at meetups?

TLDR: If you've ever eaten free food at a meetup (even though you could have afforded a meal), why not help out those who are not as fortunate? "Free" food at developer events is about practicality not being a reason to attend.

Mmmm, Pizza!

It's a cliché that developers like pizza.

Look here are some developers enjoying pizza at a previous event I organised.

This:

Quickly becomes this:

I've even heard developers be described as people who turn pizza (& coffee) into code.

I was recently talking with someone who was organising a meetup but was complaining about the lack of signups.

    "We're providing pizza, why haven't more people signed up?

They actually said that! As if people were coming for the food, and the technical talks, networking, socialising, and community building were all secondary.

Pizza isn't provided at evening meetups as a reason for people to come.

Pizza (or any other food) is provided at meetups, so people don't have to think (worry) about food or for it to be a reason for people not to come.

Pizza (or any other food or drink) isn't provided because of a concern for a lack of money to buy food. Developers are typically very well paid and able to afford to eat. 

[Side Note. I have had people come to events were there were concerns about some people only coming for the food, but I certainly wasn't going to turn people away based on this assumption. People attend for myriad reasons that are more varied and complex than anyone can imagine. You don't know what's going on in everyone's life and even if you asked they may not want or be able to tell. Based on where and when these meetings were happening, there were other ways to get food if that's what they really needed but couldn't afford. Sitting through several hours of technical talks as a way to get a drink and a couple of slices of pizza is unlikely to be a good trade off for anyone not interested in the technology.]

It's about convenience.

Pizza (or other food) is provided so that those attending don't have to think about when or where they will eat and how it fits around event attendance. As event organizers, it's necessary to consider situations like:

• If this person is coming straight from work, will they have a chance to eat beforehand?
• If they have to wait until after to eat is hunger going to distract them during the event?
• If they go somewhere to eat first, could they end up getting distracted and not come?

If a full day event and people leave at lunchtime to find food, there's a high chance that some of them won't come back in the afternoon.

Then there are events deliberately intended to fit around when people are eating. A breakfast or lunch time event would have to be much shorter if it also needed to allow time for attendees to also find food. The potential for missing a meal may also put off some attendees.

There's also a social benefit to sharing a meal (or even just a drink) with other people. With so many meetups calling themselves communities, it's great to be able to develop relationships between people based on more than a shared interest and location. Eating together can be a social lubricant to help start building relationships.

There are a lot of reasons and thought that go into providing food for developers at events and it's not about saving money or appealing to people through food.

Over the years, I've personally spent thousands buying pizza, other food, and drinks to help enable events to run smoothly. Only on a couple of occasions at smaller events did we experiment with asking for contributions. Being well paid at the time, this wasn't an issue. I expect that the majority of people reading this are people working in the software development industry who are well paid and never need to worry about being able to afford to pay for a meal.

But that's not the situation for everyone.

Food insecurity is a massive and growing problem and it's hard to imagine you can make a difference.

However, if you're in a position where you're well paid and you've ever been to an event where food was provided, please consider making a donation to Bankuet!

Bankuet is a social impact company who "make it easier to give to food banks." 

They maximize donations by letting food banks request the items they most need and then buy in bulk so that your donation goes further and waste is minimized.

You can either donate to a food bank in your area or make a general donation to where the need is currently greatest.

Please join me in supporting the excellent work they're doing.

https://www.bankuet.co.uk/givenow

"Testing in production"

It doesn't mean that you discover if something works when it's live and in use. You should test that it does what it's supposed to do before making it publicly available. (It's not an excuse for not verifying your work before saying it's done.)

It doesn't mean that you first lean about any problems with a change when it's in production. Changes should be reviewed before release and possible or likely problems addressed in advance.

It can mean that you release new functionality behind feature flags and roll them out slowly to all people.

It can mean that you A/B test new functionality in real scenarios.

It can mean that you monitor your systems in production to ensure reliability and performance.

It means that you need a way to gather feedback and errors from live systems.

It is also to recognize that things may happen in production that may not happen elsewhere.

Everyone should test in production. No one should only test in production.

Maybe don't think of MCP servers as an alternative to your API

Yesterday, I posted on LinkedIn about how I created an MCP server to return details from an experimental XAML analysis tool.

I've since been experimenting with it a bit more.

Without my tool, initially, Copilot told me that the file I was using for testing was great. (Sadly, I didn't get a screenshot of that.) But after running my tool a few times and then asking Copilot the same question without my MCP server, it started to suggest the possibility of improvements.

With a bit more pushing, it even started to be able to suggest things comparable to what my tool was providing:

The formatting it applied was even better than my simple string output.

But then I started asking about other files and it went back to giving generic feedback.

This whole experience has made me think about MCP servers in a new way.

If I have a tool or API that performs some specific task then I'll call that directly. Why further complicate things by getting an agent/AI/LLM involved?

If I have an API or tool that provides some data or information that it might be appropriate for the agent to use, then that might be appropriate as an MCP server (or other tool that an agent/AI) can use.

If I'm using an agent it might be appropriate to say "run this tool and make changes based on what it returns." In doing this the actions of the agent may not always be the same. Such is the nature of a non-deterministic system like an LLM based AI. Adjusting to the change from highly-deterministic systems to those that include a level of random variation may just be the hardest part of understanding "AI-based" computing.

If I know I want consistent results that are always presented/formatted the same way and don't have any random variations then I'll use a specific tool directly. If I want to make additional information available to the agent, or allow it to trigger external tasks, then an MCP server is highly appropriate.

I suspect this has some parallels with some businesses that are threatened by an Agent with an MCP wrapper to an API making them redundant. If all you're doing is providing data then where's the business? If you're creating/collating/gathering the data then that could be useful. If you're value comes from analysing or formatting data then AI could become a threat when it can do that analysis or formatting itself....

Sometimes we need people to run ahead

With so much seemingly changing at any one time, it can feel hard to keep up.

But, if all we ever do is try to keep up, how can we ever get ahead? Or even just prepare for what's coming?

I've recently been thinking about the benefits of thinking about the future in ways that some people consider extreme or unnecessary. But, I've found that thinking deeply about what is or could be a long way off actually helps with thinking about the short term too.

If someone runs miles ahead, they can have an excellent idea of whether the next few meters are in the right direction.

Knowing what is, or could be, a way down the road also helps you know if you'd benefit from extra planning or preparation before you get there.
Are there lots of hills ahead? Better build up the muscles to make climbing them easier.
Is the road ahead dangerous? Better pick up some safety equipment before you get there.
Does the surface change? Do we need some different tyres, or even a different mode of transport for the next part of the journey?

Draw the analogies as you see fit. ;)

Have LLMs made code-coverage a meaningless statistic?

TLDR: If AI can easily generate code to increase test code coverage, has it become a meaningless metric?

I used to like code coverage (the percentage of the code executed while testing) as a metric.

I was interested in whether it was very high or very low.

Either of these was a flag for further investigation.

Very low would indicate a lack of testing.

Very high would be suspicious or encouraging (if the code was written following TDD).

Neither was a deal breaker, as neither was an indication of the quality or value of the tests.

Now tests are easy. Anyone can ask an AI tool to create tests for a codebase.

This means very low code coverage indicates a lack of use of AI as a coding tool, which probably also suggests a lack of other productivity tools and time-saving techniques.

Now, very high code coverage can mean nothing. There may very well be lots of tests or tests that cover a lot of the code, but these are very likely to only be unit tests and are also very likely to be low-value tests.

There are two approaches to tests. Asking:

1. Are there inputs or options that cause the code to break in unexpected or unintended ways?
2. Does the code do what it's supposed to? (What the person/user/business wants?)

Type 1 tests are easy, and the type AI can produce as they can be written based on looking at the code. These are tests like: "What if this function is passed an empty string?"

Type 2 tests verify that the code behaves as intended. These are the kind that can't be written without knowledge that exists outside the codebase. These are tests like: "Are all the business rules met?"

Type 1 tests are about the reliability of the code. Type 2 tests are about whether you have the right code.

Type 1 tests are useful and necessary. Type 2 tests require understanding the business, the app, and the people who will be using it. 

Type 1 tests are generic. Type 2 tests will vary for each piece of software.

Type 1 tests are boring. Type 2 tests are where a lot of the challenge of software development lives. That's the fun bit.

Them: "We've got loads of tests."

Me: "But are they useful?"

Them: "Umm..."

I've recently started experimenting by keeping AI-generated tests separate from the ones I write myself. I'm hoping this will help me identify where value is created by AI and where it's from me.