Some of you may have heard of the magical Round Tuit. I must have been very young, 9-10 years old, and I don't remember why I was in the headmasters' office, but I don't think I was being told off (probably).

But there I was, sitting waiting for him, and as an inquisitive (and bored) child I started looking around the room. There it was, the Round Tuit - in all its glory. I had never seen one before, and once I had, I understood its power.

Tuit's are surprisingly common now, you can even find round ones on Amazon, for not much money, but, for the power it bestows on the owner, it could be a great investment (affiliate link incoming):

https://amzn.to/43atcaY

This is a round tuit. Guard it with your life!
Tuits are hard to come by, especially the round ones.
It will help you become a much more efficient worker.
For years you've heard people say "I'll do that when I get a round tuit." So now that you have one, you can accomplish all those things you put aside until you got a Round Tuit.

round tuit - Wiktionary

Wiktionary

Of course, this is all a bit of fun, and you don't need the physical object, but the idea, that you have permission to get things done, is a powerful one. Even though I don't have a physical Tuit, it's an idea I've kept with me all these years, and it's surprisingly effective.

The Tuit is a powerful and repeated idea

Getting Things Done (GTD), the much used/loved productivity method, has the 2 minute rule

“If an action will take less than two minutes, it should be done at the moment it’s defined.”

Amazon have it as one of their leadership principles "Bias for Action":

Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

We have a similar principle at BENlabs:

WHEN a decision gets made is just as important as WHAT decision gets made. Most decisions can be reversed, but time lost is gone forever. The default should always be to move forward, and to do so proactively, decisively and optimistically.

Even clothing gets it:

Just do it. - Nike

How many times do you hear...

In 1 to 1s, in conversations with your friends or family, even in conversations you have with yourself:

• Once things calm down, I will...
• When we do/have X, I will...
• I'm just going to do this thing, when that's done, I will...
• That can wait till tomorrow, I will...

etc.

Mythical future you, will almost probably also have a good list of reasons not to do the thing as well. Things will be just as complicated then, as they are today.

So, I give YOU this virtual Round Tuit. So that you too can, if you want to, embrace the Tuit, hold it tight and say - NOW is the time, Carpe Diem !

Go get stuff done.

(just like I did, and finally published another blog post)

I love Sci-Fi books, and I'm currently listening to the Expanse series (after watching the TV show). A moment in the book had me put it down, to write down what was said.

In the Expanse, there is a brilliant woman called Chrisjen Avasarala (who is also played by an amazing actress, Shohreh Agadashloo, in the TV show). She's strong, smart, powerful and all round awesome in the book/show, and last night I got to a part in the 2nd book where she said something which made me pause the audio and write it down. She said:

"A failure you understand is a victory"

This really resonated with me. I've seen this idea before, but it's nice to have a pithy one-liner to focus the mind.

At work, we talk and think a lot about "Bets", a concept we took from Marty Cagan's product management philosophy (see Inspired and Empowered books). In the books, Marty talks a lot about focusing on outcomes (not output) and on this idea of framing work as a Bet, not a task. A bet is a gamble, an investment of time to achieve an outcome. Importantly, bets can fail, and then you don't get your outcome - BUT, if your bet's never fail, then they are probably just tasks.

One of the bigger challenges for people new to this way of working and the idea of a Bet, is that they can (and SHOULD) fail now and then. Too many engineers equate Bet with an Epic or task, which needs to be a success - or they feel like they did something wrong if they fail.

There are two big problems with never failing (a bet in this context, but applies more generally):

1. Low risk = Low reward. Risk = Reward is an old adage, but holds up. So if you want big rewards there probably needs to be a chance of failure, and if a team or person never fails, they are probably not taking enough risks.
2. Low signal = Low action.  If it's only just a success, or it's unclear why it was a success - how can you use that data to improve next time? The more understanding, the clearer the signal, the more actionable the next step/change will be.

I don't want to fail, or my teammates to fail, but I want to learn, more than I want to not fail. Sometimes you have to fail to learn.  

So next time you fail, don't be disheartened by a failure, but only if you can understand WHY it failed - as then it's not a failure at all, but the basis of your next, more educated and informed attempt!

Edison himself was a famous proponent of this idea:

Thomas Edison - Wikiquote

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

I would construct a theory and work on its lines until I found it was untenable. Then it would be discarded at once and another theory evolved. This was the only possible way for me to work out the problem. … I speak without exaggeration when I say that I have constructed 3,000 different theories in connection with the electric light, each one of them reasonable and apparently likely to be true. Yet only in two cases did my experiments prove the truth of my theory

• I prepare
• I follow a standard pattern
• I share about me and the company
• I look for the positive
• I ask ambiguous and open-ended questions
• I ask for examples and absolutes
• I leave time for them to ask questions
• I enjoy it and learn from them
• I follow up

I prepare

Weeks before (takes a few hours, but very infrequently)

• I build a standard set of questions that I ask all candidates.
• I try to avoid standard questions that others will have asked them already or that the candidate may have a rote response for.
• I have a smaller set of questions I keep per role, level (experience) and speciality for the interview.
• I refine the question list as I interview, read, hear good interview questions.

Days before (takes 5–10 mins)

• I check with the hiring manager if there is anything they want me to focus on, specifically for this candidate.

Hour before (takes 15–30 mins)

• GitHubI review the CV and any other data in the HR team shared.
• I read their LinkedIn, paying specific attention to:
  - Recent companies and roles and length of time there - what have they done recently?
  - Very early experience/roles - how did they get started?
  - Recommendations given and received - what are they known for and value in others?
  - Shared connections
• I follow links they have put on their CV / LinkedIn, reviewing their personal websites, Twitter, GitHub, goodreads, etc if they share them.
• I do a basic Google search, perhaps they have spoken at events or similar.
• Skim what I find, look at the trends, the ideas, the things which may make them good for the role.
• Follow links from links, sometimes they only link to GitHub on the CV, but GitHub then links to Twitter/personal blog etc.
• I prepare and review the questions I’m going to ask, fine-tuning them to the situation and level of the candidate.

I follow a standard pattern

• It's all too easy to find a shared passion and spent 20 mins talking about it, then miss key questions you should have asked.
• By having a pattern and set of questions you use with all candidates, you have a fair and repeatable criteria by which to measure. Of course, every interview is different, but this, at least, gives you a reference point.
• I ask them to be concise in their answers. Communication is critical to any role, I personally highly value people who can communicate a lot in a little time. It shows clarity of thought and resect for others time.
• I explain to the candidate how I like to interview, and the pattern I follow. Mine interview flow is:
  1. Explaining the pattern/flow.
  2. Short intro from me, about me, what I do, what i value and who I am outside work (2-4 mins)
  3. Short intro from them, ask for things not in the CV or key/defining parts of their CV (4-6 mins)
  4. We go through my set of questions, with a focus on being concise. (20-30 mins)
  5. Time for them to ask me, absolutely anything.
• The questions section is semi-dynamic, once the interview is going - removing questions which are no longer relevant or adding them as needed.
• I also ask the same final question, regardless of how the interview has gone: “If we were to make you an offer, what is the first nagging doubt or hesitation which pops into your mind.”
  - It lets you know how to tune that offer, if you want to make it.
  - It lets you set any concerns to rest (or prep the next interview to do so)
  - It can highlight gaps in the interview process up to this point.
• Perhaps most importantly, I take notes as we go. If you are doing a lot of interviews or over a long period of time, it's easy to forget exactly what was said.

I share about me and the company

• Sharing who I am are, and what your motivation is, is a key part of the interview.
• Going first, with your introduction, being open and forthcoming sets the tone for their introduction and the rest of the interview.
• It's them interviewing you as much as you are interviewing them.
• One of the questions I ask EVERYONE is, “how long did you take researching the company and what did you find out?”
• I then ask, do they have any questions about the company, which I can answer for them.
• I do this as one of the first questions, as it gives us both context for the rest of the interview.

I look for the positive

• Some interviewers are looking for reasons NOT to hire someone, or to find fault - I look for their strength.
• Ask questions that let them show you what they are good at, what they love, what they find interesting.
• Look for ways they are different to you and the team they are joining, to find how they will add to the team, raise the bar - which isn’t always the same as fitting in.

I ask ambiguous and open-ended questions

• The question they hear/understand and choose to answer, can be as informative as the answer they give (sometimes more so).
• When faced with ambiguity, do they ask clarifying questions, or just jump into an answer?
• Are they able to be concise when faced with an open-ended question?
• I try not to ask questions with a right or wrong answer, instead try to ask questions which show me how they think and what they value.

I ask for examples and absolutes

• People learn the “right” answers to interview questions, by asking for examples from their experience, you can tie it to something real.
• They want to be right, so will often hedge their response, which doesn’t tell you what they really think - so ask “Are you better at X or Y, you don’t get to pick both”, “please stack rank these things”. The rational they give and thinking behind it is often more important than the absolute answer.

I leave time for them to ask questions

• What they ask, is almost as important as what answers they give.
• If you’ve set up the interview well and been open and forthcoming, the questions you get here can be insightful not only for the candidate, but also your interview and the process that went before you.
• Leave time for this - but also don’t make them feel bad if they don’t have questions (have some prompts ready).

I enjoy it and learn from them

• A cheat I’ve used in the past, is to ask “what's the best interview question you’ve ever been asked” to help me fill out my set!
• They will know things, have experiences, ideas and passions you’ve never come across before, look for that.
• You may never speak to them again, or you may be setting the foundation in this conversation for a relationship which goes on for many years - in both cases, have fun.

I follow up

• We submit our review via an online system, but I always make sure to reach out to the hiring manager and recruiter to give a personal response and answer any questions they may have.
• I also note down my personal reflections, there and then. It's very easy to have your impression changed when you start talking to others or as time passes (which may be ok), so it's useful to capture it.
• I will often also reach out to the candidate, to say thank you and share any links or other things we discussed, or ask for links from them. It's often just TV shows or interesting technical ideas we talked about.

Ultimately, interviewing is a chance for you to get to know someone new, so take that chance. You never know, this could be someone you spend the next 10 years working alongside, or bump into again in another context - so it pays to make the effort.

Lots of interest in ChatGPT, so much they are having to scale up their services. Lots of fascinating experiments, making it write code, pass exams/challenges or write scripts. It's extremely impressive.

I made a post back in July about GPT-3 being able to pass basic technical interview questions. It seems like ChatGPT has turned this up to 11.

But. (its a big but). The important thing to remember, is what while ChatGPT may generate very real looking text, answers and code, the things it's saying are made up (which is what it was made to do). And, some of the things it makes up are wrong.

The challenge here, is the things it's generating can be technically and semantically correct, and sound extremely plausible - they can have huge factual or implementation errors which are very hard to spot unless you already know the correct answer.

As an example, try asking what it knows about your home town, or about a team/historical event you know well. It feels like some kind of uncanny valley, but only if you know the domain/truth.

I for example asked "What do you know about Beaconsfield", which is a town outside London, where I have spent a lot of time.

ChatGPT said:

"Beaconsfield is a town in the county of Buckinghamshire, England. It is located about 25 miles (40 km) northwest of London. The town is named after the beacon field that was once located there, and it is known for its historic buildings and picturesque setting. Beaconsfield Old Town, which is the historic center of the town, is a particularly popular attraction, with its cobbled streets and well-preserved Georgian and Victorian buildings. The town is also home to several notable residents, including the Prime Minister of the United Kingdom, Boris Johnson, who has a home in the area"

Breaking the response down:
✅  "Beaconsfield is a town in the county of Buckinghamshire, England"
✅ "It is located about 25 miles (40 km) northwest of London."
❌ "The town is named after the beacon field that was once located there"
❌ "with its cobbled streets"
❌ "Boris Johnson, who has a home in the area"

Without knowing the area (or looking it up on Wikipedia/google street view) you would very easily believe the false claims the AI is making. Everything it said seemed reasonable, it was only the "cobbled streets" that caught my eye and made me investigate the other claims.

Which is scary, as the lies seems so plausible. I lived there for years and had to check, as I didn't trust my own memory. Yet the AI was able to stitch together something which feels real, feels based on concepts and ideas which could be right, Beaconsfield is exactly the sort of place that would have cobbled streets, where Boris Johnson might have a home -  but it's just not true.

I tried it with a few other towns too, very similar results, core facts right but believable half-truths or embellishments around the side. Like an author writing about a place but without ever going there (or having the internet to check against).

It is a hugely impressive tool, which is going to take a while for us to appreciate and learn how to leverage, but I caution you not to trust anything it tells you, as it seems to have a habit of spinning a convincing yarn.

(no part of this post except where quoted was written by an AI - but then again, that's what an AI would say). Happy playing.

If you work with several teams, ask yourself, what team is your top priority? You may have an idea which pops to mind. Pause on that, perhaps write it down.

This is a 2.5 min video (yep, it's really short, watch it), that asks exactly that question:

Now re-consider your first answer. Interesting, right? Is your answer still the same? The real question is: What are you going to do with this information/insight?

This video made me consider if my investment of time aligns with priorities. I agree with the video, my peer group (in my case, other senior leaders) is my most important team, but am I investing the time and attention into that team correctly, or are other groups taking more of my time?

So I checked and was surprised by the results.

I looked back over the first 2 weeks of October (I track my days in Outlook and LogSeq), and counted in 30 minute chunks where I was spending my time.

It broke down, broadly, like this:

• 40% not in meetings! (This was higher than I expected, and higher than it feels like most weeks! No Meeting Friday really helps!)
• 20% in meetings with the wider business
• 20% (an average of 5% x 4) in meetings with direct reports/teams they are on.
• 10% in meetings with the wider tech org and non managed teams
• 10% with my cross-functional peers (this is my #1 team)

Which lead me to ask myself:

• Are these percentages what's best for the business?
• Are these percentages what I want?
• Do I really have 40% of my time not in meetings?

How do your numbers stack up? Have you ever checked?

Almost regardless of what the actual percentages are, having the data and asking the questions, is giving you an opportunity to have interesting discussions with the people you work with and calibrate how you are spending your time - which feels like it can only be a good thing.

You are going to love this. Please try it.
The important bit is the sauce, and it's so simple that it feels like you found a deliciousness cheat code.

Sauce ingredients:

• 3 tbsp - Tomato Ketchup
• 1 tbsp - Soy Sauce
• 1 tbsp - Minced garlic
• 1 tbsp - Gochujang (the magic)
• 1 tbsp - Strawberry Jam (yep)
• 1 tbsp - Honey

Directions:

• Measure it all out into a pan (except the honey)
• Mix it up
• Cook on medium heat till it bubbles / gets smelling nice (1-2 mins)
• Add the honey
• Mix again
• Add your crispy chicken wings (hot) or crispy chickpeas or probably cardboard, it will still taste amazing!
• Mix and coat in the sauce, more coating the better (2-3 mins)
• (optional) Bake/Air fry coasted food for another 1-3 mins
• (optional) sprinkle with sesame seeds

ENJOY!

So easy and so good. You can be more fancy, I expect you could use the sauce in all sorts of ways - but for me, it's so amazing this way, I've not tried anything else!

You can see the original recipe and more background on how it was developed in this YouTube video by Food52 or on their website (also linked).

https://food52.com/recipes/87478-crispy-yangnyeom-chickpeas-with-caramelized-honey-recipe-eric-kim

One of my favourite William Gibson quotes (but exactly when he said it isn't clear).

The future is already here — it’s just not very evenly distributed yet.

It gets more and more true each day. Take the amazing ability for computers to build images from text prompts:

• January 2021, DALL-E was revealed by OpenAI in a blog post
  - People with access? 100's at most?
• July 2022, DALL-E 2 entered into a beta phase with invitations sent to 1 million waitlisted individuals.
  - People with access? 1 million
• July 2022, MidJourney entered open beta, anyone was able to join in and try it out.
  - People with access? Early adopters, but limited credits/pay per use
• Late August 2022, Stable Diffusion releases code and model weights
  - People with access? Most engineers (with python skills + determination)
• Early September 2022, single click installers for Stable Diffusion become common place.
  - People with access? Anyone with a modern pc and a passing interest

I probably missed a lot with the above, but the point is how fast things are moving from the lab into every technical person's hand.  These last few months have been huge, the sheer number of images being created is mind-blowing. And the images are good, in some cases winning art competitions.

The code being on your own computer, no quotas, nothing to sign up to, nothing stored on the cloud - it's freeing, it lets you experiment. The cost per experiment till this point was an opportunity cost, if I try this, I might not be able to try another idea later. It stopped me playing.

But now, with it installed locally, the only cost is time (and a bit of fan noise/electricity). I've already generated over 100 in the last 24 hours, just casually messing about! By comparison, I think I made under 10 across a few months with DALL-E and MidJourney.

Do you want in? Getting your own AI artist is easy!

• Mac M1/M2 - https://www.charl-e.com/

CHARL-E • Make art with AI on your Mac

Make art with AI on your Mac

• Windows / Linux - https://github.com/cmdr2/stable-diffusion-ui

GitHub - cmdr2/stable-diffusion-ui: A simple 1-click way to install and use Stable Diffusion on your own computer. Provides a browser UI for generating images from text prompts and images. Just enter your text prompt, and see the generated image.

A simple 1-click way to install and use Stable Diffusion on your own computer. Provides a browser UI for generating images from text prompts and images. Just enter your text prompt, and see the gen...

GitHubcmdr2

Or find any number of other one click solutions (new ones springing up all the time):

Let Me Google That

For all those people that find it more convenient to bother you with their question than to google it for themselves.

LetMeGoogleThat.com

Writer's block?

Writing prompts for AI image generation is a skill all of its own, there are keywords you can add to get the results you might want. But even just having the inspiration for what to create can be a challenge (unless you have small children on hand, they are FULL of ideas).

Luckily, someone already thought of this, https://lexica.art/ is a search engine for over 10M+ Stable Diffusion images and critically, as well as the image, they stored the prompts which generated them.

A database of 10M+ images is a huge number an impressive resource on its own - but now consider how long Stable Diffusion has been available to the public - just a few weeks!

This HUGE database of content, which took only few weeks to generate, makes me wonder about business based on licencing image based content; but I have no doubt video and audio will follow.

It is not just content licencing business which are at risk or affected by this new, world of fast and easy AI art - "real" artists are up in arms that their digital forms, networks and meeting places are being buried under a tsunami of digital art and are trying to ban it.

Online Art Communities Begin Banning AI-Generated Images - Waxy.org

Online art communities have started banning AI-generated art, while others are facing public pressure from their own members to take a stand.

Waxy.orgAndy Baio

What's next?

Creatives are only just starting to see what they might be able to do with this tech (which is itself still in its early stages). And, for me, the amazing part of all this is the means of production is getting into everyone hands, thanks to open source!

With the pre-trained AI tools, with natural language interfaces, and easy to install deployment - the cost of experimentation and failure is basically zero, and so are the barriers to entry. I don't see this trend going anywhere - and the fight against it, I suspect, is a loosing battle, as it was with digital photography.

Just thinking about what the digital camera did for photography, or YouTube for video distribution makes me think that AI based creations tools are set to disrupt and decentralize even more types of content, only much, much faster.

My kids will have a blast playing with this.

Here is a good summary by "HUGE* if true"

For the lighter side - I also recommend John Oliver and his love, a cabbage

I'm a big fan of On Opinion, a podcast about the way we think, by a company (Parlia) who is trying to map the world's opinions.

The latest episode of the podcast was all about how our "stone aged brains" are not optimized for our current environment and the challenges the old hardware causes, along with some insightful ways to counteract them.  

Our Stone-Age Brains, with Maren Urner - Parlia

We have stone-age brains, which last evolved many thousands of years ago, and are no longer suited to the challenges of ...

Parlia logoParlia

Maren Urner (German neuroscientist, professor and author) goes into fascinating detail in her conversation with Turi Munthe (the host, and my former CEO at Demotix) about this topic.

They cover a wide range of ideas from why or brains are as they are, negativity bias, tribes, how to change, way to thinking, pseudo-dichotomies, and even if we are fit to vote. I highly recommend listening to the episode (and subscribing to the podcast), but wanted to pull out just two interesting things I heard and that got me thinking (a lot).

All decisions are based on emotion?

The idea breaks down like this:

• Decisions are about preference - picking between options is only possible when you have a preference.
• Preferences are based on values - how much you like something is based on your value of it.
• Values are based on emotions - how much you value something, comes down to how it makes you feel.

So this means there is no need to differentiate between rational/emotional decisions - it's all the same. And it's all from the brain, but it not about logic, it's about feelings.

Yet oddly, when we talk about feelings, language puts feelings as originating in the heart. It's everywhere. Maren does something very thought-provoking, replacing "heart" in language with brain, when it comes to decision/thinking.

• Heart of the matter ➡️ Brain of the matter
• Heat felt ➡️ Brain felt
• Heart break ➡️ Brain break

Fun right? Puts a new spin on things. I think there could be a temporal aspect that's missing here, how fast you make the decision and how quickly the decision is linked to the emotion - but it was a fun one to try and grok.

A defence against deficient hardware

Thinking might help us get past the problems with thinking.

Maren discusses an idea called "Dynamic Thinking" as 3 principled preventative, to counterbalance some of the stone aged mental models we have. It's also an important part of Constructive Journalism, which is worth exploring in its own right.

What is Constructive Journalism - Definition - Models - Meaning

Constructive journalism is a response to increasing tabloidization, sensationalism and negativity bias of the media and offers an add on to news coverage.

Constructive Institute

The 3 principles of Dynamic thinking are:

1. Ask “what for” not “against what”
   Framing a conversation, debate or idea around what we want to do, instead of want to avoid, gives you a path to a solution.
   It's a future-oriented perspective, which engages our most valuable mental tool - our imagination. What could be?
2. Redefine how we make groups
   Tribalism is rooted, perhaps even defined by being exclusionary, making belonging a function of not being like the "others".
   Instead, define groups by how things in them are similar, how they are alike, how they are connected.
   Doing this will foster trust inside the group. If we are connected, we listen longer, trust more - while not seeding distrust of those outside it.
3. Different stories, switching our focus from the individual to the collective
   How do we really function? We over index on the power, agency and impact of the individual and undervalue those values of the group.
   We all depend on the systems and groups around us, we all stand on the shoulders of giants. Yet, even that quote feels like it's promoting the great man (or person) theory a bit too much.
   I love the concept that it's much more a case of "I am because we are" (Ubuntu), and we all should keep that in mind more!

I think applying dynamic thinking could be hugely impactful and beneficial in many areas of my personal and work life. I've already started to think how I can use these principles when considering:

• Coaching and 1 to 1's
• Product market fit and exploration
• Parenting

As you might be able to tell, I got a lot out of this latest podcast - If you read this far, you might too, go on, go download it - I hope you enjoy it.

A few weeks back, a very interesting LinkedIn post hit my feed by Jacob Singh and Dhruv Baldawa. Jacob and I were in similar circles back when we both worked with Drupal.

This is the post:

How to start a product engineering platform team

(x-post from https://jacobsingh.substack.com/p/how-to-start-a-product-engineering) As startups evolve, their org structures must evolve to match the evolving needs of the company. Cross-functional product teams give way to matrixed shared services teams w/ and eventually to internal product orgs aka…

Jacob SinghJacob Singh

The post was mostly about platform teams (and very useful for that), and made many interesting points and observations (really, go read it!), but there were two parts which I wanted to highlight as specifically interesting.

Priority is a singular noun.
This rang true to me.  The post frames the situation brilliantly, so nothing more to add, than I've seen, more than once, complex refactors or re-platform fail or take longer than they should, due to not respecting this principle.

But the more though provoking one for me was:

Rotate.
This one was tricky, initially I disagreed. Should we really be rotating team members around between teams? Team Topologies and Empowered both seemed to say a similar thing: create a stable team of autonomous, empowered people and flow problems to them.

But, the post backed it up its claim with a reference to one of my favourite laws, Conway's law.

Failure to do this will ensure Conway’s law trips up your best laid plans.

This got me thinking, as I thought I knew the law and its implications. Conway, in my mind, had always been about structure, that the organization's structure would dictate the system's structure.
But I was glossing over a key word:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway

Communication. It's not the organization's structure that's most important, it's the COMMUNICATION structure. Formal/team structure is clearly critical, but the nuance is around how information flows.

Even if you have 2 or 3 database teams, if all decisions and discussion are channelled to a single PM or EM, you practically have a single team. You also have a single point of failure.

So I can now see why rotating team members can be a preventative to Conway's trip ups. To project against theses sub-structures/communication paths, disrupting or delaying your best laid plans. It also gives you fresh eyes without fresh hires and can help permeate best practice throughout the organization.

The cost, of course, is the organizational churn, re-storming/forming/norming/performing. But in small doses, that could be a cost worth paying.  

CoPilot, the AI pair programmer by OpenAI and GitHub/Microsoft, is generally available, I've been very slow in trying it out and so far have recommended our developers DON'T use it on our internal codebases due to IP and concerns (see end).

But, you can play with the same system, to test it, without giving it access to your IDE or internal codebases, just by signing up to OpenAI's Playground - where you get $18 of free credits to ask questions of this huge AI model.

So, I did. I fed it a few typical JavaScript interview questions and was impressed by the results:

Create a React component which lets you up and down vote, with buttons, and keeps a running total of the number of up and down votes.

class UpDownVotes extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      upvotes: 0,
      downvotes: 0
    }
  }
  
  upVote = () => {
    this.setState({
      upvotes: this.state.upvotes + 1
    })
  }
  
  downVote = () => {
    this.setState({
      downvotes: this.state.downvotes + 1
    })
  }
  
  render() {
    return (
      <div>
        <button onClick={this.upVote}>Up Vote</button>
        <button onClick={this.downVote}>Down Vote</button>
        <p>Upvotes: {this.state.upvotes}</p>
        <p>Downvotes: {this.state.downvotes}</p>
      </div>
    )
  }
}

Not bad! Let's try something a little harder:

Create a javascript function SimplePassword(str) take the str parameter being passed and determine if it passes as a valid password that follows the list of constraints:
1. It must have a capital letter.
2. It must contain at least one number.
3. It must contain a punctuation mark or mathematical symbol.
4. It cannot have the word "password" in the string.
5. It must be longer than 7 characters and shorter than 31 characters.
If all the above constraints are met within the string, the your program should return the string true, otherwise your program should return the string false. For example: if str is "apple!M7" then your program should return "true".

function SimplePassword(str) { 
  if(str.length>7 && str.length<31){
    if(/^[0-9a-zA-Z!@#$%^&*()_+\-=\[\]{};':"\\|,.<>\/?]*$/.test(str)){
      var pass = str.split("");
      var hasNum = false;
      var hasLetter = false;
      var hasPunc = false;
      for(var i=0;i<pass.length;i++){
        if(/[0-9]/.test(pass[i]))
          hasNum=true;
        else if(/[a-zA-Z]/.test(pass[i]))
          hasLetter=true;
        else{
          hasPunc=true;
        }
      }
      if(hasNum&&hasLetter&&hasPunc){
        if(str.toLowerCase().search("password")==-1)
          return true;
        else
          return false;
      }
    }
  }
  return false;        
}

Yep, ok. What about a theory question?

What do you understand by Closures in JavaScript?

A closure is a function that makes use of variables defined 
in outer functions that have previously returned. 
In JavaScript, closures are created every time a function 
is created that uses variables from outside its scope.

Or a question about what NPM modules to use?

Which npm modules would you use to manage a database schema?

There are many npm modules that can be used to manage 
a database schema, but two of the most popular are 
sequelize and knex.

Ok, let's dig into that:

What are the pros and cons of sequelize vs knex?

There is no definitive answer to this question as it depends
on personal preferences and opinions. Some people may prefer
sequelize because it offers more features and is better suited
for larger projects, while others may prefer knex because it
is simpler and easier to use.

It's not just code, it can answer questions about git

What does the following command do?
git diff-tree –r {commit hash}

The command git diff-tree –r {commit hash} displays the
differences between the commit with the given hash and
its parents.

or deployment strategies

What deployment strategies do you know and have used before? How can a company deploy with no downtime?

There are a few deployment strategies:

1. Blue/Green Deployment: With this strategy, you have two identical
production environments. You deploy your updates to the environment 
that is not currently serving traffic (the "green" environment), and 
then once the updates are deployed and tested, you switch traffic over
to the green environment. This ensures that there is no downtime, as 
users will always be able to access the site/application.

2. Canary Deployment: This is similar to blue/green deployment, but 
instead of having two identical production environments, you have a 
production environment and a staging environment. You deploy your 
updates to the staging environment first, and then if everything looks 
good, you deploy the updates to production. This ensures that there is 
less risk, as you can test the updates in a non-production environment 
first.

3. A/B Testing: With this strategy, you deploy your updates to a small 
subset of users first, and then if everything looks good, you deploy the 
updates to all users. This helps to reduce the risk of deploying to all 
users at once, as you can test the updates with a smaller group first.

4. Rolling Deployment: This strategy involves slowly rolling out the 
updates to all users, rather than deploying all at once. This can help 
to reduce the risk of deploying to all users at once, as you can make 
sure that the updates are working as expected before deploying to all 
users.

It wasn't perfect, it missed parts of questions, it got confused when I used longer and more intricate problems - but over all, it would not fare badly against most entry level or even mid level candidates!

BUT. As mentioned, it's not all magic and rainbows - there are some serious questions about the ownership and licencing of the code it generates; like this one

and this one

and this one

Can AI learn from any public code online?

A question of fair use

The VergeDave Gershgorn

and this one

Is Github Copilot safe privacy wise? · Discussion #7163 · github-community/community

Hi I'm sure this is a stupid question and someone else probably asked it. But is Github Copilot safe to be used on private projects/repos. I'm sure you collect prediction analytics but that...

GitHubgithub-community

But...

Would you hire GPT-3 instead of a developer?

GPT-3 is not a developer, so it cannot be hired to do development work.

...but for how long?

And that crazy image at the top, that's another OpenAI (DALL-E) model, which instead of generating code/text, creates images. The image was inspired by the prompt "An AI doing a coding exam" and created using the NightCafe service. Its using DALL-E v1, and there is already a v2 out.

I had the privilege of presenting at https://london.theaisummit.com/ the headline AI event of https://londontechweek.com/ on behalf of https://ben.productplacement.com/.

It was a hot summer's day in London and the event was full of interesting people discussing AI and related technology. The day before, two of my colleges at BEN (Tyler Folkman and Jeff Barlow) had presenting how we are optimizes flows and technology to bring AI models from the lab into the real world.

My presentation was about how we have been using AI to help creators and brands work more successfully together, as when it works, it really works. The presentation covered:

• The huge opportunity of the creator economy and community
• Common challenges faced when trying to work with brand and creators at scale
• How AI helps with these challenges
• Case studies of where AI models have made huge impact

Reach out to me directly if you want more details.

A few highlights from some of the talks I attended:

• UK Ministry of Defence, discussing AI policy
• Round table with Deloittee about AI regulation
• TII presenting how they trained an GPT-3 Model, called Noor to process Arabic  and tracked its carbon footprint
• Shutterstock presenting how they used their huge library of image data to build new AI models.
• A fireside chat with John Lewis partnership on how they grew internal capabilities and talent around AI.

As well as the AI summit, there was also a Quantum Computing summit, while generally, as soon as someone mentions "Quantum" I hear "magic" and due to how often it's used by pseudo-science, this was different. Fujitsu had a stand, which for the first time made me Grok not only the potential but also the practical implementation of Quantum:

Fujitsu Shows Off Its Quantum Arcade Game But Also Demonstrates How It Is Generating Quantum Value For Its Clients Such As HSBC | Quantum Zeitgeist

We love games, especially quantum games. At the latest UK Quantum Summit, we saw the impressive stand from Fujitsu which aimed to showcase the work that the Japanese giant has been doing in the quantum space with the likes of household names such as HSBC.

Quantum ZeitgeistRusty Flint

It's still 5-15 years out, but Shaw's algorithm is coming,  qubits are expected to follow something like Moore's law, so be ready for your public key encrypted data to be plain text in your lifetime.

It was good to be back, to be part of a conference, a community, a sense of excitement - bring on the next one!

I'm really lucky to be able to work for a company that creates tools that are useful to me personally. In this case, TubeBuddy - an excellent suite of tools and community to help YouTubers become even better YouTubers.

When I first started using TubeBuddy was back when I was doing due diligence on the company that my employer was considering acquiring. I used a friend's account (thank you Invalid Entry) as I didn't have one and leveraged the tools to manage and optimize videos. It was really impressive, I liked the product and the team was great too! The rest, as they say, is history.

I've kept helping Invalid Entry, but late last week I made the first video public on my own channel, which, of course, was enhanced using TubeBuddy!

The video above was uploaded on behalf of another friend (a filmmaker called Stuart McKean who lives close to me). I promoted the video on Facebook, used key wording tools, and followed the best practices outlined by TubeBuddy, and with a lot of help from Stuarts excellent content, the video (sorry FILM) has gained a lot more views than I or Stuart were expecting,  and also gave me an even deeper appreciation of the joy and motivation of YouTubers.

OK, it's not a lot by big creators standard, but from a zero subscriber standing start - I'm very pleased. I've even got certificates to prove it!

I can't take any credit for the amazing features above, they were built before I was involved with TubeBuddy, but, excitingly for me, I was able to use a brand-new feature which was built after I got involved - Chapter Editor!

Chapter Editor makes adding chapters (which I really appreciate, as a YouTube consumer), very easy. I'm immensely proud of the tool the team made, it does one thing, does it very well. So thank you team.

It's so exciting to see the joy and impact a single film (or feature) can have - the feedback and comments have been wonderful on both the film and feature. The filmmaker, Stuart, is very pleased so many people have been able to enjoy his hard work. The team too has been excited by the reception of the feature.

So thank you, BEN, for the opportunity of working on interesting problems with great people, TubeBuddy for the amazing product and most importantly Stuart McKean for the content!

This dog food tastes great!

(also we are hiring)

Earlier this year, once it was safe to do so, some of our teams got together in Portugal. It was an amazing opportunity to get teammates who had been hired during the pandemic and/or worked remotely to each other (across cities and countries) to get together.

I had a single goal for the entire trip, not a new product, not adoption of new tech, not even anything directly business related, it was trust. If all we did for that week, was got to know each other better and increase our trust in each other and the teams - that would be a huge win. Trust helps you assume positive intent, which is really important when working as a team.

Because:

"that in order to understand what someone is telling you, it is necessary for you to assume the person is being truthful, then imagine what could be true about it."
― George A. Miller (1920–2012), Professor of Psychology at Princeton University.

(Miller is also the 7 +/- 2 things on working memory guy https://en.wikipedia.org/wiki/Miller's_law)

I came across this idea, that there are two types of programmers - builders and solvers on a Reddit thread and I found it thought-provoking so wanted to share it with you:

I’m going to generalise somewhat wildly here — and there are no doubt exceptions and overlaps — but in my experience there are two distinct groups of programmers:

Solvers, who typically like games, puzzles, chess, math for its own sake, and mathematical challenges.

Builders, who typically like mechanics (cars, motorcycles, bicycles, etc.), electronics, carpentry, plumbing, art, and often music-making

I suspect Solvers are more inclined to take interest in LeetCode and the like. Builders, not so much.

Notably, neither group makes for better programmers than the other — though they may take wildly different approaches to implementing solutions — and a strong team consists of both.

I’m definitely in the latter category. I find LeetCode — and puzzles in general — insufferably dull and pointless. But I appreciate that others love LeetCode and puzzles.

Different strokes for different folks.

The original author was Dave Voorhis, on Quora - https://www.quora.com/Why-is-LeetCode-so-hard/answer/Dave-Voorhis

My thoughts

It's not the only way to define or group programmers, obviously, but it's an interesting lens, when thinking about team dynamics, promotions and hiring.

Some questions that come to mind:

• If you put a LeetCode gate on the front of your hiring, you could be filtering out or even discouraging highly talented and valuable devs. Do you want to do that?
• Does your personal alignment impact your ability to assess/judge the skills of the other kind of developer? Do you prefer working with / hiring solvers or builders?
• What does your current team makeup look like, what does your product or team need to succeed?

For years, I've been asking a similar question during interviews, which was trying to get to the same root. I ask, "would you consider yourself to be a results or detail oriented person? Why? (And you don't get to pick both)", I'm not trying to trip you up, I really want to know, as it will help me see what problems, tasks and teams you might gravitate towards. But perhaps I should replace it with the Builder vs Solver question.

Diverse teams are stronger, which I expect applies to builders and solvers too.

TL;DR;

The Live Share plugin for VSCode lets you share your IDE over the internet as easily as you share your webcam and camera (e.g. Zoom).

Live Share lets you concurrently edit a file with anyone. But it also goes further, share ports, console access and access to ALL files in the project on your local disk.

It's even better than them being sat next to you sharing your keyboard and mouse, as with Live Share they can concurrently edit the file you have open, or any file in your project! Oh, and works standalone, in the browser too, so the other person doesn't even need VSCode installed.

Go install it. And/or read what Microsoft say about it.

Longer version

I'm proud to be able to say that I've worked remotely for most of my professional career. Full time remote work can be an acquired taste and isn't for everyone, or without its challenges. But I really enjoy it.

One of the biggest challenges is collaboration, how do you work with people who are not physically right next to you? Fortunately technology has been there to help, from the early days of Telegrapthy, to bulletin boards and FTP, to SVN, to GIT, to Slack, to Zoom - and everything in between. Technology has been ever improving the way we are able to make and do things without being in the same room.

For me, there have been a few game changer moments in remote working collaboration, over the years, these are a few of mine:

• Going from FTP/Shared folders to any kind of Version control. No more "oh no" moments. Branches and merges made it possible for lots of people to be working on the same code without making a huge mess.
• IRC and later Slack. Real-time and asynchronous, group chats with  searchable history with developers from around the world, coordinating efforts on your project or just hanging out to talk about the latest tech news.
• Skype and then Zoom. Voice and Video calls with high quality, multi person conference calls. It made working with a geographically diverse team much simpler - everyone and anyone is only a click away from a team meeting or 1to1.
• Screen sharing, and drawing on screen with Google Hangouts or Zoom. Seeing what people are working on, the code running, the missing semicolon or rouge variable and being able to highlight / point to things. This allowed for pair programming and more often rubber duck debugging, in a way just webcams/microphones did not.

But concurrent editing has been missing. Yes, Google doc has it for documents, and you can do ugly/hacky things using private Etherpad, but true pair programming has always been really clunky.

Until now. I had tried Live Share, or things like it a few years ago, it was painful. Now it's as simple as clicking a link, then pasting a URL to someone - that's it. Could this be the next game changer moment?

Go try it!

Or see it in action below: