Ship: push the changes.
Show: merge directly after CI passes. In doing so, you’ve taken your change live quickly while still creating a space for feedback and conversation.
Ask: classic review process

I feel that junior team members are less frequently singled out for praise, as often they are working on less critical tasks, and so the impact of their work is less visible.

Sometimes the “feedback” is hearing how something you’ve built has touched someone, or made their lives better [...] it could also be simply hearing that you’ve made it easier for a person to accomplish a task that was previously difficult

Feedback from a talk is welcome because giving a talk is a solo adventure.

and about feedback in general :)

An efficient alternative to gitlab and github

Devs are expected to do everything.

The tools are more complex and it cycles every 5 years.
HTML and CSS are not enough these days to build websites in companies.

How to finish the last 10% of a project?

1. Set aside a block of time.
2. Decide upfront what you're going to work on.
3. Fight with everything to focus on that one thing.

"Just work."

Avoid the feat of finishing. It's useless. Release it.

The key point they make is that anything you do is of no value until it is in the hands of the people it is intended for.

Always ship.

“The simplicity of HTML and CSS now feels like a radical act. To build a website with just these tools is a small protest against platform capitalism: a way to assert sustainability, independence, longevity.” — Jarrett Fuller

Reason to write:

• share information
• learn about something
• side-effects such as help to establish your credibility

How to write for developers?

Consider the clarity, personality and the uniformity of content. Each medium has it scale on these three.

The physical act of writing? Start with notes and expand. Just start writing. A similar approach is reported by Finding comfort in the chaos: How Cory Doctorow learned to write from literally anywhere.
The point is to have something, then iterate.

1. software should comply to needs, not the other way around.
2. well designed API are great
3. use standards whenever possible
4. we have different tastes
5. respect the user's home directory.

The long-term popularity of any given tool for software development is proportional to how much labour arbitrage it enables.

What do I mean with labour arbitrage?

Friction is defined as the difference between military theory and reality in the book On War.

There are plenty of such frictions in software development, for example:

• API's that does work quite as you though it did, or it changed
• Bugs. Security alerts. A breaking dependency upgrade.
• Someone gets sick and information is lost.
• Requirements are unclear, or a client changes what they want, during of after development.
• Laptop breaks or gets stolen.
• Tooling breaks.

How to avoid that?

• smaller scopes and shorter iterations
• more autonomy
• redundancy
• better planning
• automation
• experience
• gaming
• checklists and runbooks

Wow!

I’m designing for the web. The infinitely flexible web. The web that doesn’t have one screen size, one browser, one operating system, or one device. The web that can be used by anyone, anywhere, on any internet connection, on any device, on any operating system, on any browser, with any screen size. I’m designing with the web. Using the web platform. I have a deep understanding of HTML and its semantics. I love CSS, I know how and when to utilise its many features, and I keep up-to-date as more are added. I have a strong understanding of modern JavaScript and most importantly I know when not to use it.

Also an accessibility specialist. My expertise goes beyond what web designers need to know. I’m also a design system specialist. I’m a systems thinker. I love standardizing things to simplify the web development process. [...] I love human-centred design and co-design—nothing about us without us.

I think programming is like running a dishwasher. It always takes longer than you think and some stuff is never as clean as you expected it to be.

These are great programming and code patterns

It simply handles it. The service is a simple binary in Rust 😃