wpeterson

If they’re optimizing full table scans of 20M+ rows, they probably want an optimized column oriented DB or a data warehousing option like Snowflake.

100% this. Only use containers for remote execution: CI, staging, production. Run native code locally. Manage dependencies and isolate project environments with NIX.

Ugh, what a loss for this community and the Ruby community.

This should be worthy of a Hacker News black banner today.

This resonates with my experience.

You can tell the author is mostly worn out not from long hours or challenging technical work, but from fighting against the overwhelming inertia that faces building/shipping anything. It’s exhausting.

This article is dangerous in romanticizing the “not invented here” culture at many big tech companies and seems rooted more in the 90s than present day.

The world of open source tooling and easily re-usable SAAS offerings means everyone has access to the best tools, whether you’re a small startup or a big company.

Anyone who longs for internal, corporate tooling baffles me when they can use things that actually have polish, user experience and likely better implementations under the hood.

Companies should spend their time/energy building things unique to their problem domain, not weak also-ran corporate tooling.

I spent two terrible years in Mountain View for a work opportunity I couldn't turn down and it was horrible. Our rent went up 20% during that time. It felt completely unsustainable, ecologically and financially to live there.

We moved back to Boston and have been overjoyed with fleeing the peninsula. I'd still love to visit north of San Francisco of south of Monterrey on vacation but they literally couldn't pay me enough to live there.

Hey buddy!

Reading all the design and discussion I was. Rey curious how you structured things at a brass tacks storage level.

This may be a confusing thing, I suspect Instacart may get volume discount from stores for bringing the extra business.

So this markup may be based on discounted cost instacart pays, not necessarily what YOU would pay at the store.

Still think it's a crazy premium, but I enjoy grocery shopping.

ezCater | Boston, MA | ONSITE | Fulltime

https://www.ezcater.com/company/about-us/

ezCater is the #1 online marketplace for business catering in the United States – a $21 Billion market.

We’re backed by Insight Venture Partners and have been growing 3X per year, and we want to grow even faster. We’re always looking for highly skilled engineers to help build our web and mobile apps, while riding this rocket ship of growth.

At ezCater, technology is valued as a differentiator and also as a key component of our success. We push ourselves everyday to better the codebase, improve performance, and deliver an amazing customer experience.

Senior Full-Stack Engineer: https://www.ezcater.com/company/apply/?gh_jid=78210

Senior iOS Engineer: https://www.ezcater.com/company/apply/?gh_jid=78582

Much better quality of [everything but weather]

I've been living in Mountain View for several years, but we're moving back to Boston in a month.

We can get a house 3x as large for 2/3 the cost and have a much better quality of life.

RubyGems.org has their own web server and web services for publishing library versions and to allow the clients to fetch libraries and query the universal registry.

It's totally reasonable to host your code on github and to build a package manager that loads the content of a package from it's github repo.

What seems insane is to use a single github repo as the universal directory of packages and their versions driving your package manager.

There's a reason rubygems has their own servers and web services to support this use case for the central library registry, even if the source for gems are all individually projects hosted on github.

The problem with performance optimization is that if you obsess with optimizing code well outside the critical path, it's often wasted effort drowned out by larger latencies.

If this code was part of a web application, the I/O bound latency of backend/persistence calls will almost always outweigh any CPU bound processing time.

So they may have made this method call 14x faster, but how much latency were they really shaving off their average request? I would be surprised if it were more than a rounding error.

I don't understand why people think serving a blank or janky page to your users is OK. There's no reason not to serve a completely rendered page from the server side and only enhance the UI with client-side rendering and navigation when there is a user action or other event after page load.

The test case used text in a table, which is an extremely poor example. Modern designs use a lot of images and CSS, where presenting a complete document and stylesheets allows much faster time to render than client-side rendering followed by fetching all those assets and applying styles.

The pain for your users is multiplied by the slowness of mobile devices/networks and the complexity of your UI's layout to render.

Outsourcing functionality or work makes a lot of sense for things that aren't core to your business. If you're building a web or mobile app, backend services should be core to your business.

It's a very different thing to write a web application or web services that can run on many hosting platforms than to give responsibility for your entire backend to a service provider.

This is a nice PR piece but building operational systems in a marine environment usually requires hardy engineering, equipment, and constant maintenance. It's not a friendly environment.

I can't see the benefits here, if they want water cooling colocation with hydro-electric or other freshwater flows seem much better.

I grew up in Natick, surprised to see this as a codename.

Is there any connection or just a weird coincidence?

Viktor Frankl wrote about understanding human suffering as the one constant in all our lives and the one thing that binds us all together:

“To draw an analogy: a man's suffering is similar to the behavior of a gas. If a certain quantity of gas is pumped into an empty chamber, it will fill the chamber completely and evenly, no matter how big the chamber. Thus suffering completely fills the human soul and conscious mind, no matter whether the suffering is great or little. Therefore the "size" of human suffering is absolutely relative.”

It's a good exercise to enumerate and guess the dramatic maladies of most people around you, but even that belies the larger truth of all of our shared suffering. It's the human condition.

It's great to see an attempt at mobile responsive design. This looks like a good step in the right direction. Here's hoping for even more work to make the site work on mobile.

As a tech lead, you're a mixture of manager and lead engineer.

As a manager, you should be clear to represent your team in public in terms of giving everyone credit for success and taking personal responsibility for failure yourself.

As a manager, you need to balance what technical work you assign yourself - it should be a mixture of interesting projects and valuable scutwork. Don't be the guy who takes all the good work for himself and only delegates work no one wants.

As a lead engineer, the most valuable thing you can do for your team is to focus on helping them start things and finish things. Folks do well in the middle between those two, but most of the wasted time and frustration comes from not knowing how to begin working productively on things or getting lost and not knowing how to wrap them up successfully.

As an architect, be able to quickly change altitude when explaining the behavior of the system or code that you're responsible for. When debugging an issue with a developer, be able to dive deep into the technical details. When explaining a schedule or cost estimate, be able to talk about the system at a high level to the CEO.

Averages can be useful, percentiles can be more useful.

However, the biggest asset in useful monitoring is focusing in on the right events and data. Is an average latency across all of your requests useful? Probably much less than averages per API or page.

Another victory for the mobile-web over a native app that didn't need to exist.

Once upon a time, there were multiple repos and multiple tools for different jobs.

Then Twitter grew to thousands of engineers, many of whom were from Google. Now everything is being converted to enterprise Java in a single, monolithic repo.

Is that an improvement or just bureaucratic standardization and cargo-culting from engineers raised in the google3 monolith?

Interestingly enough, LukeW is now doing product/design for Google.

When you have separate repos, the external code and integration points remain relatively static. IE: You may consume an API, but it's versioned/snapshotted at a given version.

With a monolithic repo, especially without development branching - everyone is running against HEAD all the time. So while you are developing your component, everything else is changing around you.

Perhaps a better way of framing this is:

Distributed repos make writing software easier.

Monolithic repos make testing and running software easier.

Large monolithic repos are an artifact of scale where the individual cost of lost productivity in development is worth the increased performance at deployment and testing.

Architecture is just dividing pain into different buckets.

Large repositories are painful, as each developer bears the pain of integration every time they have to make a change to the repository integrating with all of the other code.

Small, distributed repos are painful when change accrues in larger increments and must be resolved at release/integration time.

As a developer in one of the largest monolithic repos in the world, I feel the pain every day of that pattern.

The weather is awesome and it's a beautiful area.

However it's more crowded and expensive than many cities without any of the benefits of living in a proper city. The housing and services are throttled despite an ever increasing demand of more tech workers arriving. Prices go up and quality of life goes down.

+1 for working remotely in Mountain View.

As a new resident, I wish I were living somewhere else and working remotely.