4.3 KiB
+++ title = "Commented Links for 2020-07-26" date = 2020-07-26
[taxonomies] tags = ["links", "datomic", "advice", "developer", "google", "racism", "logging", "delete", "product manager", "syntax highlight", "highlight", "rust", "modules"] +++
Datomic Internals, Developer Advice, Racism@Google, Logging, Code To Delete, Being a Product Manager, Syntax Highlight, Rust Module System.
Unofficial guide to Datomic internals
Database internals are always curious, to say the least. And Datomic is also a curious database, as everything is immutable.
But understating internals is always good to understand where the database fits and how to take most of it.
Advice to Myself When Starting Out as a Software Developer
When you're working in the field for too long, it is easy to forget how it was when you started.
I can't find anything wrong with the tips, but they feel a bit... bland. I mean, honestly, the tips here are something that should be in every developers list anyway, beginner or pro.
Google Ad Portal Equated “Black Girls” with Porn
Oh, are you saying Google is racist? That's impossible! That's "the algorithm" fault! Google is good, it gives me free email!
You see how "giving things for free" and "open source" (and then not listening to users) is purely a marketing plot?
Good Logging
Logging is always important -- personally, I think logging (and good logs) are more important than debugging -- but knowing how and what to log is the key for properly dealing with it.
Some of the points are quite common, like screaming logs, although the solution is not using WARNING or INFO, but actually figuring out how to properly set the log level for each modules -- and using modules -- feels more correctly.
Personally, I leave a lot of debug messages in some places, as "scars" of a
battle. Maybe some future developer will see that sequence and think twice
before jumping in.
Write code that is easy to delete, not easy to extend.
That's one thing I totally agree: it is better to write code that's easy to delete than to reuse. But simply going into copying things over and over so you can delete one thing without breaking the other is not actually the solution.
I'd just adding abstractions, to the point functions are so simple they exist without any business logic; these logic pieces are then put together in other functions, describing exactly what the business rule is: get_info_from_server, change_info_in_some_way, and so on. If the rule change, you just delete the abstraction in the middle of the larger function.
"But that still doesn't solve it!" Well, if the business rule changed, then you can either delete the larger function and write a new one to follows the new rule or simply drop -- or add -- any of the abstractions.
22 Principles for Great Product Managers
I didn't even get to half of the list and I was "yup, I had a hard time with a manager that didn't do that" and "I remember when they did that and it was awesome".
Syntax highlighting is a waste of an information channel
Once again, "I can get behind the sentiment, but not the implementation". Surely, having information about types, or some parameter, in the syntax helps a ton, but the fact is that it depends on situation. At some point, the type may be more important than the parameter, or vice-versa, or worse, it may give focus to something that is not important at that time. Putting all that together, at the same time, would be a nightmare -- or a fruit salad of colours that would make reading the code and finding what matters completely impossible.
Clear explanation of Rust’s module system
Rust module system is a bit different from everything else, and the exploration I did gave me some insights about it -- mostly, exactly what the post says.