293 private links
What are developer's blocks?
All these practices (documentation, tests, CI) are valuable, but sometimes they just mount up until you’re blocked.
Either you are new to the project and you just feel overwhelmed or you’ve been working on the project for a while, but you run out of stream and get stuck. it may be due to overwork or a lack of motivation.
How to unblock?
- Take time with learning. Sometimes, the docs or tests need to be read to get an idea of the externals. Eventually looking at the source code and building up a mental model of how it fall fits together. "If you think education is expensive, try ignorance"
- Realise when you're tired
- Work incrementally: implement it with the minimum effort. Circle back round to improve the tests, docs, etc...
- Write a prototype: Concern yourself only with the happy path. If you’re trying to learn about a dependency, it’s sometimes easier to write a quick prototype of using the dependency, possibly in an empty repository.
- Start with draft documentation: avoid premature docs polishing. Capture why you did things a particular way. Provide basic usage instructions.
- Release early, release often
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.
The source code of the Viaweb editor was probably about 20-25% macros.
Computer hardware changes so much faster than personal habits that programming practice is usually ten to twenty years behind the processor. At places like MIT they were writing programs in high-level languages in the early 1960s, but many companies continued to write code in machine language well into the 1980s.
How to do X in the browser dev tools.
It’s not always easy to keep these separate, especially when one’s vocation transcends mere occupation to become a genuine passion and source of fulfillment.
The job [...] starts with great enthusiasm, but may evolve to reveal fundamental incompatibilities.
it seems almost predictable that when someone works defining design principles for their clients all day, they don’t necessarily stop and think: Oh, maybe I should apply these same methods to my own life as well.
“One of the choices I’m most proud of is that early on, I realized that what success looks like for me is freedom and curiosity and the ability to follow whatever path I take.”
Freedom, Curiosity, Happiness, Authenticity, Love
It made them a subscription model:
▫️ Lust → Tinder
▫️ Gluttony → Uber Eats
▫️ Greed → Amazon
▫️ Sloth → Netflix
▫️ Wrath → X
▫️ Envy → Instagram
▫️ Pride → LinkedIn
I like the menu at the bottom, and the simple yet clear introduction.
While copying the code, the right abstraction reveals itself.
If you start too early, you might end up with a bad abstraction that doesn’t fit the problem. You know it’s wrong because it feels clunky. Some typical symptoms include:
Removing a wrong abstraction is hard work.
Clean up afterwards :)
Changer d'entreprise après 25 ans
C'est plus une plateforme d'aide. Je remarque que tout informaticien qui se reconverti peut apporter son expérience et développer un produit en adéquation avec ses besoins.
We ended up deciding: what the heck, we might as well meet the market demand. So we put together a bespoke ASCII tab importer (which was near the bottom of my “Software I expected to write in 2025” list). And we changed the UI copy in our scanning system to tell people about that feature.
I am not sure it's a market demand, but only a ChatGPT hallucination.
Deleting lines of code for optimisation and better maintainability.
I’m a web developer with ADHD, and I help people build the web better.
Builder of Kelp UI.
Instead of asking: I’m hungry, let’s go to McDonald’s
Why not: I’m hungry, let’s go eat: McDonald’s?
A “no, because” statement instead of a plain “no” moves the problem from a blocker into an opportunity.
Do not accept “we’ll figure that out later” as a response to pointing out meaningful problems. It’s a con.
Solve the problems or abandon the project.
Import et Export of software forges (issues, PR/MR, milestones, release assets, etc...)