Wednesday, March 13, 2024

Tuesday, March 12, 2024

Reverse engineering a workshop

I've been working on writing a technical workshop. I've not done it before, and I couldn't find any good, simple guidelines for creating such a thing.

Having asked a few people who've delivered workshops in the past, the advice I got was very generic and more about the workshops they've proctored rather than how to structure one or put one together.

So, rather than make it up, I started by trying to reverse engineer what good workshops do.

I want the workshop to be fully self-paced and self-guided. If it can be used in group or "instructor-led" scenarios, that'll be good, too, but I don't have any plans (yet) for this.

From looking at many workshops I've completed and thinking back to those I've participated in in the past, I was struck by how many take the approach of showing a completed project and then simply listing the steps to create it. I find this approach to often be disappointing.
Yes, as a participant, I get the satisfaction of having created something but it's not something new or necessarily specific to my needs. More importantly, the reasons for each individual step weren't explained, and the reason for taking an approach when others are available (or even what the other approaches are) wasn't given. This means that I don't get the wider knowledge I likely need to be successful. Is the intention that in completing a workshop, you have the knowledge to go and build other things and the confidence to do so, having done it once before? It probably should be. 

What I find many workshops end up doing (intentionally or otherwise) is providing a series of steps to recreate a piece of software and assuming that's enough for the participants to then go off and successfully create anything else.

Yes, saying, "Anyone can follow our workshop and create X", is great. But that's not the same as a workshop that teaches reusable skills and provides the knowledge needed to go and create your own software.

I want to create a workshop as a way of teaching skills and introducing a different way of thinking about a topic.


Aside: what's the difference between a workshop and a tutorial? I think it's that workshops are longer. Possibly a workshop is made up of a series of tutorials.


After initially struggling, I eventually concluded that a workshop is like teaching anything else. With clear learning goals and a structure, it's a lot easier to plan and create.

In this way, writing the workshop was a lot like writing a book. Only without an editor chasing me for progress ;)

More thoughts on this topic another day. Maybe.
Although, it has got me thinking about what I'll write next...


If you're interested in how my efforts turned out, you can see the results of them here.

Sunday, March 10, 2024

Who said it doesn't matter

That someone admitted [bad practice the business would not like to admit to] is not the issue.

The problem isn't blaming who said it.

The problem is that it is the culture. 

Trying to hide the issue or blaming someone for admitting it doesn't help. It encourages bad practice, which really only makes things worse.


 

Saturday, March 09, 2024

Detecting relevant content of interest

When AI is actually a bit dumb. 

Consider something I'm seeing a lot:
  • Content (e.g. news) app shows lots of different content.
  • You read an article in the app within a specific category.
  • Several hours later, an automated backend process tries to prompt re-engagement.
  • The backend process looks at what categories of content you've looked at recently.
  • It notices a recent article that is in that category and is getting lots of views.
  • The backend process then sends a notification about that content as you're likely to be interested. (It knows you read content in the category, and lots of people are reading this new article. It should be of interest.)
  • But the "assumption" was based on a lack of consideration for articles already read. (It was of interest, that's why you read it several hours ago.)
  • Enough people click on these notifications to make them look like they're doing a good job of promoting re-engagement.
  • People click on the notifications because they might be related to or following on from what they read earlier and not realizing that it is the exact same article.
  • Analytics only tracks openings from the notifications, not how much time is spent reading the article they were using to promote re-engagement.

Analysis of analytics doesn't flag this, and the opacity of "the algorithm" doesn't make it clear this is what's happening.
All the while, many people get wise to these pointless notifications and turn them off, and so many miss something actually useful in the future.


I know there are more complex and varied scenarios than mentioned above, including how the above could be considered a successful "engagement" in other ways.

The main thing I take away from this is that I don't want to be creating software that tries to do something clever and useful without being able to accurately tell it is being successful and providing value.
Creating something that is trying to be clever but comes across as stupid because it doesn't make wise or appropriate use of the information it already has does not excite or interest me.

Friday, March 08, 2024

Software development = basketball

This might be a leap but go with me for a minute.


"Lessons in basketball are lessons in life"

 

It's a cliched phrase that was drilled into me at basketball training camps and through basketball-related movies when I was young. We weren't just being encouraged (forced?) to learn lessons that would help us play better basketball, these lessons would help throughout our lives.


Thinking today about the importance of fundamentals, I wonder if the world would be a better place if more developers (had) played basketball.