Is second-order enshittification a thing?

 
Enshittifcation, as a term popularized by Cory Doctrow, has for many become a catch-all term for things generally getting worse. I've found it useful (unsurprising if you know me) to think about it in two categories.
There's the popular definition of how very large, dominant platforms change [to get worse] over time as business/organizational priorities change.

I think there's a second-order version of this that follows as a response.

I'd sum it up like this:

"If [big company] doesn't have to focus on quality, we can cut corners there too."

What happens when "everyone" takes this approach is that things get continually worse. Not all at once and not always in the immediately obvious ways. More in the million paper cuts way.

From a software perspective, it's the increasing number of small bugs that no one seems to care about fixing. This teaches people to not bother reporting them. After all, "what's the point? They're not going to fix it even if I [you] do report it."

With fewer known or reported bugs, the company thinks everything is fine, or worse still, thinks skipping on quality is an approach that works.

And a self-reinforcing cycle continues.

I prefer to think of it another way.

Software exists to help people and to make their lives "better". This could be in one or in many ways.

When people are constantly being interrupted, frustrated, and disappointed by the software they use, it's very hard to argue that it is making them better, happier, or more productive.

This is part of the reason I think that QA, customer service, and fixing bugs are among the most important things that those in software development can focus on.

With AI making copying software easier, it's focusing on how it relates to people that can be the real differentiator. 

Yes, AI may mean you can vibe code a copy of something that exists, but does it include support for all the non-obvious edge cases? Do you even know all the features that exist in what's being copied? How (and?) will you handle any bug reports?

Yes, building software can be fun for you, but high-quality software that works reliably benefits many more people and, in a small way at least, makes the world a better place.

And this can also lead to mediocrity

A small company tries to compete with a large one. They try to do everything because that's what the large company (or their software) does. They try hard, but as they're stretching themselves so thin, everything suffers. "Never mind", they say, "at least we're trying our best." But, for what? Who benefits? The company's staff exhaust themselves producing a mediocre product, and it's no better than the alternatives.
Trying to compete with a large company and basing goals on the perceived [low] standards of another company doesn't produce a great product, happy customers, or happy staff.

_This was written many months before posting--to avoid anyone thinking I'm responding to a single person, company or incident_

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 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

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. ;)

The problem with multi-word terms (including "vibe coding")

TLDR: I think it's worth being clear about the meaning of the words we use. Maybe compound terms 

Not wanting to sound too pessimistic, but I think it's fair to say that we are Lazier than we realise and not as smart as we think.

We hear a term that's comprised of multiple words we recognise, and assume a meaning of the overall term based on our individual understanding of the individual words.

Let me give you three 3 examples.

1. "Vibe coding"

Originally, it was defined to describe people "going with the vibe" and letting the AI/LLM do all the work. You just tell the AI what you want and keep going until it has produced all the code and deployed the resultant software without having a care or knowledge about how it works.

But some developers heard the term, presumably thought "I know what coding is and I know what good vibes are so if I put them together that must mean 'using AI to produce code that gives me good vibes.'" 

The result: there are lots of different understandings of the meaning, and so whenever it's used, it's necessary to clarify what's meant. Yes, there can be lots of different meanings and I'm not going to argue that one is more valid than the others.

2. "Agile development" 

The original manifesto had some flexibility and left some things open to interpretation or implementation appropriate to specific circumstances. However, I suspect, there were a lot of people who thought "I know what development is and I know what it means to be agile so I'll just combine the two."

The result: everyone has their own understanding of what it means to "do agile development". Some of those variations are small and some are massive. I've yet to meet two different teams "doing agile development" who do things exactly the same. Does that matter? Probably not. It's just important to clarify what people mean when they use the term.

3. "Minimal viable product" (MVP)

Yes, you may know what all the words mean individually. You may even have an idea about the term as a whole, but the internet is bursting with explanations of what it actually means. My experience also tells me that if you have a development background, your understanding is highly likely to be very different from someone in product or marketing.

Does it matter? It depends on whether all the people using the term are in agreement. It might be fine if you're using it as an alternative term for "beta", or you mean it must have a particular set of features, or it requires a certain level of visual polish. I think that you can prove it's viable based on customer actions is more important. But, again if all the people on your project can agree on the meaning, I trust you'll work it out. (Confession: I left one job because the three people in charge--an issue for another time-- all had a different understanding of what MVP meant, but refused to give their definition or acknowledge their definition was different from the others. It made the work impossible.)

Some people (Or, maybe all people, some times--I have done this myself) will hear a word, assume a meaning and not ask any questions.

I've observed a similar thing with headlines. People make assumptions based on headlines or TLDRs, and so don't get to appreciate the nuance. Or maybe don't even appreciate that there might be more than a simple explanation.

Nuance matters. It's the detail where the devil hides. It's the 80% of edge cases accompanying the 20% of the obvious in a 'simple' scenario.

Words matter. I probably spend far too much of my time thinking about words because they're a foundation of communication.

Yes, for many people, words don't matter.

But, going back to thinking about "vibe coding", words are how we communicate with machines. While the trend has always been for "higher-level" languages, we didn't go all the way to our spoken languages previously because of

A) technical limitations 

B) the lack of precision in our spoken/written languages 

AI/LLMs overcome some of the technical limitations and can make some reasonable guesses to work around the lack of precision.

Relying solely on natural language to express all the subtle details and the specifics required with software using only a few sentences, or even paragraphs, doesn't seem appropriate.

Some people think 'Nuance doesn't matter' until the software doesn't do exactly what they expect in an edge case scenario.

Producing software that isn't as good as I want/expect may just be part of the enshittification of life.

I think many people believe (or think they can get away with) acting like "Close enough" is the new "Good enough".

Magpies are very vocal. And, maybe they're right. Perhaps we should just focus on the new and shiny.

Or if using AI/LLMs saves money and cuts costs, that's all that matters. Well, matters to some. I definitely don't think it's all that's important.

Then I wonder about choosing names for things. 
If there are such potential problems when combining existing words. Maybe using made-up words or words with no direct correlation to the thing the name is used for....

Now, I'll just wait for the comments that tell me I don't understand the above terms correctly...

Sales, Marketing, and Advertising

I'm writing this for my own benefit and to think it through.

I'm trying to get some ideas clearer in my head by reducing them to something specific and simple. Obviously, the real world is more complicated and nuanced. I can't reduce whole industries down to a few paragraphs.

Let's start with some definitions:

Sales: Exchanging money for a good or service. Or activities relating to this.

Marketing: Saying 'here is a thing.'

Advertising: Saying 'buy this thing.'

Of course, people rarely buy something before being aware of it. Advertising and/or marketing create awareness that leads to sales.

When advertising creates enough sales to keep going, a business can be successful.
Put money into advertising. Create sales to more than cover the advertising. Make more money. Repeat.

Marketing is intended to eventually lead to someone buying a thing, but it may do so indirectly. By simply showing a thing, it may lead to people wanting to buy it. But it might "just" be increasing awareness so that someone will consider them (the company or a product) favourably (or at all) when looking to make a purchase in future.

Marketing may also be able to produce something that can "spread" / be shared / "go viral", so that it reaches more people than paying for direct advertising.

A "thing" can also be a concept. People still need to "buy" into an idea!

The marketing of ideas can be a powerful thing.

The boundary between advertising and marketing can be blurry. At least one is needed. A thing won't sell (or spread) if people don't hear about it.

Sorry, no conclusions or summaries here, just a desire to learn and grow.

Software development as "creative problem solving" - and me.

The following is inspired by multiple interviews with actors and comedians. - Yes, I find software development inspiration in unusual places.

A motivated person who wants to make it in the 'arts' will typically have to do many things by and for themselves.

This means being a creative problem solver.

Want to put on a show but don't have a stage, set, or costumes? - Work something out!

Want to make a film but only have a tiny budget? - Get creative!

Want to try something entirely new and different that no one has thought about before and that everyone says is impossible? - Find a solution! Help others see your vision!

These are also the aspects of software development that I love best.

While software can do "anything", such a broad set of options is rarely helpful. Constraints are real, and they drive innovation and creativity. The constraints often lead to discovering that something isn't as impossible as originally thought.

There may be a need for people to build software that is the same as (or a tiny deviation from) what already exists, but I don't want to do that.
Not because it's beneath me but because it doesn't excite me.

I've previously particularly enjoyed projects along the lines of:

"We need it to do X but can't use [the only way anyone has ever done X before]."

or

"We only have 5 weeks to build [seemingly large and complex series of connected software], or we miss out on a massive opportunity for the business."

or

"We want it to do Y, but as no one has ever done that, we don't know if it's possible and can't (yet) see how to do it."

There are two ways such projects can be even more satisfying (to me):

1. When I get to see and hear how the created solution helps people and improves their lives. Even if only in a small way. 
2. When I'm creating something that helps improve things for other software developers. This is because improvements for them are multiplied into more, higher quality software that is beneficial (or even "just" less frustrating) to many more people.

This is, possibly, why I've recently refound an enthusiasm for the possibilities that come from creating software.

2024 wasn't a great year for me. I left what was initially a very exciting project as a team was formed around the work I'd started. As I felt the project moving backwards, it became frustrating and unproductive, and so I stepped away, wondering if this was even an industry I wanted to stay in.

Side note. Many months later, a simpler version of the project was launched, which received much acclaim and positive reactions. Hopefully it will go on to be very helpful to a lot of developers, but I can't talk about it in any detail.

I planned to take some time off and reassess my career plans.

That's not how it played out, as I sustained a physical injury that meant I had six months where all I could do was sit (literally) and watch the world (and work) go by.

It was like a miniature version of the COVID-19 lockdowns, but just for me.

Upcoming plans were cancelled. These included career goals, planned jobs, and events I'd been looking forward to for months (and even years in one case.) It was not a happy time.

At the start of 2025, when once again mobile and recovering well, I determined to forget the past year and try and find not only paid work (because bills don't stop when people do) but something that would excite me again. A way to use my creative problem-solving skills that could help other developers improve the overall quality levels of the software in the world.

As my experience is with native (rather than web) technologies and because I've spent a lot of time over the last few years thinking about how it can be easier and more productive to work with XAML, I've been thinking about that once again. As I refine what I would have previously thought was "too big an idea for me", I also look forward to sharing more about that soon.

Superstition, placebos, belief, and "playing with code"

Another brief post to help me think by writing.

I recently heard that "there's no merit to length in writing." They were talking about reducing the length of their book from 220K words to 180K, but the idea stands. The value isn't in the number of words, the value is in what it makes you think or do as a response to what you've read.

I've also recently recognized that when I'm thinking about a new idea, I spend a lot of time focusing on how to first express that idea and make little progress in progressing the idea. Once I first start writing and articulating that idea then I make progress in thinking about the consequences and application of that idea.

So, ...

I've recently been struck by the idea that "superstition is a placebo for belief." There's lots to unpick there and maybe that will come in time.

Beliefs are also strong and hard to change. Ironically, this is especially when people think they are very logical and intelligent.

I've recently encountered as lot of developers who are reluctant to embrace significantly new ways of doing things. 

Side note for the irony of developers being responsible for creating change (by producing or altering software) but reluctant to embrace change themselves.

They will quickly try something new (or "play with a new technology") and then quickly decide that it's not as good as what they currently use (or do).

Maybe "doing things the way I've become accustomed to doing them" ("always done them"?) is a superstition about being productive and a believe that it's the best way to do something.

Briefly "playing with something" (Yes, I dislike this term) is unlikely to provide the time or chance to learn the nuances of something dramatically different to what they've used before. It's also likely that it won't enable the opportunity to fully appreciate all the potential benefits.

Or, maybe the time to "ramp-up" on using something new means that it's never adopted because "there isn't the time" now to slow down while learning something new, even if it means being able to save time and move faster in the future. 

Or, maybe it comes down to not appreciating the possibilities of a new technology that requires thinking about usage in a fundamentally (an conceptually?) different way.

I've seen the above happen over and over again as new technologies come along. i.e. Asserting that "the new technology is slow" when using it in a way that an existing technology would be used but that is far from optimal for the new technology.

It's not the technology, it's what you do with it. Unfortunately this isn't always easy to identify without spending a lot of time using it.

And the placebo? - That there can be a perceived performance (or other) benefit by not changing when compared with the short-term impact/cost of slowing down to learn to do something new.

Yes, this applies to AI/LLMs, but to many other things too...

where did the SOCIAL in social media go?

I joined Twitter, and Facebook, and MySpace (although I was a bit late there) on the same day in 2007. Until then I didn't see the point.

MySpace was already pretty much dead by that point. Over the years Facebook became a way of keeping up with family and friends I knew locally. While Twitter became a place to connect with, meet, share, and learn from others with similar interests.

With many people and the friends and acquaintances, I'd made over the years, who had those interests, mostly gathered in one place it made keeping up with announcements, updates, and just general chit -chat possible. I found it reasonably easy to keep up with what was going on in the areas I was interested in. It was, of sorts, a community.

And then a bomb was set off under twitter.

With people leaving at different times and going off in different directions to different alternative apps. It became an impossibility to keep track of everyone who moved to a new platform/app. (Especially with the misinformation about sharing usernames and accounts on other platforms.)

I now have a "presence" in multiple apps (Mastadon, Blue sky, Instagram, Threads, and yes still X -- all profile links 😉) 

But none of them seem a patch on the community that existed before.

In each app there are a few accounts that I used to follow all in one place, but it seems an uncomfortable and unnecessary effort to keep opening and scrolling through each one on the chance of finding something important and/relevant. Plus each now has a terrible signal to noise ratio that is off-putting.

I've tried cross-posting across apps, but the expectations of content on each seems so different. Although I know others treat them as interchangeable--with varying results.

If I just feel the need to say something that I think/hope will get a response I'll go to Twitter/X, but then I'll feel bad because of all the people being vocal elsewhere about why they left and closed their accounts.

Yes, what Elon did to Twitter and what X has become are far from great, but I don't want to be another voice complaining.

How (and) can an online community be created that's anything like what we had in the past?

I know a bit about building communities IRL, but where and how are online communities really built?

Or should I just give up, pick one app, and start making connections again...

A lesson in algorithms from Guess Who

Earlier this week, I attended the DotNetNotts user group meeting. The second talk of the night was by Simon Painter and was about some of the algorithms used in Machine Learning.

As part of his explanation of decision trees, he used an example based on the game Guess Who?

Here's a screenshot, from YouTube, where the hybrid part of the meetup was relayed.

If you're not familiar with the game, you have to ask yes or no questions to identify one of the characters:

Alex, Alfred, Anita, Anne, Bernard, Bill, Charles, Claire

David, Eric, Frans, George, Herman, Joe, Maria, Max

Paul, Peter, Philip, Richard, Robert, Sam, Susan, Tom

As part of his talk, Simon stated that the best strategy and ideal scenario for any decision tree is to divide all the available options in half (a binary split). However, for this game, there are no characteristics of the characters that make this possible (and hence the challenge of the game). 

Simon did however point out that there is the possibility of using compound questions to have a greater chance of success by more evenly dividing the groups in half each time.
So, instead of limiting questions to the form of "is the person wearing a hat?" you use questions like "does the person present as female OR have facial hair?" or "does the person have blue eyes, a hat, OR red hair?"

Such questions were relevant for the rest of the talk, but it got me wondering.

I looked at all those people and their names and thought I saw something...

About half the people seem to have names containing two vowels...

It turns out that 15 people have names containing two vowels. This is better than any visual differentiator but is still far from perfect.

Ideally, you want to divide the group in half each time.
So, we'd go from 24 > 12 > 6 > 3

When you get to only having three options left, there are myriad ways (questions) to differentiate any of the options in this version of the game, but (without having done the math), it's just as quick to guess each person/option in turn.

What we need to maximize our chance of winning, and probably remove all fun from the game, is a set of questions that will divide the group in half until it gets to a group of 3.

It was only on my way home that I realized that if I'm going to look at the letters in the names of the people there are probably more and better questions that can be used to play a perfect game of Guess Who without using compound questions?

And so, (because I'm "fun") I tried.

It actually turned out to be really easy to find such questions. And by "really easy", I mean it took me less time than it's so far taken me to type this.

Here are the questions:

Question 1: Does the person's name start with a letter that comes before 'H' in the alphabet?

This is a simple split.
If they answer yes, you get the people Alex - George.
If they answer no, you are left with Herman - Tom.

If the first answer was Yes, question 2 is: Does the person's name start with a letter that comes before 'C' in the alphabet?

Another simple split.
If they answer yes, you get the people Alex - Bill.
If they answer no, you are left with Charles - George.

If the answers so far are Yes & Yes, the 3rd question is: Does the person have facial hair?

If the answer to this question is Yes, you're left with Alex, Alfred & Bernard
If the answer to this question is No, you're left with Anita, Anne & Bill.

If the answers so far are Yes & No, the 3rd question is: Does the person's name start with a letter that comes before 'E' in the alphabet?

If the answer to this question is Yes, you're left with Charles, Claire & David
If the answer to this question is No, you're left with Eric, Frans & George.

If the first answer was No, the next question to ask was the hardest to identify. Question 2 is: Does the person's name contain fewer than 3 consonants?

Another simple split.
If they answer yes, you get the people Joe, Maria, Max, Paul, Sam & Tom.
If they answer no, you are left with Herman, Peter, Philip, Richard, Robert & Susan.

If the answers so far are No & Yes, the 3rd question is: Does the person's name start with a letter that comes before 'P' in the alphabet?

If the answer to this question is Yes, you're left with Joe, Maria & Max
If the answer to this question is No, you're left with Paul, Sam & Tom.

If the answers so far are No & No, the 3rd question is: Does the person's name start with a letter that comes before 'R' in the alphabet?

If the answer to this question is Yes, you're left with Herman, Peter & Philip
If the answer to this question is No, you're left with Richard, Robert & Susan.

Yes, this was a questionable use of my time ;)

If you don't think questions about the letters in the person's name are appropriate or allowed, please keep that opinion to yourself.

Anyway, if you want to know more about machine learning the whole event is available online.

Further silly posts about over-analyzing games are unlikely to follow. "Normal" service will resume shortly.

Reflecting on 1000+ blog posts

These are the current numbers for my blog. (Well, at the time I first started drafting this. I expect it will be several days before it's posted and then they will be different.)

These are the numbers I care about.

The one most other people care about is 2,375,403. That's the number of views the articles have had.

But this isn't a post about statistics. This is a post about motivation and reward.

 

I started writing this blog for me.

That other people have read it and got something from it is a bonus.

If I were writing for other people, I would write about different topics, I would care about SEO and promotion, and I would have given up writing sooner.

I get lots of views each day on posts that I can't explain.

I know that most views of this blog come from "the long tail," and Google points people here because there is a lot of content. The fact that I've been posting for 17+ years also gives me a level of SEO credibility.

There have been periods where I have written very little. This is fine by me. By not forcing myself to publish on a particular schedule, the frequency of posting doesn't hold me back or force me to publish something for the sake of it.

I publish when and if I want to.,

Some people need and/or benefit from forcing themselves to publish on a regular schedule. If that works for you, great. If it doesn't, that's okay, too.

Others might think a multi-month gap in posting is bad, but if that's what I want or need, it's okay. Over a long enough period, the gaps are lost in the overall volume of posts.

I'm only interested in writing things that don't already exist anywhere else. This probably holds me back from getting more views than if that were my goal, but it probably helps me show up in the long tail of niche searches.

And yet, some people still regularly show up and read everything I write. Thank you. I'm glad you find it interesting.

Will I keep writing here? I can't say for certain but I have no plans on stopping.

I'm only publishing this post because I thought I might find it useful to reflect on all that I've written, and 1000 posts felt like a milestone worth noting, even if not fully celebrating. Originally, I thought I'd want to write lots about this, but upon starting it feels a bit too "meta" and self-reflective. I don't know what the benefit is of looking at the numbers. What I find beneficial is doing the thinking to get my ideas in order such that they make sense when written down. That's, primarily, why I write. :)

I don't want to be interesting

This is a great book. I heartily recommend it. However, I don't think it's interesting.

I don't think it's interesting because I don't like that word. 

"Interesting" is vague.

"Interesting" is meaningless.

"Interesting" is a word people use when they don't know what else to say.

Try it. Next time someone tells you about something "interesting", ask them what made it interesting or why they thought it was interesting.

Or consider when someone tells you they "have something 'interesting' to tell you." Is it really interesting? Or is it gossip? Or is it something they don't have a better description for?

"Interesting" is unspecific and unconsidered. Not the book, the concept.

 That's not what I want to be, or do, or be thought of.

Here are some much better adjectives (in no particular order):

challenging
inspiring
thought-provoking
troubling
upsetting
motivating
fascinating
amusing
entertaining
captivating
encouraging
intriguing
inviting
gripping
impressive
restorative
engrossing
enchanting
enthralling
spellbinding
diverting
attractive
rousing
persuasive
provocative
stimulating
stirring
exceptional
exciting
unforgettable

Don't those sound more appealing?

It's the first three items on that list (challenging, inspiring, thought-provoking) that I think apply to that book, too.

Understability of code should be the default priority

All things being equal, so not when performance is an issue, and in addition to any existing coding conventions, the understandability of code is the most important thing.

Typically this means, "can I read the and easily understand 'everything' about it?"

In the past, I've said that "readability" is the most important thing but what I've realized lately is that I mean: can I easily read it AND understand it?

This is more important than "SOLID principles" or "Clean Code."

Delivering value is the end goal when writing code. The code is a means to an end. It's not an end on its own. The primary goal is not to have code that meets a specific standard. Even if there are appreciable benefits from following that standard. The goal is to benefit the people using the code.

Yes, there are many reasons for following established principles, practices, and conventions. I recommend and follow many myself. But they're not the most important thing.

It doesn't matter how great the code is if you don't ship.

It's great that you've structured code to make it easy to maintain, but if you don't release bug fixes or new features, I question the value of the effort put into how the codebase is structured.

I've seen code that is technically "clean" but is slow and hard to understand and modify.

I recently met some developers at a company who highly prioritize "clean code." But, their shipping schedule was so slow that their customers complained about the infrequency of new features and updates. They had a massive backlog of "core" functionality that was expected to take years to be implemented. Their competitors had more features, more customers, and a better reputation. The developers at this company wanted to create a better product but admitted that their focus on "clean code" meant their development process wasn't as fast as it could be. I'm not implying it's the only issue or factor, but the product, their customers, and ultimately their business weren't as competitive as they could be because of an arbitrary set of rules they were enforcing upon themselves.

Obviously, there are multiple factors to consider when deciding what to prioritize. Priorities will also differ for products, domains, and personal preferences, but having a fixed rule that is never changed can hurt as much as it's designed to help.

Test coverage is also an important related factor. If I'm not writing something "test-first" (because sometimes this isn't practical or desirable), my guiding principle is that anything "non-trivial" should have tests. I define "non-trivial" as anything where I can't look at the code and immediately see and understand every code path and likely error case. It's not always perfect, but it's served me well for years.   

I don't have any "hard and fast rules" for when to play specific practices or when to structure code in specific ways, but "is this easy for me to read and understand?" is my guiding principle. And if I'm working with a team, having code reviews can verify that others working on the code can read and understand it too.

If I can understand it, I'm aware of the potential consequences of any changes, regardless of how it's structured.

I'm curious if others have general principles for planning and structuring code. Anything that doesn't include "must" or "always" (or treats "should" like "must") but instead acknowledges the complexities of managing multiple priorities in different circumstances.

Laughter and creativity - Peter Pendleton Eckersley

It cannot be more sufficiently emphasized that, that pioneer adventure was born in laughter, was nurtured in laughter, and died in laughter.

And I want to believe that if only people would see their jobs; if only people would see their lives in terms of its humor, of its excitement, and that a job well done deserves laughter.

Not the solemnity of the pompous administrator on top of it.

If we could only see that the thing that we do is a God-given thing, for heaven's sake,  because it's creative and it's fun and it's exciting.

Then, I think, all these certificates, all these rules, all these rather dull regulations might be seen to be unnecessary.

Peter Pendelton Eckersley - on the bureaucracy that came at the start of the BBC

Plant trees while you search for error descriptions

 

Ecosia is a search engine that uses some of the money they make from selling advertising to plant trees. You make a small change to your search behavior and they plant some trees. It's simple.

There's even an extension for Chrome to make it your default search engine. (You should install it 😉)

Under the hood it uses Bing to provide the search results, so you'll still get high-quality results. This isn't some random, small company trying to compete with Google on Search.

That all sounds good, but I've done a bad thing.

I've changed a default setting.

Shock. Horror!

For my Error Helper extension for Visual Studio, the default is now (as of v2.4) to search with Ecosia.

Changing default settings is something you should only do with great care and for very good reason as it can surprise, confuse, and frustrate the people using the software.

If you're not aware of my extension, it provides some additional options when you right-click on an entry in the Error List. The one of particular interest here is the option to easily search for the text of the error message. Sometimes, error messages don't give you all the information you need to address an issue and so it's necessary to ask the internet for help.

But I did it for a very good reason.

I wanted to help raise awareness of Ecosia, and in turn, help create a world with more trees in it.

This will help plant a few trees based on usage and people not even realizing anything's changed.

The impact on existing users of the extension will be minimal as it will continue using whatever they were using with the previous version. Even if that was the old default.

I'm just trying to do something to help other people make the world a slightly better place with minimal effort on their part.

Don't want this? That's ok, you can still configure the extension to use, Bing, Google, or StackOverflow as the search engine of choice.

If you're very upset by this, simply send me your receipt for your purchase of the extension and I'll give you a full refund. (Just kidding, the extension is free!)

Why some things never get better

So, imagine you're dealing with a technical problem. 

There's no specific tooling to help with your scenario.

You can muddle through but everything feels harder than you'd like. 

There are a few simple tools or features that would make this much easier. They'd handle the need to do complicated things manually and avoid errors that are easily made when doing things manually.

But, this thing you thought was going to be easy has turned out to be harder and more time-consuming than you had planned for.

You're now frustrated and behind. 

You just need to get this done and move onto the next thing.

You can't justify the time to work on tooling as well as solving the problem immediately in front of you.

The whole thing has become so frustrating that you just want to get it fixed so you can move onto the next task and not have to think about it again.

You certainly don't want to spend more time thinking deeply about the issue. As would be needed if building a tool to help with it.

So you move on to the next thing.

Maybe, you think, you'll come back to this once the initial pain has passed and work on the tooling that will be useful for yourself in the future and for other people too.

But you're busy.

Other things have a higher priority. Plus, you can't fully remember the pain you felt previously. Maybe it wasn't that bad. Maybe someone else will have made something to help when you have to work on something similar in the future.

And so you don't create that tool.

Sometimes things only get better when you take it upon yourself to deal with extra pain so that others don't have to.

Sadly, I'm not able to handle as much of that extra pain or as frequently as I'd like. :(

</rant>

Imposter syndrome - a coin with 2 sides?

Lots have been written about Imposter Syndrome, especially with how it relates to the world of software development. I wouldn't normally write about such things here but I've recently been struck by a new, related idea and it felt too long for Twitter.

Talking about complex issues can be hard as it's natural to assume that other people have similar thoughts and experiences as yourself. But that's not always the case.

But what if all imposter syndrome is not the same?

I think there are two kinds (there may be more but two is enough for me, now.)

• I don't deserve to be here.
• I don't deserve to be allowed in there.

The order doesn't matter.

It's easy to think they are the same but there are some subtle differences.

One is about loss and one is about gain.

But, both are about self-doubt, fear, a lack of appreciation for own value, and neither are necessarily rational.

In that "people in tech" often think of themselves as logical and want everything to be logical this can make it difficult to talk about.

It's also possible to have both thoughts about yourself. Not about the same thing but about different or even similar topics at the same time or in quick succession.

It sometimes feels like everybody has imposter syndrome at least some of the time.

Not everything is imposter syndrome though. Sometimes you can be in positions you don't deserve to be in. Sometimes you'd like something, to be, or do something that you're not qualified for or yet capable of.

But what can we take from this? It doesn't sound like I've made any great insight.

Well, here's the thing that struck me. 
It's important not to assume that the imposter syndrome another person is currently feeling the same kind of imposter syndrome as you.

For example:

If you're someone with a job and your imposter syndrome makes you state you don't feel like you should be there, it can be really disheartening for the people who would love to be there but their imposter syndrome tells them that they don't deserve to get a job there. 

Or people with good jobs they clearly deserve saying they have imposter syndrome can be really disheartening for those without a job and have struggled to get one, for years and so feel their own sense of imposter syndrome about being worth employing.

It works the other way too. If you have imposter syndrome about not being recognized or accepted for something, it's tough to hear people who are recognized say they have imposter syndrome about being acknowledged that way.

Beware of dismissing other people's imposter syndrome. Especially when it's different from the type you experience.

Both types of imposter syndrome offer an opportunity for self-improvement. As a prompt to increase technical skills and as an opportunity to acknowledge your own value and worth, regardless of 

Reasons to ask a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 12(+) reasons to ask a question:

1. To get an answer.
2. To force others to think about the question's topic.
3. To encourage someone to think about how they'd answer (even if they don't.)
4. To get attention. 
5. To get a response (that isn't a direct answer.)
6. To show (admit?) that you don't know (everything.)
7. To show a willingness to learn.
8. To show that asking questions is good/ok/acceptable/encouraged.
9. To show an example of questions that can be asked.
10. To show that you've thought about (or researched) the subject enough to be able to ask smart, informed, appropriate questions.
11. So others can hear the/their answer.
12. Never for no reason. 
13. Other?

I know the above is a generalization, and it won't apply to all scenarios but is a helpful summary of the things to consider.

Questions to ask BEFORE asking a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 12(+) questions to ask yourself before asking a question:

1. Can I work out the answer myself?
2. Can I find the answer myself?
3. Will the person I'm asking know the answer?
4. Can they know the answer?
5. Will they be able to give me an answer if they know?
6. What will it cost them to answer?
7. Will this impact my ability or opportunity to ask other questions?
8. Will others want to know the answer?
9. Have others asked the question before? and what, if any, answer did they get?
10. Why isn't the answer easily/already available?
11. Is this the best time to ask? And if not, when is?
12. Have I been paying attention to what has been said already?
13. Other?

I know the above is a generalization, and it won't apply to all questions but is a helpful summary of the things to consider.

Not all are always relevant, appropriate, or useful, but all are worth considering before asking (or even answering) a question.

Questions to ask BEFORE answering a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 12(+) questions to ask yourself before responding when asked a question:

1. Do I know the answer?
2. Can I tell them the answer? (If I know.)
3. Should I tell them the answer?
4. Why do they want to know?
5. What assumptions do they have that have led to (or are evident from) the question?
6. Why do they think I know (or can get) the answer?
7. What will they do with the answer I give them?
8. Is there something I can give them better than the answer to their question?
9. What led them to ask this question?
10. Are other people likely to have this question?
11. Where else can I share this answer?
12. What type of answer are they expecting? (long, short, etc..)
13.  Other?

I know the above is a generalization, and it won't apply to all questions but is a helpful summary of the things to consider.

Not all are always relevant, appropriate, or useful, but all are worth considering before answering a question.