Freek.dev

I fully agree (but I might not be totally objective here 🙂)

Read more [tnakov.dev]

Adding fake() methods to your custom facades in applications and packages can provide some nice DX and APIs.

Read more [ryangjchandler.co.uk]

Claude Code has considerably changed my relationship to writing and maintaining code at scale. I still write code at the same level of quality, but I feel like I have a new freedom of expression which is hard to fully articulate.

Read more [blog.puzzmo.com]

Good naming, consistency, clear communication, and discoverability. These are things that do not only apply to command line programs, but to general development as well.

Read more [clig.dev]

Jujutsu (jj) is a new version control system from a software developer at Google with a focus on DX.

Read more [v5.chriskrycho.com]

Let's talk about Husky, a tool that automatically runs any number of commands whenever you commit or push. You'll never have to worry about forgetting to format, lint, or test before uploading code to the repo — Husky does it for you every time you run git commit or git push

Read more [tighten.com]

Communication is an absolutely critical skill for product development. But it's hard and it requires practice and feedback.

Read more [thunk.dev]

Some good tips for writing effictive, human-friendly documentation.

Read more [thenewstack.io]

A nice list of things to keep in mind when writing software or documentation.

Read more [leerob.io]

How many times have you onboarded a new dev onto your team, only to have to spend ages debugging with them because your project's .env.example file is wildly outdated?

Here's a package that can help with that!

Read more [github.com]

If you’ve ever found yourself asking any of these questions and happen to use VSCode, maybe the new Inline Parameters extension will help you out!

Read more [liamhammett.com]

My buddy Frederick wrote an interesting post on why he always checks out the admin panel of an app instead of the code.

Read more [frederickvanbrabant.com]

JMac, the creator of Laravel Shift, has a few interesting ideas on how to make the framework better.

Every so often a revolutionary change is required. This provides a chance to revisit goals. One of the primary goals of Laravel is developer experience. And maintainability, freshness, and approachability all improve developer experience. So, with all this in mind here are the top five things I would change in Laravel.

Read more [jasonmccreary.me]

Here's an interesting approach to work with env variables proposed by Marijn Huizendveld

Frameworks offer tools to parameterize environments in a variety of ways. But because of this configuration files of projects tend to get messy once projects are taken into production. Specifying purpose of the parameter within the name can help identify unneeded configurations. Making configuration explicit within the application layer can be even more helpful. Doing so eases refactoring and provides potential to improve the overall developer experience.

Read more [marijn.huizendveld.com]

In an article on his Medium blog, Jerzy Zawadzki wrote about the most important changes made in Symfony 4.

Internally, Symfony 4.0 is “just” Symfony 3.4 with removed depracations. But from outside there is a big leap forward. Most changes (from the installation process, directory structe through using bundles, to coding itself) were made to improve Developer Experience with the framework. Such system like Symfony, which can be used to create web apps as easily as to build other frameworks on top of it, must be complicated. But, as Symfony proves in new version, this complexity may be ‘hidden’ from the developer eyes.

https://medium.com/@zawadzki.jerzy/symfony-4-new-hope-dbf99dde91d8

Read more

Brent Roose wrote down his thoughts around how things like fonts, spacing, docblock, ... can influence the cognitive load of a programmer.

As a professional programmer, I'm reading and writing code on a daily basis. I'm working on new projects, doing code reviews, working with legacy code, learning documentation etc. Based on my own experience and that of colleagues, being a programmer often involves a lot more reading than actually writing code. Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

https://www.stitcher.io/blog/a-programmers-cognitive-load

Visual debt is real.

Read more

On the Tighten blog Samatha Geitz sums up the benefits of giving developers one day of "free" time a week.

About a year ago, Tighten officially implemented a "20% time" policy for its developers. This means that, on any given week, we only bill our clients for 32 hours of developer work; for the other 8 hours, developers can work on whatever projects they’d like to (as long as they can readily come up with an explanation of how it benefits the company in some way.) ... Here are some reasons that you may want to consider experimenting with a policy like this

https://blog.tighten.co/give-your-developers-20-percent-time

Read more

Rob Allen, an active member of the Zend Framework community, makes the case for giving some love to API errors.

It's not hard to have great error responses; you just need to care. Poor error response cause developers to give up with an API and go elsewhere, so it's a competitive advantage to get this right.

Developers integrating with your API will thank you.

https://akrabat.com/api-errors-are-first-class-citizens

Read more