2024-04-01
Unix terminals and shells - 1 of 5
Part 1/5 on better understanding what a terminal is and how it works.
Part 1/5 on better understanding what a terminal is and how it works.
I still don't think you should, but if you're going to write programs in bash, you should at least try and know what you're doing to prevent shooting yourself in the foot.
On a simplicity kick. Seriously, stop complicating things when they're too simple for you. A program really can just be a series of nested function calls and no more. Resist the temptation to "simplify" an already simple problem.
One of the older essays with interesting things to discuss. Worth a read and deep contemplation.
Less practical and more comedic.
This is the only software philosophy you need.
No, really. It will make you as smart as Socrates. To know that you know nothing is the beginning of true wisdom.
Update (2024-12-14): I've actually written an entire post similar to this in my piece discussing Knowledge vs. Wisdom. That's how important an idea I think this is.
I've rarely felt more like I could have written a post than this. Stop over complicating everything.
Absolutely invaluable insights into managing and creativity.
Great introduction to many core computing.
Such a simple concept that gives you so much return. I've used this to great effect in many large projects.
A fun combination of Taoism and software development. Truly something valuable to the career programmer.
If you're writing SaaS you really need to understand these concepts.
The amount of time it takes to remove code you didn't write in most code bases is way too high. Too many people think the source code is the valuable part of the company when it is quite clearly the mental model in the heads of the programmers that provides at least ten times the value.
A Rich Hickey talk is always a good time.
Here I think he's right on in understanding the real problems of versioning and communicating what we've done to our code that someone else depends on. I also love the attention to the real semantics through set operations. I also think he's right. Every time someone breaks something I depend on, I'm forced to do a bunch of work because of someone else. Not work I wanted to do, work they made me do. And that makes me want to instead do the work to delete that dependency. It's costing me extra work to maintain it. Work that's usually not improving my work in any meaningful way to me and my users.
Telling developers building dependencies, building platforms, that it's fine to break things as long as you change the left most number invites them to break things. It says it's fine as long as you let me know. It's not fine. Stop breaking things! If you want people to depend on you, be dependable. "The spec says I'm allowed to. I changed the number."
No. Just because you can doesn't mean you should. My favourite dependencies don't break things. They continue to work, they know when to stop. My favourites haven't been updated in years. When did we get this insane idea that everything needs updating to add new things I don't care about all the time? I blame Microsoft but we all need to stop it. Build new things when you want to add something. It's fine to create a new package that depends on the first if you're adding new things. The vast majority of people using the first thing, by definition, don't need the new thing.