I’m cool with story points, as long as I’m not asked to make them up or care about what others’ story points are. 🤠

And here are a few screenshots of an interview with Deming:

and

A toxic trait of some devs I can’t stand is when they write their opinions in confluence/notion/etc and then point to it as “the standard” whenever someone says something that goes against it.

Best practice: write your own version, but prepend the title with “Updated:”

Reviewing all the tickets for an entire week and expecting everyone to be able to have enough context on everything is a ridiculous way to plan your week.

Instead: Work smaller. Have the courage to speak up and say “I can’t care about all those things right now. I need deliberate attention and focus on the thing right in front of me right now and everything else is a distraction. I’ll give the same amount of attention to all those other things when I’m working on them.”

That’s not to say you shouldn’t be aware of the bigger picture and know what else is going on.

If it’s not in main, it doesn’t exist.

Bad managers take silence as acceptance.

Often, they should be hearing it as hopelessness.

It’s fine to have strong opinions, but don’t dismiss others if they have a differing opinion. Their reasons are often just as strong as yours. Listen to them. You might learn a thing a two.

A few interview questions to consider.

• What’s the whole process for getting one line of code changed into production?

  • I once had to remove a link from an admin dashboard. The process to do that was 52 steps.

• Humility is an enabling principle that precedes learning and improvement. A manager must be willing to seek input, listen carefully, and continuously learn. They do not know it all and readily admits that. When you have done this? How often?

• How do speed and quality relate?

  • After they answer: Does frequency of feedback affect this, and if so, how?

• What does the phrase “test in production” mean to you?

• Who owns the board? Is it viewed as Products board?

• Do you put ticket numbers on each commit?

• Do you incentivize improvements? And how soon? What type of improvements do you value?

• How do you recognize when you’re stuck in the “we’ve always done it this way” trap?

• Are developers treated more like a line cook or a doctor?

• In order to get better, you have to be intentional. If you’re not intentional, you’ll be average. What are you doing to be intentional?

• I found myself fixing bugs constantly in the past few jobs I’ve been in. They didn’t have good practices, always rushing around, which led to bugs, and it was a constant firefight. What’s the situation like here?

• How often are you changing our process to try to make yourself more effective?

  • (there should be many recent examples).

• What question did you wish you would have asked before you started working here?

• If you’re the manager of a 7 person dev team, how many separate concurrent initiatives do you have? How did you reach that number?

• If your team uses PR’s, how do you handle large refactorings? Do you have to create a story/ticket just for the refactoring? If it’s a large refactoring and other work is going on, do you plan on having a messy merge conflict when that time comes? How do you encourage small changes like typos, small refactorings, etc? Do you roll them into bigger PR’s and deal with the merge conflicts that others have later?

• (If they bring up story points) How many dollars does a story point save or make?

Another css example I want to hang on to.

It’s pushable!

Code:

<button
  class="mb-4 p-2 w-32 transition ease-in-out duration-100 outline outline-1 shadow-[0_5px_0px_0px_rgba(0,0,0,0.6)] active:shadow-none active:translate-y-1 "
>
  pushable button
</button>

There’s a lot of more examples at Josh Comeau’s site and hnldesign

Continuous Integration is a thing developers do, not a software build tool.

quick example of some css tailwind stuff when hovering over an image

A few interview questions to consider.

• Why did the last person in this role leave?
• How many long timers have left recently? Why?
• Is deploying difficult? How often do you do it?
• Do you assign tasks to individual people?
• Do you seek simplicity? What was a complicated process that as a team you were able to simplify?
• Do you limit WIP? If not, how to fix bottlenecks in your process?
• If everyone in the standup is busy with something, is that a red flag or a good thing?
  • (no way that team is efficient. )
• How often is the question “How am I wrong?” asked?
• What is your improvement strategy?
• Do you deploy on Fridays? Why not?
• Do you measure the queues - i.e. how long things wait to be reviewed, to be QA’d, to be deployed? What are those numbers?
• Do you ever commit a change that you do not trust?
• What corners do you cut? What corners have you cut?
• “Follow the plan” or “incorporate feedback”?