Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
hbrn
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
54 ms
·
601.
▲
by
hbrn
4y ago
It would only be poisoned if I had to adjust the perfect solution definition to fit my edge case. Luckily, I did not.
602.
▲
by
hbrn
4y ago
> What deep tradeoffs are Solid or Svelte making in exchange for their speed I wonder why so many folks care about performance. I guess it's the only objective thing you can throw in someone's face as an argument. But I think o
603.
▲
by
hbrn
4y ago
There's React Stockholm Syndrome: downsides of React are often praised. Somehow people think there's a lot of foresight and wisdom in JSX invention. There's just so many good properties JSX has. But JSX was merely an easiest
604.
▲
by
hbrn
4y ago
I'd say it's subset of perfect solution fallacy [1]. Every edge case is seen as a problem that has to be solved, at any cost . One of the root causes is that when you're designing something, you really suck at understanding
605.
▲
by
hbrn
4y ago
> Nobody ever got fired for copying Google, Spotify, Twitter This. I see it over and over. People are thinking that copying management practices of successful companies is going to make them successful too. But it only works if those pra
606.
▲
by
hbrn
4y ago
One litmus test for a good manager that I found: do they ever make decisions that are optically bad? If the answer is no, what do you think are the chances that optics are the main factor in their decision making process? An example from pe
607.
▲
by
hbrn
4y ago
Plaid was originally a budgeting app. After realizing how terrible banking APIs are, they pivoted to building a developer-friendly banking API. Now their valuation is 10B+.
608.
▲
by
hbrn
4y ago
> Not going to lie -learning to do TDD properly is difficult > The dev manager had everyone take a day of TDD training after that, but nobody really understood That is exactly the problem with TDD or any other methodology that is hard
609.
▲
by
hbrn
4y ago
It all comes down to cost. Most of the time you can get kind monitoring for free or at a very low cost. AWS gives you a bunch of metrics out of the box for every product. Wrap your webapp in newrelic-agent and get a bunch of nice dashboards
610.
▲
by
hbrn
4y ago
The more I think about it, the more I realize that generic declarative style, despite sounding very promising, might not be a good fit for modern deployment. Mainly due to technology fragmentation. There's no one true way to deploy an
611.
▲
by
hbrn
4y ago
While premature optimization is still evil, I think it's no longer the root of it. Average quality of developer is way lower than it used to be (people aren't even capable of optimization). The need for optimization is also not as
612.
▲
by
hbrn
4y ago
I believe the main reason is that it makes fun of newspeak used by russian propaganda. Newspeak started long before the war. Explosions are called "claps", plane crashes are "rough landings", decline is "negative gr
613.
▲
by
hbrn
4y ago
> Tests make refactoring slower, because you might have to also update the tests No, tests can make refactoring slower, because they often test implementation detail instead of interface. Being able to distinguish the two is not as easy
614.
▲
by
hbrn
4y ago
> lack of tests will inevitably result in a slowdown This is exactly the mindset I'm talking about. Lack of which tests? Manual? Unit? Functional? Integration? End-to-end? Doesn't matter, right? All tests have zero cost, the mo
615.
▲
by
hbrn
4y ago
Exactly my experience. Numerous times I found ways to reduce accidental complexity in software. But guess what, my change breaks 50 tests, because accidental complexity happened to be under test. What I anticipated to be an enjoyable 2-hour
616.
▲
by
hbrn
4y ago
There's this stupid dogma: tests are good, codebase without tests is bad. It is incredibly hard to fight the idea of "we need more tests" because of that. Anytime engineering team gets some freedom, tests are usually the firs
617.
▲
by
hbrn
4y ago
My guess is that TDD probably works well enough for external consultants or outsourcers, where you have to come up with really good requirements in advance. That said, if you have really good requirements, any methodology will work. A fun
618.
▲
by
hbrn
4y ago
A good example is the password rotation policy. It is still enforced by some of the standards (PCI DSS comes to mind), despite existing research that shows it worsens your security.
619.
▲
by
hbrn
4y ago
To be fair, I skimmed through your docs and did misread them initially: I thought you don't allow foreign keys, but you actually don't allow foreign key constraints . If you are still allowing JOINs within a shard, then I need to
620.
▲
by
hbrn
4y ago
A relational database without relations is an oxymoron. As folks pointed out, you also have to throw ACID away. So what's left of the original database, SQL-dialect? I bet that gets limited too. Look, I get it, you have to sell your pr
621.
▲
by
hbrn
4y ago
I'm unfamiliar with vitess, but what exactly is the achievement here? If you have a shared-nothing architecture, you can keep indefinitely adding nodes to get more throughput. You can easily do a billion qps if you wanted to. The downs
622.
▲
by
hbrn
4y ago
> It tests if you understand the subject well enough, and the "other person" well enough, to communicate it to that other person Interestingly, writing code not different in that regard. Too many developers think that it's
623.
▲
by
hbrn
4y ago
Unfortunately a lot of folks I met fall into this trap: I'm a senior engineer with XX years of experience, I cannot write bad code. Still haven't found a good way to convince them.
624.
▲
by
hbrn
4y ago
As the company gets bigger, it naturally starts doing more rituals. Some are justified, most are a cargo cult. The sad part is that since rituals are an inherent to a big company, following (and enforcing) rituals is synonymous to being pro
625.
▲
by
hbrn
4y ago
A good question to ask: why is it a part of our business process to do things that don't generate business value? The honest answer is usually: we don't really know what is the right process for us, but because we couldn't ad
626.
▲
by
hbrn
4y ago
This is a really good point. Engineers are constantly trying to predict the future, but ability to do so often does not depend on engineering skills at all. Often it is completely out of your control. Instead of trying to make code "ex
627.
▲
by
hbrn
4y ago
Couple of examples relevant to tech: Javascript being the lingua franca for all engineers eventually dominated the market. Not because it is a good language, but because everybody spoke it. Typescript movement can be viewed as vocal minorit
628.
▲
by
hbrn
4y ago
This discussion has already happened hundreds of times. I'll say that Mao and Stalin are leftists that killed way more than Hitler. And you'll say they aren't really leftists. The problem with these radical solutions is that
629.
▲
by
hbrn
4y ago
Capitalism might have it's downsides, but I came to think that software engineering problems are deeply rooted in human psychology. > Nearly all the rot and poison comes from one source It's tempting to think that all the world
630.
▲
by
hbrn
4y ago
This is probably not a common interpretation, but I've always viewed the idea of 10x developer as someone who delivers 10x the value. Not necessarily 10x lines of code or even 10x story points. 1x developer might look at the problem an
More ›