hbrn

35 ms·

391.
by hbrn 4y ago
And yet it strongly correlates with tons of other meaningful metrics, like work success and income.
392.
by hbrn 4y ago
Plenty of bad advise here. It sounds like you already made up your mind about this person and came here to enforce your confirmation bias. Since I've been on both sides of this story, I'm going to be the devil's advocate. &gt
393.
by hbrn 4y ago
> basic medical definition of dead, which is basically no heartbeat This is an extremely reductive statement. There is no unified medical definition of death, precisely because it's a highly controversial topic. Closest to what you&
394.
by hbrn 4y ago
See how casually throwing in the word "undisputable" in a discussion of a controversial topic triggers a dispute?
395.
by hbrn 4y ago
> Scientifically, "a human" is an alive organism of the species "Homo sapiens." You seem to be conflating linguistics with biology. If we agree to change the definition of a word "human", this isn't goi
396.
by hbrn 4y ago
> Go mutilate your plan so that you have a Real Deliverable every five working days If we're talking about web development - yeah, pretty much. IME, most projects where team lead was not willing to "mutilate" were a disast
397.
by hbrn 4y ago
1. You will never be able to fix all bugs. There's plenty of bugs in your software right that that you are simply not aware of. 2. Bug fixing has diminishing returns and exponential costs. If you accept these two axioms, Zuck's qu
398.
by hbrn 4y ago
> The Jam dev team recently shipped a major refactor of all the state handling in the app a few weeks ahead of schedule To me that doesn't sound like a thing to be proud of. 1. You approved a plan to have a refactor that lasts sever
399.
by hbrn 4y ago
None of these tips are specific to remote. None are insightful either. Write comments, plan better, do things better. Seriously? Just another google spam blog post to drive traffic. Btw, if your team goal is "ship to production" (
400.
by hbrn 4y ago
People seriously need to stop with this idea that small frameworks are only good for small projects. The counterintuitive reality is that the best tool for big project is a small framework. The bigger your project is, the more likely that f
401.
by hbrn 4y ago
Why would you want to talk to people who are wrong? Sometimes I don't care which political party the barista voted for, I just want to get my coffee. People and programs are never perfect. Type checked program is not guaranteed to be c
402.
by hbrn 4y ago
Not every team has eternal policy debates. Eternal debates indicate a deeper problem with the engineering culture. I'd rather have that problem become visible so that I could address it, than keep it hidden under a pile of irreversible
403.
by hbrn 4y ago
Such policies should be defined by the company, not enforced by the language. Even in static languages world, a lot of projects allow dev/nightly builds to be unstable. Which is literally what you're talking about: checking in pro
404.
by hbrn 4y ago
> If you have a good set of unit tests that test all observable behaviors of a system means you can optimize the logic inside and constantly rerun those tests to make sure it's not broken This is a naïve utopian world view. The word
405.
by hbrn 4y ago
Maybe some of them were synesthetes?
406.
by hbrn 4y ago
If you can tie these to automated alerts that's great. But there's no need to automate everything, "Do things that don't scale". I make these comments searchable (they always start with "# TODO: "). And th
407.
by hbrn 4y ago
Here's a simple solution: change your comments (and your mindset) from vague "will fix it later" to a more specific "fix once <trigger condition> occurs". Ideally trigger condition is tied to automated alerts
408.
by hbrn 4y ago
I used to share the same example against obsession with DRY. But it's a bit more nuanced. Both options can be valid. DRY is a tangential topic, the main goal should be to keep your code as close to your mental model as possible (also k
409.
by hbrn 4y ago
> team decided to have a shared on-call rotation. They would cross-train. Each team makes a procedure book that covers any first-on-the-scene tasks for most alerts and issues. Shared on-call is a section I strongly disagree with. Shared
410.
by hbrn 4y ago
But the on-call footprint is also smaller. Ideally up to a point where most of the problems don't require immediate response, so most teams won't need a 24/7 on-call. I think the issue is that first people introduce 24/7
411.
by hbrn 4y ago
Performance is a feature. Unfortunately, it's not a feature that masses deeply care about, good enough is good enough.
412.
by hbrn 4y ago
> you end up with both the old monolith and new microservices, the monolith never gets fully broken up, and now you need to support two development paradigms forever. It's not a bad thing, it's actually a quite pragmatic approa
413.
by hbrn 4y ago
Doing things incrementally almost always feels more expensive. And sometimes it is. But it is always a net positive in the long run. When you're starting those "replace X system" projects, what you're not anticipating
414.
by hbrn 4y ago
Can you expand a bit on complexity part? How exactly serverless reduces it? The only thing that comes to mind better isolation between parts of the app, but this could be achieved with any architecture if done right .
415.
by hbrn 4y ago
That's not how open source works. Open source projects don't just float by themselves in the open source cosmos. There's still people behind them. Maintainers and major contributors are from Facebook. You can't "jus
416.
by hbrn 4y ago
What makes you believe peace would be the only natural outcome? Putin turned out to be an authoritarian dictator with imperialistic beliefs, peace is rarely an option with those guys. Russia being a part of NATO could allow them to invade n
417.
by hbrn 4y ago
I wish it was that easy. "Of course it does: engineers will be more productive, we'll have less bugs and better performance. {TECHNOLOGY} has been around for {N} years and getting more and more traction. Do you want us to be ahead
418.
by hbrn 4y ago
> In not so many words, it meant that Russia would have to join the transnational gang as a foot soldier (Estonia) rather than a capo (UK) let alone a boss (US). And what do you think makes US and UK above others? Here's a hint: US
419.
by hbrn 4y ago
Any "architect" joining the company and pushing for drastic changes like that is either an idiot chasing the hype, or a malicious actor trying to boost their importance. Good news: your gut feeling is correct. Bad news: you will l
420.
by hbrn 4y ago
> Where I come from, truck drivers own their own trucks and are pretty happy about them And you're free to write your own software in whatever way you want. But when you're working for a business, the end goal of your code is t

More ›