1,000 karma · joined February 20, 2017
>Untangling messy parts of the codebase, identifying and removing dead code, cleaning up build, deploy and monitoring systems - these tasks often feel overwhelming because they can overwhelm you, sucking up days for no real gain.
Those aren't the risks I'm thinking about when I'm worried about problems like this. Difficulty/time is not the concern. Unknown-unknowns are the concern.
Upgrading our NodeJS version takes about 10 seconds with Elastic Beanstalk on AWS, but we're not on the latest version, even though it seems to run without issue and our tests pass. Why? Because maybe it'll expose some race case that would only appear in production. And worse even, maybe that race case will affect a lot of people sometimes in an extremely hard to reproduce way. Maybe it'll break something that isn't apparent for weeks.
We had a bug where some SMS notifications weren't being sent in production, and it was hurting our retention metrics for a couple months before one of our engineers stumbled across it. It was caused by a maintenance upgrade of one of our very few dependencies. In a small company or on a new product, you don't have the kind of bulletproof reporting to know when something like that is broken - your metrics are moving around quite a bit by default.
Code that works and has been working for ages without issue is code that I am not interested in changing unless I absolutely have to. Leaving/avoiding code that hasn't been changed in forever is sometimes the best option to ensure stability.
This all being said, I agree that this worry can be carried too far. Like I said - I've gone back and forth on this. Fundamentally it's a tricky line to walk.
It just feels like forcing everyone to be an employee will box out a large number of happy part-time drivers who weren't too concerned with setting their own rates.
Sure - some (non-insignificant) portion of Uber and Lyft drivers would like to be employees. But surely some (also non-insignificant) portion would prefer to be contractors for Uber and Lyft and keep the legal protections that come with that.
These articles always make it seem like it's a no-brainer win for all drivers no matter what, but it's never seemed so clear cut to me.
What the parent comment said is probably true for the majority of cases - most people will succeed or fail due to external factors outside of their control. But you'd have to perform some impressive mental gymnastics to assert that Elon Musk just keeps getting lucky because of his environment, and not because of his own actions.
That being said, I think at some point you have to decide who you want to be. Elon Musk is an insane outlier in every way, and his life is the extreme opposite of stability and peace. I don't think that reality is unrelated to his success. So the parent has a point - accomplishment/self-improvement/growth aren't going to make everyone happy. Some people prefer stability over learning new things.
It doesn't make sense for me, but I can understand why some people want to live their life that way.
For example, installing a router and setting up a wifi network can seem like an unfathomably complex topic to an older person who's lived their life mostly via paperwork. But it's not that hard! And that person could almost definitely sort out how to do it with a little time and effort. You probably have examples of this in your own life.
So then, just flip it. That challenging thing that seems out of reach? Just assume you're the older person setting up wifi - assuming the thing is much more complicated and difficult than it actually is. It only seems so daunting because you have no exposure to that specific topic. If you just rip the bandaid and start learning about it a bit, you'll almost always discover that the individual steps to get started (for almost anything) are completely within reach.
For me, that thought process always gives me enough confidence to try. If I find out the thing is actually too hard, so be it. But usually, it isn't. Usually it's surprisingly easy!
I don't really have any concerns about whitelist/blacklist (I'm aware of the history) because alternatives are more explicit. Allowlist/Denylist seem strange to hear at first, but they're intuitive, so I'm fine with it.
With master/slave, in Djangos case[0], they replaced it with "leader" and "follower", which obviously have different meanings. Master and slave have a very explicit connotation, which is that one controls the other, and the other has to do everything the other says. Leader/follower does not fit the bill to describe that relationship. We're explicitly and objectively losing precision because we've decided that non-derogatory non-outdated accurate terms in the English language make some people uncomfortable.
And again, to really drive this point home, these are just words. They are not derogatory terms. They're used in accordance with their dictionary definition. This is like saying we should stop using "kill" to describe the termination of a program because people have been killed and that makes some people sad when they think about it.
I think this is a fair read on sexuality especially given the "spectrum" understanding of sexual preferences. If you're born 50% interested in men and 50% interested in women, you can very well choose to live your life (and identify) as a straight person or a gay person (or a bisexual person!).
That doesn't mean that others aren't born with a 0/100 ratio (one way or the other), though.
A food establishment forced to serve you might serve you food that's gone bad, a mechanic might not fully tighten the nuts on your brake pads, or any other variety of horrible things that people could do to harm you while leaving room for plausible deniability.
At least if they can legally deny service to you, you know that the ones serving you aren't a risk to your wellbeing. And to that end, I think it's a bit unfair to suggest that less money means there would be no businesses to serve that group of people. If every restaurant is discriminating, the singular restuarant that serves the less wealthy group would have plenty of business, simply due to the lack of competition.
The "pro-regulation" argument is valid with regard to a less commoditized market though, which is interesting. For example, I wouldn't want the only company that makes a life-saving drug to be able to legally discrimate who they sell it to.
It's a challenging problem and I certainly see both sides. My gut goes to regulations affecting large businesses but not smaller ones. It feels like there are probably some difficult edge-cases within there though.
This is an important point that those in disagreement with these kind of arguments often under-emphasize or ignore entirely. When a government makes it illegal to behave in a racist way, the racists don't go away, and they might even be amplified within those communities in a similar way to the Streisand effect.
If everyone in a community is racist, you can't simply make it illegal to be racist to fix the problem. They have to make that decision on their own - anything else is fundamentally authoritarianism, which doesn't have a great history of long-term success.
The title is a dishonest representation of the content of the article. That's what I take issue with. Nothing more, nothing less.
I think I understand what you're aiming at. I think I would agree with you if the title wasn't so rigid, but it feels to me like a significant claim that extends beyond the here and now reality.
This article is not about the institution as a greater whole. It's not about the bigger picture. It's about the Memphis PD. That's what's on the table here, and that's what the title should make clear.
Sensationalism is the concern, not criticism of police.
I'm not certain it's fair to compare standard clickbait to a title on NiemanLab - it seems like you agree with me that it's a not a positive thing. I think we've definitely seen increasing amounts of this behavior from more prominent publications, but I wish we wouldn't.
I'm sure other people will come forward with similar experiences, but they haven't yet. It seems like a dangerous approach to assume the worst until then.
> Mark McCarren, a New Jersey federal prosecutor involved in the case, said Rosenbaum indicated that the transplants he brokered took place at more than one U.S. hospital and that the hospitals were duped and were not in on the scheme.
If exclusively New York-Presbyterian were potentially involved in pushing the organ black market (for example), and the title still said "US hospitals", this would be a fair comparison.
If a ring of doctors were caught illegally selling organs, we wouldn't title an article "Doctors have been selling organs for years". If bank tellers in a specific city were taking some money off the top of deposits, we wouldn't write "Bank tellers have been stealing money for years".
I'm sure there are some national issues with policing in the United States, but most police organizations are local. It's very unlikely that every local organization is bad, and even if they were, it would be very unlikely that every local organization is bad in quite the same way.
I don't think headlines like this help us balance the discourse. There's no concerted effort by police nationwide to spy on black reporters and activists. This is about a problem in Memphis, Tennessee. The content of the article doesn't imply anything beyond that. The title is extremely sensationalized, and many people will only read that far.
- Avoid rules and tools
Until you understand why someone came up with them originally. My biggest blind spots came from reliance on things like React Dev Tools. Every time I had to sort out a bug, I would start poking through React Dev Tools immediately without thinking, find the issue, and then patch it. The closest thing I can equate this to now is using a GPS to navigate. You'll get to your destination, but you won't learn the roads you drive on every day. Throw out the GPS, and you find pretty quickly that you know the roads, which is a faster + easier way to navigate. Same thing with debugging. You can still use the GPS once you know the roads if you need to get somewhere unusual, but you shouldn't usually need it. Same thing with debugging tools. Big time saver.
Rules are in a similar camp. Strict global rules are always bad. "Don't repeat yourself" is a horrible as a strict law in a codebase. I repeat myself all the time intentionally to avoid prematurely abstracting things. That being said, there are times it's absolutely mission critical to abstract something or risk massive difficult-to-unfuck technical debt moving forward. Knowing the "spirit" of these rules (which is difficult to garner via anything other than experience) is incredibly important in using them effectively, which in turn also saves a ton of time.
- Use a tool from your toolbox
As much as you can, don't make/use new tools. The law of the instrument[0] can actually work to your benefit in engineering if you use it correctly. The fewer tools in your coding toolbox, the more proficient you'll be at using those tools. The bugs that arise from that limited set of tools are more predictable and become easier to avoid and easier to diagnose. Your code ends up naturally looking more consistent when you're trying to treat every problem as if it's from the same set of problems (and in my experience, very few problems are not from a very small set of types of problems). The less unique problems you're solving, the less time you're spending learning how to use new tools. This effect compounds as time goes on, and ends up being incredibly powerful over time.
- Be even more explicit than you think you need to be
Implicit functionality is the beginning of the end of any codebase. If you think comments are necessary, the code is too implicit. If you have to ask the author what the code does, the code is too implicit. Code should make intuitive sense like a great UI makes intuitive sense. Non-engineers with an understanding of your product should be able to traverse your folder structure and find something if they want to (most members on our team are able locate and modify copy in emails/notification/interface files without much trouble). But it's not for them, it's for you. Trying to remember what you did on a feature you built 6 months ago is borderline impossible, so don't try. Write it so that you don't have to, and that'll guarantee other engineers working on it at any time can dive in without talking to you about it first. A lot of time is saved in not having to bring yourself or anyone else up to speed on anything.
- "Think slow"[1] about everything
Your brain is going to want to "think fast" all the time. Brains weren't made to code, so they're really bad at knowing when to rely on instinct and when to consider something more thoroughly. It likes to think fast more than it likes to think slow, so you'll end up coding instinctually if you're not intentional about it. That will result in code that looks like the most significant project you worked on before this one, and that code probably doesn't make any sense in whatever you're coding right now. So you have to force yourself to think slow about literally every single little detail of the code you're writing at first. Every styling detail, every filename, every semicolon, literally everything. Consider it, make sure you understand exactly why you're doing it, and make sure it makes sense to you in this specific scenario. Be able to explain why you do everything the way you do.
This is immensely tiring up front, it feels impossibly unsustainable. And it would be if you had to do it every time you wrote code, but you don't. Once you understand exactly why you're doing each thing you're doing, it's incredibly quick to understand if it still makes sense in each following scenario. Once you've gathered most of the reasons for the way you write code the way you do, the process starts to fade into the background - you can start to "think fast" again. And even better, you've trained your brain to stop and "think slow" when you don't have an explicit reason for doing something a particular way, thus preventing any "relapse". It's locked in. Engineers who have this figured out can avoid writing unpredictable/difficult-to-debug code with clinical precision and save themselves days of pain per month.
I think this last step is actually the core of "having the right habits from the get-go". I think every great engineer can explain every tiny little nuance of why their code is the way it is. I don't think that comes from being a great engineer, I actually think that's how you become one in the first place.
My pet theory is that this list is part of how one becomes a so-called "10X engineer". You don't have to code 10X faster, you just have to use clever compounding tricks to spend 10X less time on the noise in between.
After spending some time working with him, I was convinced I was simply being lazy and started forcing myself to do all of the "clean code" steps that I was ignoring in lieu of speed. I slowed down for a month, maybe two, but then I was back up to speed and writing code that I could actually feel good about.
I haven't quite caught up to his pace, but I've got the second best thing in having him on my team now.
It's shocking how sure I was that I couldn't write clean code as fast as I do now. I'm lucky to have met someone that was able to teach me by example - I'm not sure I would have ever corrected my habits had I not worked next to someone who had.
Huge difference between something like "The Ping" and deciding not to rewrite that original contractor code.
Code can be decently sloppy, but there's likely a strong correlation between good code and good startups. Not because the code made them a good startup, but because the good startups are good at most things.
Many startups will do fine with a rough codebase, and obviously you should value the code accordingly (if it's an API as a service, highly, if it's a physical product with no software component, not so much). But be wary of any startup that's close to so bad you worry it might fail. Good founders will rarely let it tip so far to that side of the scale.
Obviously there are loads of exceptions to this rule. But I think if you want to be a founder of a software driven startup or you want to find a great place to work as a software engineer, aim your expectations higher than feels reasonable and you'll probably land at a decent medium.
Certainly not a showstopper though, passing a URI is easy enough!
So I agree most probably just get discouraged and give up early. But I can easily see 9 long-time "zombie" YouTubers for every channel with a big audience.
I think the more powerful benefits are definitely hiring and having a team that can work on both sides (and in that regard I think your points are perfectly reasonable), but there are definitely some more direct benefits in our case.
[0]https://support.stripe.com/questions/passing-the-stripe-fee-...
In this sense it's essentially entrepreneurship. The founders who are simply not doing a good job don't always realize it. Some people will continue their efforts for years without knowing it's their own inability holding them back.
There's definitely things to gain from talking to the author of the project, but seems a bit reaching to suggest they wouldn't have been able to do what they did without talking to him. And it seems like a particularly pessimistic read to assume they were just lying to him outright to pull from his experience. Very little to gain from being a shark in this scenario, tons to (potentially) gain from acquiring an existing package manager. Gotta follow the incentives.
It's also worth mentioning that he mentioned the name similarity in his post in this way:
> When I showed it to my wife, the first thing she said was, “They Called it WinGet? are you serious!?” I didn’t even have to explain to her how the core mechanics, terminology, the manifest format and structure, even the package repository’s folder structure, are very inspired by AppGet.
He did not go on to mention that his own name was (nearly certainly) inspired by apt-get (stylized as AptGet on Ubuntu[1]). Implying he was the originator of the name [X]Get for a package manager seems aggressively dishonest, to the point that it throws his entire side of the argument into question for me.
I haven't looked thoroughly into the code, but this feels like someone who was expecting something to come out of his hard work and is (understandably) bummed it will now likely amount to nothing. I have trouble putting much blame on Microsoft for that.
https://help.ubuntu.com/community/AptGet
I wonder if he mentioned his name was inspired by the extremely more well known and 22 year old default package manager in linux that happens to be called apt-get.
I mean honestly if he's saying that as justification in his blog post, I'm immediately off his team. That's insane. Obviously a layman would think the name was ripped off if they didn't know about apt-get.
I would guess there's something in this extension that looks very similar to suspicious activity (regardless of whether it is) and some light refactoring would resolve the issue of repeated flagging.
Not suggesting this is right or good, but it's probably less time consuming and more effective than emailing back and forth for two years.
It wouldn't surprise me if this is often the case for people who feel they need more sleep. Having proper blackout shades and full silence (via ear plugs or otherwise) during sleep allows me to sleep a significantly shorter period of time as measured by however long I end up staying asleep. I typically don't use an alarm, so it's fascinating to be able to notice that natural difference in how long my body seems to need before booting back up.
Interesting anecdote - the pandemic is what triggered my awareness of this effect. When I'm at home alone sleeping (typically into the late morning, I'm a night owl), my dog will sleep with me. When my girlfriend started working from home from early in the morning, he would wake up with her and bark loudly at the occasional activity outside. I suddenly couldn't wake up on my normal schedule, even though I wasn't actually consciously woken up by the barking. The thought occurred to me that it could still be the barking and something related to the depth of the sleep, so I tried ear plugs + having my girlfriend close the bedroom door. Suddenly I was back to sleeping normal hours. Years of strange sleeping pattern problems were explained in an instant.
I didn't make it through the first chapter before I started looking into the accuracy of the claims he was making. Some of them were clearly bananas.