HN user
No, it is more accurate to say that leadership at Cloudflare does not know what they are doing nor have they known what to do for a good decade now.
I think we're starting to see that across the entire industry. Leadership is easy when times are good. The job has gotten very hard.
I read The Cuckoo's Egg only a few years ago (in my 30s) and it's an absolute delight. Easy to understand if you do any sort of linux administration, and really demonstrates how lax things were and how far we've come in terms of cyber security.
AWS Lambda supports shipping your Lambdas as containers now. Very nice experience.
Yep. I've found that the ticket or tech debt isn't important until it becomes on fire and must be fixed ASAP. It doesn't matter that the possibility for the bug to happen has existed for 2 years, the organization doesn't find the investment worth it until it's burning down the house.
about 40 and growing
Having dealt with all of these in production, I can tell you the strategies I've used to combat these things:
1. Solid code reviews. Anyone of our developers can halt a code review for any reason. We require 3 approvers on each review. Sensitive areas require reviews from people familiar in that area. We also have tooling that allows us to generate amounts of test data in dev that is similar to prod loads. This helps us catch a lot of time bombs.
2. Feature toggles to decouple deploy of code from release of code. This allows us to test our code in production before turning it on for customers. It also allows us to slowly rollout a feature and watch how the code behaves. This also gives us a kill switch to turn off the code if it is bad.
3. An incredibly robust testing pipeline. It takes about 50 minutes from commit to production deployment. We can also deploy previous containers very quickly for situations that require it.
This doesn't solve all of our problems. Some changes cannot go behind feature toggles (DB migrations, dependency upgrades, etc). But we do pay a lot of attention to design and rollout plans for database migration changes and such.
All of these things come at an extra cost to us, but it allows us to move quickly when we need to. But we're in a lot better place than we were when we were trying to do weekly releases. We have a good mix of team experience (sr vs jr) - and have a lot of discipline in our software engineering practices. We still have problems like I said, but these strategies have greatly improved our ability to deliver software.
I've worked at a lot of places like this, and I'm continually surprised people enjoy it.
That's been my experience as well. When a manager says they try to "shield you from the bullshit" it's just a lack of transparency that leads me to making my own (often worse) assumptions.
I once read an account of someone that took Ibuprofen on an empty stomach and burned a hole in their stomach lining. Since then I always eat something first.
Will the politicians still ignore the desires of its constituents vs special interests? No question.
It seems like none of this actually matters until we can solve that problem.
You have to really provide valuable, quality content for organic SEO
This is the key. Google wants to make sure your readers are getting their questions answered. SEO is constantly changing, but high quality and valuable content will always be king.
If you call a script that does a few seconds of processing, and keep calling it, yes it will take down the server...
aka, exploiting the script loading behavior...
My network carrier already does some anti net neutral things that I like.
What happens when they start doing things you don't like?
They have to do more than just accept the comments.
Or what?
There's no one enforcing rules in this administration.
Fantastic response.
~4 hours from report to release.
It's hard to move fast and have a well engineered product.
You should check out Rocket League.
So what's the big picture here? We've suspected for years that football leads to brain trauma. Does that mean the NFL should shut down? Should they continue to operate as normal?
There have been efforts recently to make the game safer for players, but the amount of concussions and injuries seen every season don't seem to be decreasing.
Can you make the game "more safe" without drastically changing the game? Any game played at this high of a speed, with this strong of players is going to have some inherent danger to it.
Do we just need to make the effects more widely known and understood by the players, maybe treat football like smoking with warnings printed on the outside of helmets? Anything less than that and you run the risk of not making your point.
Should I feel bad as a fan for watching football? Is it any worse than buying clothing made by child labor from a third world country?
Yeah, let's not feel bad for the airlines. They do it to themselves.
It sounds like he's doing quality work, really. There's no secret. He claims to have a GREAT copy writer for his niche and provides them with the exact info they are looking at google for. Do that for a few hundred well written articles and any site will rank well too.
But a google algorithm change could definitely crush his income.
Yeah... this seems like a really fast way to lose customer trust.
I'd love to take you up on this offer as well... sdm350 at gmail
Solutions usually come from people who see in the problem only an interesting puzzle, and whose qualifications would never satisfy a select committee. -- John Gall in Systemantics[1]
A very short read, and quite interesting. It touches on a lot of the same points already made in this thread (people will game metrics, etc). The biggest argument that the book makes that is trying to set up a system to accomplish something will cause the system to do everything but accomplish its goal, which leads to the above quote. You can't set up a system to achieve a goal, only set up an environment that allows the goal to be achieved.
There are tradeoffs to all software.
I use lastpass with a yubikey for 2fa and I feel safe enough. I briefly looked at other password managers when I was evaluating lastpass, but convenience won out for me. I haven't looked at moving out of lastpass, but 3 years ago no other password manager came close to the mobile and platform support that lastpass had.
I considered keeping my passwordDB local, but the inconvenience of needing it and not having it wasn't it worth it to me. Do I know I'm making a tradeoff? Yes.
I also have a nasty habit of setting things up on a local server and then never updating it. Instead I decided that lastpass was worth the $12/year so I wouldn't have to manage anything locally.
So while lastpass may not be perfect security, I'm a lot better off than I was three years ago when I used the same few passwords everywhere.
It also helps me share passwords with my wife, so that's nice.
You underestimate how lazy and unmotivated most people are.
I feel like all of this just comes back to judgement calls. You can't pick technologies in a vacuum, and you can't generalize technology choices.
It's not very fair to make these claims without knowing all of the details around the situation. Microservices CAN be a pain, but it might offset a greater pain of trying to coordinate a monolithic deployment. It depends on things like team size, budget, and technology available to you.
This is where I see the disconnect between employers and most developers. "Programming" isn't a job. Your employer doesn't pay you to write code. They pay you to solve problems. The good employers don't care what tools you use to solve the problem, just that you solved it. The bad employers will force you to use technologies and buzzwords that probably don't apply to your situation. You should be able to defend all of your decisions and have good reasons for them.
On the flip side, not everything you try will work - that doesn't mean that it's a bad option, just that it didn't work for your situation. You don't need to have a redundant low-priority memo system because you don't get enough value out of it to justify the overhead of maintaining it.
If the taxi even shows up at all...
It sure is, but it still happens a lot.
Being able to remember and implement those algorithms in under 20 minutes on a white board is not applicable to programming at Amazon, Facebook or Google at scale.
But Facebook doesn't get any cut of a sponsored post. (meaning a company paid an individual to write a post)
If the service won't be responsible for incorrectly validating the ID, what's the point? Seems like you'd be paying for nothing, really.