319 private links
Ideas for creative projects. Lean and have fun.
“What I cannot create, I do not understand”
One ting to consider: KISS. The program can crash or panic for a lot of code path. Implement only the necessary!
KISS for maintainability: "Nothing in Rust forces us to get fancy. You can write straightforward code in Rust just like in any other language. But in code reviews, I often see people trying to outsmart themselves and stumble over their own shoelaces. They use all the advanced features at their disposal without thinking much about maintainability."
Here an real life example.
But if simplicity is so obviously “better,” why isn’t it the norm? Because achieving simplicity is hard!
Even in Rust: abstractions are never zero cost for developers.
Often, simple code can be optimized by the compiler more easily and runs faster on CPUs. That’s because CPUs are optimized for basic data structures and predictable access patterns. And parallelizing work is also easier when that is the case. All of that works in our favor when our code is simple.
Most of the code you’ll write for companies will be application code, not library code. That’s because most companies don’t make money writing libraries, but business logic. There’s no need to get fancy here. Application code should be straightforward to keep your fellow developers in mind.
Tips:
- start small
- avoid optimization early
- delay refactoring: we have limited information at the time of writing our first prototype.
- write code for humans
- The right abstractions guide you to do the right thing
As a nuclear engineer, I have never been asked to show my portfolio of reactor designs I maintain in my free time, I have never been asked to derive the six-factor formula, the quantization of angular momentum, Brehmsstrahlung, or to whiteboard gas centrifuge isotopic separation, water hammer, hydrogen detonation, or cross-section resonance integrals.
There's something deeply wrong with an industry that presumes you're a fraud unless repeatedly and performatively demonstrated otherwise and treats the hiring process as a demented form of 80s-era fraternity hazing.
The table is available as PDF https://dr-knz.net/programming-levels/prog-skill-matrix.pdf
Take a moment and think; what does everybody needs here?
What are the things this team struggle with?
How can I write up a doc, show what is wrong and propose a solution?
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.
The ideas of a grug developer.
How to do X in the browser dev tools.
I used to be on a team that was responsible for the care and feeding of a great many Linux boxes which together constituted the "web tier" for a giant social network.
At some point, I realized that if I wrote a wiki page and documented the things that we were willing to support, I could wait about six months and then it would be like it had always been there. Enough people went through the revolving doors of that place such that six months' worth of employee turnover was sufficient to make it look like a whole other company. All I had to do was write it, wait a bit, then start citing it when needed.
One near-quote from that page did escape into the outside world. It has to do with the "non-compliant host" actions: "Note: any of these many happen without prior notification to experiment owners in the interest of keeping the site healthy. Drain first, investigate second."
So the author created a list of actions; methods to apply for any given events.
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.