Blog.Danielboyle.net – Page 2 – I like to make things.

Family Cooking, Part 2

Following up last night’s experiment, here is what I accomplished in one hour of wireframe. I focused on a single core flow – defining who is cooking the meal and how it could work. If you like this idea and can pull it off, you have my permission to steal this idea. Just do a good job and give me credit.

Wireframe: who is cooking? — Assuming the user has already found a recipe or built a meal and is ready to start cooking, we ask them to select who is cooking or add a new cook.

Wireframe: Add a new cook — A new user will need to upload/select an avatar, provide a voice sample (so the app can determine which spoken command refers to which set of instructions), and details about what this person can or cannot do.

Wireframe: Select the new cook — We return to the selection screen with our new cook ready to go.

Wireframe: Recipes — The app is now in ‘cooking’ mode. Each user gets their own timeline and their own single instruction. Terms that can can trigger additional interaction (such as whipping egg whites to “soft peaks”) are highlighted, and basic touch commands are available.

Wireframes: Speech controls — We want to support voice controls as much as possible – to save time, keep your device clean, and generally allow multiple users easier collaboration. This isn’t an exhaustive list, but here are a few theoretical commands for this step: Go forward or back a step, give me more information, re-read the current instructions, or stop until I can get help from someone else.

This is a bare shell of a small feature-set within the apps. But, I think it shows the potential of re-thinking how we consume recipes and cook with our families and I hope that something like this arrives in the future.

2 Hour UX: Family Cooking, Part 1

Timekeeping: My initial notes and sketch stayed within the one hour time limit, if you ignore the fact that my Wacom tablet and Photoshop had a disagreement that required troubleshooting and a reboot. I spent another 30 minutes or so typing this up.

The basics of a recipe app are pretty well defined at this point. Virtually every one contains a list of recipes, with the ability to search, sort, filter, and favorite. Each recipe contains an ingredients list and the steps needed to create the dish, and most include photos and secondary data such as tips, timing, and common substitutions. They’re literal digitizations of your parents’ or grandparents’ file of recipe cards. The better apps offer digital-native features, such as the ability to generate shopping lists and may have a video of someone following the recipe, but those are the exception.

Let’s think of some scenarios for a family cooking app that takes full advantage of a digital platform, specifically an iPad. Knowing how my family cooks, and others cook, there are a few common scenarios that occur:

First: the “rushed parent” scenario. I have little time, and only the ingredients on-hand to create a meal. This is largely solved by a large recipe database and good filters.

Second: I’m the primary cook, and I’m preparing a meal with multiple dishes. At the extreme end, this is someone preparing for a large family’s holiday meal. Multiple dishes need to be prepared in a sequence that allows me to make the best use of my time.

Third, I’m the primary cook, but I have a helper in the kitchen today who is less adept. I need help dividing the tasks appropriately so they can be a part of the meal without putting themselves (or the meal) at risk.

Persona Spectrums

Meal complexity

No, meals aren’t people, but let’s create some axes anyway:

Single dish vs multiple dishes
Single session vs a multi-day affair

Personal Comfort

How comfortable is the person in their ability to successfully cook this recipe?

I’ve never cooked before
I’ve never cooked this recipe before
I cook this recipe regularly

Ability

Is the cook capable of doing everything?

I have no limitations
I don’t know how to do something
I can’t do something…
- …because my hands are full (or covered in something)
- …because I have a physical limitation (such as someone with arthritis kneading dough by hand)
- …because it’s not safe for me (a young child using a knife or stove)

Attention span

How much mental power can you devoting to cooking?

My full attention
I’ll have the occasional interruption
- A knock at the door
- A crying child
I will be constantly interrupted
- I have ADHD, or am otherwise not ‘neurotypical’
- There’s a lot going on around me

Problems

Because most recipe apps are little more than a collection of text files, they can’t handle these problems well. It’s assumed you’ll read and absorb the recipe ahead of time and make sure you’re planning things out in advance. Additionally, recipes themselves are often written to encourage you to do large amounts of prep work up front, regardless of if it’s a quick stir fry (where this is important) or a slow braise (less so).

They also lack common definitions. If you’re a new cook, you probably don’t know the difference between a simmer and a boil, and if it’s your first time baking bread, do you know how to knead dough?

It’s easy to get lost in the steps if you get distracted for any reason, largely due to the design to optimize for page count even if you’re not printing the recipe.

New requirements

As a part of the app, allow for the creation of users who may have different skill levels or specialties. Each recipe must be broken down into steps, with metadata for each step that denotes what is required for that step from prep, skill, and equipment perspectives. Allow for the combination of recipes into a meal.

Use those three pieces (distinct users, step metadata, meals) to create a step-by-step flow that focuses on appropriate division of labor and just-in-time prep. Thing about it as Lean Cooking or Agile Pastry.

Within the presentation layer, ensure the timelines are built so that no user can get too far ahead, and that the display is limited to only what is necessary for that step. Imagine a “presentation mode” for a recipe where each step is one slide.

Assume that the user cannot touch the device with their hands. Any action – whether it’s to go to the next step, get info, or start a time, will be voice-accessible in this mode, by any user.

Family cooking app: partial flow — I’m illustrating a partial user flow. The user can search for recipes and add them to a meal, or select an existing meal. After confirming who is cooking, tasks are divided into two parallel streams that allow each user to proceed independently until they reach a break point.

2 hour product: Introduction

I’m trying a new strategy for generating and exploring experiences, based on the idea of speed painting – a part of the warm up and exploration process of artists where they strictly time-box themselves and try to generate a larger quantity of work at lower fidelity, and not worry about specific executions later.

If we’re being honest, it’s glorified sketching.

If we’re still being honest, this is also pretty similar to the idea of a whiteboard challenge that designers are given in interviews. That’s ok, though.

My goal is to regularly explore product ideas that bounce around in my head, and experiment with different techniques, such as Persona Spectrums that I find interesting. I’ll take 1 hour to work through definition and discovery, and another hour to put that into wireframes. If I like the idea, I may continue my explorations into actual mockups or prototypes. My first idea? A family cooking app for the iPad. I’ll spend 1 hour on each of the next two days, and see where I get.

The interview process

The reality is no single interview format is perfect. Someone has a bad day. They’re too easily faked. They are problematic for people who aren’t neurotypical. They test the wrong things. They’re not respectful of time. Passion isn’t the same as skill.

Look. Interviews aren’t fun for anyone. The whole process from initial contact to final decision can easily take months, depending on timing, and if you have a bad day at the end? You’re toast. Make the wrong decision as the hiring manager? You’ve wasted your time, and now have to undo the damage.

The best you can do is have a clear process and clear expectations. Understanding what is important to your team and your organization is critical. This tells you what you are testing for, which tells you how to prepare your interviewers and set up the day fairly. There’s nothing worse as a candidate than spending your entire day taking questions from a random crew who clearly hasn’t talked about what is actually important.

What I was hiring for a Senior UX Designer role at eBay, I had a list of things I wanted:

A true senior designer. This person needed to have the experience to work independently, present their work, and make the right decisions without constant escalation.
A designer focused on connecting products and flows, and less about building a flashy UI. This was related to business tools and payment processing. We wanted someone who was into the complexity of interconnected systems, not someone who would complain that they didn’t have anything Dribbble-worthy.
A designer who was willing to take and give a critique of work. This designer would be facing commentary from multiple teams who are likely to disagree with each other, possibly putting the designer in the position where they would be forced to get to the root problem and build consensus, or at least make it obvious where the true points of contention are. It was also important for us, as a team, to critique each other’s work directly and honestly, without causing or taking offense.
A designer with good communication skills. They’ll be responsible for presenting and selling their work, as well as working with product partners across coasts and continents.

When evaluating candidates, we knew we were going to be turning down ‘great’ designers who didn’t otherwise match what we wanted. It might be unfair, but (for example) a candidate with severe anxiety or who refused confrontation would not work well in this particular role.

Designing the process

Usually, I’m a firm believe at starting with the end: know where you want to end up and design your flow to get you there. This is no different. In short, you’re going to have a candidate who you’re pretty sure you could hire come in and share themselves with the group. Once they pass the “recruiter sanity check” – they’ve verified the candidate is who they say they are, and they have at least some interest in the position, it’s time for a phone call or two.

As the initial non-recruiter contact, it’s your job to make a solid connection and impression. This is (probably) YOUR team, and (probably) YOUR hire. Give the details the recruiter didn’t. Make sure there are no illusions. And above all, make sure the candidate passes the sniff test. If you get a feeling that they’re glossing over something, push them on it. If there’s a gap, or something strange, dig into it. This doesn’t mean they’re a bad designer or a bad person, but that everyone has a blindspot. You’re trying to answer two questions with a moderate degree of confidence: Would I want to work with this person? Could they do the job? You’re screening for the needs that you’ve hopefully listed out, using an abbreviated form of your interview loop – end to end walkthrough of a project; they articulate a design process and perspective, the ability to participate in critique, and a general culture fit.

While I disagree with some of his examples of good and bad questions (and answers), generally, speaking I find Richard Carillo’s perspective agreeable: we need to give questions that provide room for thought and exploration, while still encouraging a candidate to provide an answer – even if it’s wrong. Take this question about reducing Rock, Paper, Scissors to two options: No special knowledge is required. You don’t have to create something from whole cloth. The candidate has a specific goal but will have to talk through how they get there.

Off-site

At this stage, I have never asked a user to spend more than an hour preparing anything. When reviewing work, I will happily review a project on a website, or a super-basic presentation as long as I can understand how you work, where you had an impact on the process, and how the final product succeeded (or failed) and how you might evolve it. Chances are, a designer preparing for interviews already has this ready, or can get it ready shortly. I repeat: I stress that I am not grading someone’s presentation design skills. I just want to walk through one project in detail, and ask questions. Beyond that, I’m going to ask pointed questions – talk through designing a new feature, with critique and iteration as we go.

I’ve also seen suggestions to ask candidates to “teach something they’re passionate about.” It’s an interesting request, though I struggle with it on principle. First, we’re interviewing a senior designer, not a manager or principal/lead designer. We’re testing the ability to do, not the ability to teach. Second, it’s incredibly hard to define success here even if they are a good teacher. What if they’re passionate about dance? Or astrophysics? I’m clumsy, and math isn’t my strong suit.

Your candidate passes the round of phone screens. You think they’re a promising candidate. But maybe they can’t show a lot of recent work due to NDAs. Maybe they don’t have a huge body of work. Maybe you’ve just been burned in the past. So you’re thinking, it’s time for a design exercise.

Design Exercises

Design exercises are a touchy subject. I did a few earlier in my career. I interviewed with design agencies when I didn’t have much of a portfolio, or at least had a rather scattered one, and I understand why. I spent days on them. One was given pre-interview and was the topic of much of our critique. There was no direction around expectations for deliverables or format – just “do this in 2-3 days”). If this sounds like a setup for failure, it was. To this day, I’m still not sure why they brought me in for an interview other than to spend hours tearing my work apart. I’ll leave them nameless because it sounds like they took the feedback to heart. Another was given after an interview. It was legitimately the kindest, best interview I’ve ever had, and the agency heads said they liked some of my work, but that it was inconsistent. They gave me an old brief, their final set of wireframes, and we chatted for a few minutes. A few days later, I sent my work to them… and they broke my heart. This was Huge, Inc. (in their independent days). To this day, I have nothing bad to say about this. I had a third, which gave me 24 hours to complete a full presentation, from scratch) – even though I had a full-time job at the time.

I recently completed an exercise before being hired at Indeed, and I have to say that I feel it was a pretty good example. It was made clear that this work as NOT meant to be used in their daily work. I was given a clear brief, and clear expectations as far as deliverables and scope. I was told how much time was expected of me, and asked when I could start and complete it. I was then allowed to present and discuss the work remotely – all of which minimized the actual disruption to my normal life. Also: I was paid (well) for my time. Do you need to do design exercises like this? No. Good candidates have been hired without them. But, if this is a part of your process, do it like this.

Onsite

Then, comes the big show: the onsite interview panel. Assuming your candidate has gotten this far, you should be pretty confident that they’re a good match because you’re about to wreck your team’s day.

I feel like UX and product design interviews have an almost standard flow and while I think that does lead to a bit of a cookie-cutter feel, it’s not a bad process. They’ll introduce themselves, and their background, and walk through 2-3 projects. The panel (who are all of your breakout session interviewers, as well as other interested parties) is going to watch politely and ask clarifying questions or ask for more information, but avoids outright critique. This is setup for the rest of the day and ensures everyone has the same background, besides testing the candidate’s ability to hold it together and tell a coherent story in front of a dozen people.

From there, you’ll break out into as many sessions as you have time and people for. Having been on both sides of the process, I feel that paired breakout sessions are the best. They allow you to expose more of the team without overloading the candidate, help eliminate dead spots in interviews and helps ensure that no single person can break the process. Also, the day’s schedule should, in general, be shared ahead of time. The panelists should all know exactly what they’re doing. The candidate should have a general idea of what to expect. Other than generally asking the panelists responsible for the candidate deep-dive to followup the presentation immediately, there’s no set order to the operation, and time should be left to allow the candidate to breathe – try ending sessions 5 or 10 minutes early, instead of on the hour (or half-hour).

Deep dive

Immediately following the presentation, go deep on the presentation. Ask critique the work, critique the decision-making, and make sure the candidate’s contributions are clear. Leave no stone unturned.

Whiteboard design sessions

Give the designer a brief, and ask them to solve a problem. This is almost cliche, and there are dozens of guides that teach the test. Yet, I can’t think of a better way to understand the ability of a designer to solve a problem. Whether you’re designing an app for a theme park, an autonomous vehicle product, or a video game scoring system, you want to understand if a candidate can break down the task in a way that works for your team, and produce a concept for a viable product or system at the end and with points for further iteration and AB . The guidance I can give here is that you must – MUST – push for both process and an actual solution. Too many UX designers can’t actually design experiences – they’re lacking the ability to synthesis knowledge, assumptions, and hypotheses into testable flows.

I don’t know if whiteboard sessions must always relate to your core product. What I do know is that they should stretch the designer’s apparent skill set and get them outside of their comfort zone – even if you have to do two whiteboard sessions.

Critique

I am a firm believer in the power of group critique among peers. With the right framework, this transforms designers and their work, improves decision making, and eliminates the need for putting designers in front of a firing squad of directors. I will always fight for this in any flow I design. Given an experience that’s fairly common and no personal stake in the matter, ask the candidate to provide critique. Try to understand the user and business needs behind a feature as designed, and discuss where it meets or fails those needs. We’re not looking to endlessly praise the subtle interactions of Google Maps, or destroy the endless consumption of Netflix. We’re trying to take on the perspectives of others, and provide honest, kind, and useful critique. If you’re short on time? Combine this with a whiteboard session,

Culture fit

I’ve already had my say here. Team fit is valuable, but you don’t want to create a monoculture. Test for cultural fit, but don’t be a jerk. If you’re short on time, you can do this separately.

Breaks

Allow for 5-10 minutes between sessions. And if you’ve got a full day scheduled, plan to take the candidate for lunch (or let them explore solo depending on your environment).

Wrap-up

Don’t just let the candidate walk. Ask how it went. Not everything will go perfectly, and some people will just have an off day and their brain will fall out for a few moments. A candidate who gets 95% of the way there and shows self-awareness about where they failed or could have improved might actually be the right candidate.

Be honest with the candidate about your timelines. If you’re in the final round of candidates and want to finish them all before deciding, say so. But be fast. I lost multiple candidates at eBay because our process took so long, and we can’t ask everyone to wait forever. In the meantime, get feedback within 24 hours. It doesn’t need to be immediate – allow time for parsing and reflection, but don’t wait so long the details fade. Look for areas of agreement and disagreement as much as the individual hire/no-hire ratings. And last, follow whatever HR-approved decision-making process you’ve got in place.

Admin note:

A recent WordPress update appears to have duplicated sections of some blog entries and mangled more than a few others. If you see weirdness, I discovered this while writing at 11PM on a Monday evening. I will fix it when I am less likely to make things worse.

So what HAVE I been doing?

One thing that fascinates me is learning how people learn. The (probably disproven) cliche about people learning best from different methods (reading, watching, hearing, and doing) has intrigued me as there was one thing that my brain had steadfastly refused to learn until recently: 3D modeling. I took one class in college and every single concept bounced off my brain so hard that I decided to change my concentration so I wouldn’t have to take a second course. Several attempts in the intervening years didn’t change that impression much.

I recently decided to change that. I am not, by any means, good enough to claim 3D modeling as a marketing skill, but it’s nice to see at least some of the concepts stick.

I’ve also been forcing myself to relearn to draw and paint (digital and watercolor) over the last year or so. Here’s a small sample.

Granted this is from more than just the past few months, but when I’m stressed out from work, I find this far more relaxing than flailing at game design.

What’s in a title?

I’ll start with the disclaimer that this is my own opinion, based on my own experience. take everything here with a giant grain of salt (or at least many small ones). Onward!

After six and a half years at eBay and multiple roles on several products, I was given a team to manage. Then I threw it away when I moved to Indeed in February 2019. I made a conscious decision to change from a management role, back to a hands-on Individual Contributor (IC).

What does that mean? I’m still working on UX strategy for my product and helping my team improve decision making through our processes and cultural changes – a.k.a. honest, kind feedback. And yes, occasionally hands-on work. About the only thing I don’t do is write reviews and make hiring decisions.

I frequently grumble about the weird proliferation of design titles. We’re now all UX designers, who are separate from UI and visual designers. We rarely talk about interaction designers (or interactive) designers, information architects, or the myriad of titles that existed when I got started in this field over 15 years ago. That’s not to say I want all of you to get off my lawn. But it’s worth examining, as our titles morph and our seniority levels multiply, how our deliverables change. As a manager, instead of creating the products, I was building a team and acting as a multiplier for their skills via process, coaching, and leadership. I traded in hands-on product time for product strategy and growth. As a rather senior IC, my job is about 80% the same – however instead of writing reviews, I directly shape my product and how it connects to the rest of Indeed’s job seeker ecosystem.

This doesn’t mean I think that “UX Designer” is a great title. It’s a title defined in opposition to what it’s not. It’s not UI or visual design. It’s not wireframes. It’s not design systems. It’s not information architecture. About the only thing you can get a UX designer to commit to producing is a stack of scribbled-upon post-its. As much as I want to throw my hands up and yell at everyone to get off my lawn and let me have my UI, they’re right, and it drove me nuts during hiring. It’s not about the UI – it’s about the entire experience about using the product – synthesizing user research, understand the underlying systems, and teaching complexity through a user interface. Yes, a user interface. Whether it’s a fork at a restaurant, car’s dashboard, or a smartphone app, the user’s experience is ultimately defined by how they interface with it, from discovery to dismissal.

For the record, I don’t think any company has a perfect structure. Facebook calls their IC’s product designers. Whatever your specialty is, you’re expected to shape your product from end to end – which is great. However, this also makes it difficult to show recognition of effort when you inevitably leave since there’s no obvious promotion path. eBay, instead of creating a dozen arbitrary titles, recognizes growth within titles, by creating levels such as Designer 3 or Senior Designer 1. Of course, this process can also be weaponized, and has drawbacks in terms of unclear expectations and growth patterns.

Ingress, Egress & Failure.

I’m not sure if anyone reads the NY Times regularly, but a few days ago, they recently published an article about the most recent findings around the Boeing 737 Max crashes earlier this year.

In summary, many changes happened simultaneously and in near-isolation – the removal of backup sensors, the increase in scope, the decision to not require additional training, etc. Now, what we do on a daily basis doesn’t have the same immediate life-and-limb impacts of aircraft flight control design. Don’t the problems sound familiar, though?

https://www.nytimes.com/2019/06/01/business/boeing-737-max-crash.html

Not coincidentally, they published another article earlier in the year explaining WHY the 737 Max was such a challenge for Boeing to build and why it needed software intervention in the first place. In summary, the 737 is a VERY low-slung aircraft on the ground. Its short landing gear was designed for easier loading and unloading of passengers and cargo, as well as easier maintenance at smaller airports with less equipment. Many gains in jet engine efficiency have come from increasing the diameter of the first stage fan(s), which is a problem with limited ground clearance. Moving the engines forward and upward changes the center of balance and the center of thrust (both of which impact flight characteristics). Changing the way a plane flies can require extensive training if not full re-certification. To use a software metaphor, that’s not going from 1.0 to 1.1 – that’s going from 1.0 to 5.0.

A previous manager of mine always used the metaphor of trains. Companies are very good and building trains. PMs, developers, and designers are really good at making trains move forward in parallel. Some are fast, some are strong, some are beautiful. All too often, this is good enough. To run with the train metaphor our job is to not just build the trains, but to make sure they arrive safely. A passenger train needs to arrive at a station. It needs a platform where it can stop for several minutes to unload and load passengers. That station needs multiple platforms and switching so it can handle multiple trains. It needs signaling so trains know to stop outside the station. It needs to allow for the time and distance required for a train to actually respond to these signals. A freight train skips the station entirely. In short, it doesn’t matter how many wonderful trains you build if they crash into each other just outside the station.

As UX designers, we need to consider not just our products (the trains), but our users’ ingress and egress points. And we need to begin planning for failure – failure in our systems, and failure in our partner’s systems.

If you’re curious about designing for failure, consider reading Amber Case’s “Calm Technology.“

Conflict resolution, take 3

After taking some time off and considering the previous entries in the system, this are my latest thoughts around conflict resolution for an RPG system.

To summarize my previous goals:

The system should allow to strategy and semi-predictable outcomes. It should be neither totally random (dice rolls) or totally predictable).
If the order of play can’t be determined by the storytelling and fiction of the world, a system will allow the players to determine the order.
All action takes place via the players. The DM never acts, except as a reaction to the outcome of a player’s action.
The result of an action will be either a full success, mixed result, or failure.

Not a goal, but an additional restriction: The system should work with a single, standard 52 card deck. No special supplies are required.

Conflict Begins

All engaged characters are dealt a hand of 3 (secret) cards.

Order of Play

The general preference is for storytelling and fiction to determine the order. If the group is walking down a hallway single file, the character in front encounters danger first, and thus is first to act/react unless they choose to delay their action. If one character is about to act on another character who is asleep, then the sleeping character goes second. If two characters are genuinely attempting to act simultaneously (i.e. approaching each other around a blind corner), or attempting to act simultaneously to another stimuli (i.e. reacting first to a signal) – then continue with this set of steps.
Any characters who attempt to act at the same time place a card from their hand face down.
When all cards are placed, they are revealed. The player with the highest card goes first. For the purposes of determining order, Aces are high followed by Kings, Queens, Jacks, then 10s and all other numbered cards in descending order.
If there is a tie, another card is dealt to the tied players, and the process repeats.
If more than two players are attempting to move simultaneously, non-tied players go in order of their cards. Then the tied players re-draw. For example, 4 players play, in order, a King, a nine, a nine, and a five. Player one (King) goes first, then Player 4. Players 2 & 3 (who both played a 9) redraw, and play 10 and 2, respectively.. The final order is Player 1 (King), Player 4 (5), Player 2 (10), then Player 3 (2). All cards played until this point are discarded.
Players who go through these steps DO NOT draw back up to 3 cards.

Resolve action

The desired action is described in story terms, and aligned to a player character’s skill or action. The DM gets final say on validity.
The player plays 2 cards from their hand face up in front of themselves. If they have a card remaining in their hand, it is set aside for now (but not discarded).
The player plays additional cards as desired by drawing from the top of the deck. The goal is to meet or exceed a target without going over 21.
Target for mixed result is 15. Target for a full success is 17. Going over 21 is an automatic failure.
If you get 21 from the 2 cards from your hand (aka, blackjack) you have an automatic full success, which cannot be interfered with.

Modifiers & Assistance

Modifiers come from a character’s innate skills, the surrounding environment, or other players.
Modifiers increment or decrement the target by 1. So 2x (-1) modifiers, make the target for a mixed success 13, or full success 15.
One player involved in the scene or action may choose to assist or hinder at any time before the action is resolved by replacing the last card played with one card from their hand. Each action may only be assisted/hindered once, and each player may only do this once per round.
Some skills may allow you to “hold” a card going forward. This essentially allows you to assist yourself. Once per action you may spend one hold to replace the last card played with the one remaining card in your hand (if you have one) or draw a card from the deck, and replace the last card played if it is beneficial (the card that was removed from play will be discarded.

After all players have gone (1 full round) the DM deals enough cards to return all players to 3 cards in hand. When the deck runs empty, reshuffle all discarded cards.

I feel pretty good about this system, though the numbers may need to be adjusted. What say, you, internet? Reasonable next steps to check the validity of this system would be some simple dogfooding, and then take an Apocalypse World (or derivative system like Dungeon World or The Sprawl) adventure and rework it using this system.

New job, new distractions

First, I’ve taken a break from my game design experiment because I started a new job. I’m no longer a UX Manager at eBay. I’m now a Senior UX Designer at Indeed. My thoughts on job titles, taking a management (or individual contributor role), and looking for and leaving jobs will come later.

I had a week in between jobs, and used that time to work on 2 projects. First, I wanted to make progress on my workbench. I need to move my shop space into a different part of my house, and the current bench is not moveable, and even if it was, has some functional shortcomings. Second, I started exploring 3D modeling in Blender (via a Udemy course). I’ve got no particular goal with this other than to learn a new skill. I’ve always been curious about 3D modeling though my exposure to the creation process was limited to one college course. I’ve barely made it through the first section but I understand enough now to have some fun.

As my schedule settles over the next week or two, I will begin reviewing the game work I’ve done so far and define next steps.