hbrn

13 ms·

121.
by hbrn 4y ago
Raymond Hettinger talks are a good start (e.g. https://youtu.be/wf-BqAjZb8M ) Every now and then read Zen of Python and try to understand it. Tim Peters somehow managed to fit enormous amount of wisdom in it.
122.
by hbrn 4y ago
The only way to enforce such law would be to have an oracle that tells you which actions would maximize profits. Obviously such oracle doesn't exist, and even if it did, it would not come from legal system. What legal system can do fai
123.
by hbrn 4y ago
> Those are the design decisions accompanied by developers who think complexity is the enemy and seek to "contain" it at all costs—even when it adds hierarchical/organizational complexity. Not in my experience. Overenginee
124.
by hbrn 4y ago
OAuth library is a perfect example of lousy engineers inventing complexity. Here's a talk where Jack Diederich mentions it: https://youtu.be/o9pEzgHorH0?t=870 It is indeed complex: 200+ classes. Plenty of unit tests an
125.
by hbrn 4y ago
I fail to see how unit tests are going to help. If rules are independent, overall complexity is low, even if there are thousands of rules. If rules are dependent, unit tests are useless. > introduce layers of abstraction, try increasin
126.
by hbrn 4y ago
But I get to refuse to turn OAuth into a cross-cutting concern in my application. You won't see refresh tokens referenced in the UI code. And I get to use a 3rd-party library that solves 90% of the pain for me. I strongly disagree on t
127.
by hbrn 4y ago
But complexity is the enemy. Where it can't be eliminated, it can be contained. That's what software engineering is about. It is nearly impossible to find a complex domain that doesn't naturally break into smaller subdomain
128.
by hbrn 4y ago
> Testable code is inherently more decoupled I.e. more abstract with more layers. Exactly the opposite what you want as a startup. As a startup, your pivot is not going to be switching from MySQL to Postgres. Your pivot is going to be sw
129.
by hbrn 4y ago
Most people agree that coming up with proper edge cases for unit tests is way harder than writing original code. You're not just writing code that works, you need to anticipate in what way it's going to break. That means that en
130.
by hbrn 4y ago
> If you can fit the entire system in your head, it's probably a relatively simple codebase. Or it has good boundaries and I never have the need to load the whole system in my head. You're not loading the whole OS kernel in you
131.
by hbrn 4y ago
And that's why I said "most likely". That said, mathematical algorithms: 1. Rarely need refactoring. If you often refactor your math, you probably mixed it with something else (unless your business is math). 2. Rarely have
132.
by hbrn 4y ago
If you're building complex things... most likely you should be building simple things. Most software in the world implements business rules defined by people who are way less smart than your average engineer. And yet our software is mo
133.
by hbrn 4y ago
The comment you responded to says unit tests give confidence, you seem to agree. "Tests generally" and unit tests are pretty much the opposite camps in testing world.
134.
by hbrn 4y ago
Automated tests are not a solution to constant regressions. The are a solution to lots of manual tests. If your team ships lots of regressions, it means your team prefers regressions over manual testing. It's a culture problem. You c
135.
by hbrn 4y ago
Unit tests can never give you "confidence". > you can watch as over time you get either increasing error rates or a massive slow down in team performance I hear this story repeated over and over and yet I consistently witness t
136.
by hbrn 4y ago
> Either you're writing tests or you're manually running the software (manual testing) There's nothing wrong with manual testing. In fact, unless you have good set of E2E tests (most companies don't), you still need m
137.
by hbrn 4y ago
We have two variables with the same name, but one is a constructor argument, another one is an instance attribute. PEP-484 is absolutely fine with that, it's downsides (and benefits) are purely in the human domain. > allowing variab
138.
by hbrn 4y ago
> LLMs are not supposed to answer knowledge questions I googled for a knowledge question and wasn't able to find an answer. Then I used ChatGPT and it produced a surprisingly satisfying (opinionated and correct) response. I was able
139.
by hbrn 4y ago
He could've used different variable names in his example too, which makes me believe variable clashing was in fact intentional. And while it's definitely a controversial approach, there are cases where it can be considered more re
140.
by hbrn 4y ago
Other than having type annotations, in what way is this nicer? Seems way more verbose and less readable.
141.
by hbrn 4y ago
I use something very similar with Logitech devices and can't imagine my life without it. One thing I'll add, IMO it makes way more sense to map "forward" button to "Enter". Esc is already easy to reach if you k
142.
by hbrn 4y ago
I feel the same way, I lost amazing engineers to this weird typing obsession. Excessive typing is very costly and should be left to popular libraries that solve generic problems. This is where you get best bang for buck. It should not be pr
143.
by hbrn 4y ago
Async processing is also a great way to sweep failures under the rug. A lot of those failures won't even be detected, because you don't have proper monitoring, whereas in sync world you fail early and loudly. And instead of "
144.
by hbrn 4y ago
So the argument is that synchrony taken to extreme is ridiculous, therefore we need asynchrony? Sorry, but that's a textbook manipulation. Almost like he's trying to sell us something... No wonder AWS UX is so terrible.
145.
by hbrn 4y ago
1. Anything that is connected to user interface should be synchronous by default. 2. You can't predict which parts of your system will be connected to user interface. 3. Here's the worst part: async messaging is viral . A service
146.
by hbrn 4y ago
No offense, but this sounds like typical React-cult nonsense. You're still making the same amount of DOM manipulations in the end. And you don't need VDOM to figure out which manipulations are necessary. There are some potential o
147.
by hbrn 4y ago
VDOM is just an implementation detail that you shouldn't care about at all. But React team went big on advertising it as some kind of virtue, and a lot of gullible engineers bought that idea.
148.
by hbrn 4y ago
The reason VDOM was desirable is that React's "View is the function of the State" paradigm has a great developer experience, and VDOM was just the easiest way to implement it without sacrificing performance too much. Now that
149.
by hbrn 4y ago
The only way to innovate is to keep trying new things until one of them succeeds. Failure is inherent to innovation.
150.
by hbrn 4y ago
What type imports are you talking about? https://peps.python.org/pep-0585/ has been implemented in Python 3.9.

More ›