Windows Apps London (formerly Windows Phone User Group) - it was good while it lasted

TLDR: User groups were great. I miss organising and going to them. Maybe I should revisit my plans about this...

I've organized over 100 user group events / meetups. I've also attended and spoken at many others.

The one I had the most to do with was the Windows Phone User Group, which later evolved/became Windows Apps London.

I "ran" this for as long as it existed. It all seems a very long time ago, but as I finish shutting up the virtual shop on the group (Stop paying for things--like domains--that I really don't need and no one looks at) I wanted to take a moment to reflect.

Here are a few of many pieces of similar feedback.

“Great to hear dev thoughts & experiences & see some interesting apps demo’ed”

“Met lots of cool people, and was well worth the trip.”

“Great bunch of people. Lots of enthusiasm and the usual witty banter”

“Meeting was great – fantastic bunch of WP7 developers, designers and officianados!”

“I really enjoyed everyone’s demos; even the games, which is not my domain, provided some interesting info about phone dev.”

“Thanks very much for putting on the event. I found it really useful as well as wonderfully motivating.”

“A great opportunity to meet and socialise with other developers.”

“We had a great time, really informative stuff, we learnt several things both from the talks and from general networking that we’re going to apply to our current and forthcoming projects.”

“Really appreciate the effort put into the event, great to meet everyone”

“It was great being able to network with intellectual individuals”

“It was really awesome. I now have the knowledge to create a better app.”

“It was very informative and enjoyable”

“Fantastic group. Always learn new things and pick up information”

“I like the format where someone knowledgeable us something we didn’t know already”

“One of the most interesting meetings I’ve been to”

“Wealth of knowledge to gain, recommended this to all developers”

“Good format, very useful.”

“Great event! Enjoyed the learning and the interaction with the other participants.”

“Thoroughly enjoyed the evening. Learnt a lot and looking forward to the next one.”

“Lots of fun, excellent talk and great people”

“I think this is a great event necessary for the platform. The atmosphere was good and enabling for sharing ideas.”

“Entertaining and inspiring talk”

“Really enjoyed the format! Great to hear everyone’s thoughts.”

“My mind is pretty blown away right now, very interesting evening with so much to takeaway and think about”

“Probably one of the best groups. Each meeting is useful for learning new things and getting a different point of view”

“Would love to see some more of these events”

“Fantastic presentation. Really helpful to pick up new tips.”

“Interesting conversation was flowing freely around the table. A really good night.”

“Great food, company, conversation and laughs!”

I couldn't let all the history of something that was a big part of my life for a very long time go away completely, so I've created an archive of the website at https://mrlacey.github.io/winappsldn/
Not that I really expect this to be of much interest or use to anyone any more, but it felt too important (to me) to let it go away completely.

Why developers should be excited about implementing migrations

I often hear that developers aren't keen on doing work to upgrade the frameworks/platforms/tools that they use (or the software they're building is using). It's not writing code, and so it's not considered "real development" work.

I think that doing the work to support upgrades or migrations is one of the most important and valuable things a developer can do:

• It's often a simple way to fix potential security vulnerabilities.
• It normally brings performance improvements.
• Updates bring new capabilities and options for things to add to the software.
• Keeping up with the latest versions makes future updates/migrations easier.
• It can help you learn and get hands-on experience with the latest technologies.
• It can allow you to see a large part of or various/obscure parts of the code base, helping you to learn more about the code you're working on.
• It can make it easier for other developers in the team.

So, a high-impact task that helps you learn while supporting the team by doing things they don't want to do? Sounds like a great thing to prioritise if you get the chance.

How quickly can a Windows application launch?

Following on from my recent post asking How much does start-up time matter when choosing a framework? I've now published some figures and the code I used.

With some minor tweaks, I now have an updated graph of the data:

This graph is based on the release builds of the simplest, most minimal apps I could reasonably come up with that were as close to identical in all frameworks.

The code and more details can be found at https://github.com/mrlacey/WinAppLaunchCompare

From that repo:

Miscellaneous observations:

• As expected, WinForms was super fast.
• WPF (both .NET and Framework versions) was surprisingly (disappointingly) slow.
• The difference between MAUI and WinUI is surprising given MAUI uses WinUI to create the Windows version of apps. I expected these to be closer.
• Of the cross-platform options (and WinUI) the difference is basically irrelevant. Having clicked the button to launch the apps many, many times, I didn't perceive any real difference, never feeling that one was slow or faster than the others.

My takeaways:

• For choosing a cross-platform framework, there's hardly anything in it in terms of the time it takes to launch the apps.
• I wouldn't base a decision to use a particular framework based on these (or similar) tests/results.
• I also looked at the time until the App class was loaded. This varied but didn't seem to be related to the overall time taken.
• Performing tests like these can easily become an infinite rabbit hole. There are always potential tweaks and optimizations that could be done. If you have such an interest, please go ahead.

Feel free to experiment with this code as you wish and suggest any ways it could be improved or anything artificially slowing down a version of an app can be addressed.

What makes a good teacher of technology?

I guess it comes down to different people wanting different things. Or, maybe, I'm looking for different things than the majority of people are looking for.

Being aware that I'm trying to learn a variety of new technologies at the moment, and also writing things to try and find a new way of teaching something I'm very familiar with.

Here's what I've seen a lot lately:

Teachers (either qualified educational professionals or people whose job it is to teach and are recognised as experts at teaching new technology) will explain that there are different options or ways of doing things, and then say, "I always use X, so you should too."

Is it that the people learning are just looking for a seemingly authoritative answer, and so are happy to use/do X because they've been told that's ok?

Or, is it that explaining the nuanced differences between options and where/why/how you'd use each and what each is intended/best for is much more difficult and so people don't (or can't) try?

Or a combination of the two?

I find it a bit like being told, "There are lots of potential tools in the toolbox, but I always use a hammer, so you should just use a hammer."

Simple answers are attractive, but don't provide the knowledge to know how to use something other than a hammer or even tell when using a hammer is not appropriate.

I want that deeper knowledge.

Maybe others are happy with a simple solution. When their hammer stops working or can't be used, they'll come back with questions about alternatives. 

I prefer to know in advance if I'm going to be using the wrong tool or what the potential negative consequences of what I'm planning will be.

I want all the learning up front. If you're selling education (or views), then holding back some of the knowledge until later has a benefit for you. But, who is the lesson for?

what "everyone" gets wrong about "write once run everywhere"

It was never meant to be about the ability to write a single app that runs on any/all devices.

It is about the ability to use the skills/tools/technologies to build software that can run on multiple operating systems, devices, hardware, etc.

There are a very small number of scenarios where you want the exact same code running on every imaginable device. Even when you do want this, there needs to be logic within the software to account for the differences:

• Different input devices (not just touch, mouse, & keyboards)
• Different output devices (not just size of screen, or none)
• Different sensors or physical capabilities
• Different usage scenarios
• Different connectivity or storage capabilities
• Different user permissions or account settings

There's the dream scenario where you build a piece of software for a specific OS and/or device type, but then decide it would be nice if it ran somewhere else too, and you hope that tooling can magically make it happen for you.

Sometimes this works. To a point. But you'll almost always want some customisation or need to handle different scenarios or capabilities the new device(s) present.

What's useful is: when you know you need to build software that needs to run in lots of different places/ways, you can benefit from not needing to learn/support/maintain different technologies to build all that software. 

It's not just about the reuse of code once written, it's also about the reuse of skills.

How much does start-up time matter when choosing a framework?

I got nerd-sniped.

I was asked about measuring and possibly benchmarking different .NET frameworks for making native apps in terms of performance.

Apparently, this is an important factor for some people when choosing a framework.

I think I know better. I know you can write very bad (hence slow) code in any language or with any framework. I also know there are almost infinite things you can do to make code faster.

A basic comparison didn't seem very useful. I knew that if I saw such a thing, I wouldn't care very much, as it all comes down to optimising appropriately in a real app, given the constraints and requirements of/for that particular app.

I tried to find a way to get excited about the prospect, but couldn't see what could be exciting.

However, two questions persisted:

1. Do other people care?
2. How much difference is there?

It's hard to know if other people care, but is there a significant difference?

Time for a quick experiment...

Doing the simplest and quickest thing I could, I did a quick test to see how long it takes to launch a trivially simple app and for it to report that it has finished loading.

Here are the initial results:

The Windows Forms perf was to be expected and was included as a reference for the others.

Why is there so much difference?

Is this interesting?

Do you care?

Should I go deeper in investigating more realistic scenarios and considering simple optimizations (like AOT)?

Let me know if you want to know more.

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.