nthj

So, a manager?

The browser is perfectly capable of stuff like project management workflow apps when you’re not shipping 22MB of useless abstraction layers in a runtime language.

This argument fails to include at least 3 factors:

1) A slower infection rate prevents or at least helps with “flattening the curve,” that is, avoiding overwhelming health care systems, which impacts both COVID and non-COVID patients

2) A lower initial viral dose seems to lead to better outcomes (lowers mortality rate)

3) We are seemingly within reach of effective vaccines

One of the hidden assumptions in "hire people that write well" is that people who write well would also likely have high reading comprehension skills. Or, the inverse—I find that the ones who want to jump on a quick call vs. writing out their request are the same people who seemingly don't read the documents I produce.

Quickly reading and understanding almost everything I can find—code, plans, schedules, calendars, strategy, memos—is how I excel in remote environments. It's not a huge time commitment, 20 minutes a day, but I have the organization's "state" modeled in my head, which helps me identify dependencies and potential bottlenecks before they're surprises.

I agree with this. I don't think I could argue it's table stakes, but having 32GB and being able to run 3 external monitors, Docker, Slack, Factorio, Xcode + Simulator, Photoshop, and everything else I want without -ever- thinking about resource management is really nice. Everything is ALWAYS available and ready for me to switch to.

The immunocompromised and the economy get a benefit if we get to 70% vaccinated; I get a benefit for myself just by getting the vaccine.

I’ll allow that there is seemingly a significant portion of the population who believes they don’t personally benefit from a vaccine, but your comment said -everyone- is incentivized to shirk: that’s just not true.

While the government absolutely should have fixed the incentives, I am a little puzzled why a huge private equity firm or a Bill-Gates-like figure didn’t fund more N95 machines when the government failed to. (Or at least, I haven’t heard that anyone has.) $25-100M for machines to help get the whole economy back on track seems like an obvious move on both economic and humanitarian grounds.

Absolutely:

* Avoid network and JSON serialization overhead

* Perform larger refactorings or renamings without considering deployment staggering or API versioning

* testing locally is far easier

* Debugging in production is far easier

* Useful error stack traces are included for free

* Avoid (probable in my experience, at least in larger security software organizations) dependency on SecOps to make network changes to support a refactoring or introducing new components

If an organization is or will pursue a FedRAMP certification, as I understand it, that organization must propose and receive approval every time data may hit a network. Avoiding the network in that case may be the difference between a 50-line MR that's merged before lunch and a multi-week process involving multiple people.

Always provide options and a recommendation.

As long as the markets value ARR at a 3-10x multiple, subscription businesses will continue to appear :)

I agree, and this is why I mentor my engineers to replace the phrase technical debt with specific qualities that are impacted by technical choices:

* Resistant to future change

* Won’t scale past x units

* Prone to operational issues

* Exposes us to liability or compliance risk

* Increases ongoing maintenance costs

Any large initiative to replace "crap" should map to specific product quality attributes that stakeholders and leadership buy in to, and ultimately be justifiable back to COGS or churn mitigation. In this way, objectively, a system can be $10M better because it e.g. closes $10M in customer tickets.

I’ve been on several airlines over the past few years and not once have I been charged to check my bag at the gate once they ran out of space. Sometimes they ask for volunteers.

Sounds like you and I have similar approaches, and I just have more CRUD to manage in my case. For e.g. payment processing endpoints, I use Golang. Managing 3rd party SDKs is nicer in Golang, imo.

I also heavily rely on Postgres views, which ActiveRecord just sees as read-only tables, so my Rails code can still call `user.api_data_entries` without any ORM wrangling.

Oh I agree, I lost a lot of nuance with my trite 1-sentence summary. Shiny is mostly good judgement, good taste, careful organization and a lot of sweat resulting in well-crafted CSS.

Especially in the past few years, as browsers have implemented a lot of animations and scaling in CSS which offloads to the GPU. You don’t want JavaScript/CPU doing that math anymore.

Component-based JavaScript frameworks “force” us to organize our CSS in the same way outlawing cars in favor of bikes bikes ensures everyone follows the speed limit.

If you’re going for speed of development, it’s hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers. It’s also very opinionated (convention over configuration) which helps me just build out features rapidly without making thousands of pointless decisions.

I am not opposed to React for like, a calendar application, or a particularly complex part of a web app, but most web apps have 90% CRUD and 10% shiny.

And with well-tuned SQL and turbolinks dropped on, Rails pages load in 30-60ms with no page refresh.

They talk about reducing memory allocations. My guess is the rest of the app is very large and they’re benefiting from not sharing memory and GC with that.

Of course, everything you said is true for a small-to-medium sized Rails application.

They likely could have explored a separate Rails app to meet this goal, but then they have to maintain the dependency tree and security risks twice. And if the Rails core refactors away any optimizations they make, they have to maintain and integrate with those.

There’s definitely some wiggle room and a judgement call here but their custom implementation has merit.

This statement seems to assume wealth is a fixed constant, which it isn’t. Theoretically if it was believed a company will create a thousand trillion in wealth it could be valued against that.

http://www.paulgraham.com/wealth.html

This has historically been true, but one major variable has changed: executives have been forced to see what their companies look like with remote workers. The land and housing markets look very different when a significant percentage of people aren’t paying for a shorter commute.

C. S. Lewis taught me newness is no virtue, and oldness is no vice. I’ll leave the answer as to why I’m quoting a writer on religion in response to an anecdote on developers’ quirks about their environment as an exercise to the reader.

Thank you, that makes perfect sense. I hadn't considered optimizing for location. I just saw in the settings where I can choose a roaster, so I reduced the selection to those much nearer my location. And I did indeed receive an email about a replacement—very slick and very appreciated.

I think this is why you need a very senior engineer overseeing your MVP.

Before MVPs were championed, companies would create a full-fledged project management suite with 50 database models and release it to crickets.

An MBA and a junior engineer define an MVP as “You can log in, and add todo lists and check them off.”

A senior engineer defines that same MVP as “You can log in, add todo lists, check them off, delete your account, and if the server crashes or we’re hacked, we have backups for 30 days.”

Or in other words with an MVP you still need to complete the 80% of the iceberg the MBA and junior engineer can’t see, but you don’t build the whole iceberg at once.

Point taken. I have been buffering supplies since February, and anywhere else I can support shipping delays with a bit of additional planning, but coffee and eggs are I think the two places in my lifestyle still coupled to just-in-time delivery. I have caffeine supplements stocked as a backup, but that misses out on the ritual.

It’s been an interesting year, kind of like playing Factorio but in real life.

Hey, newish customer here. I’m in the 10%—my bag is somewhere halfway across the country, and USPS hasn’t posted an update in a week now. I’ll need to supplement with Instacart, which kinda breaks the abstraction.

I totally appreciate that USPS isn’t in your control.

Cost isn’t really a constraint for me, but running out of coffee is. I just checked and I don’t see a way to switch to FedEx or UPS for an additional charge. Is that something your team is exploring?

Right, I’m a big fan of the monolith, but that doesn’t preclude anything you just described. Absolutely use RDS. Absolutely use S3. Even on a low traffic app.

But what I see a lot of is engineering teams making sweeping consistency judgements. RDS and S3 are great as services, everything should be a (micro)service. Our calendar feels amazing as a React SPA—everything should be built in React.

No. 90% of a product is just CRUD to support the 10% of magic that customers really value. Ship the 90% as a monolithic CRUD app and spend those cycles on that 10%.

Most productive refactoring carries forward from a more effectively designed data model. There can be value in pushing code around but often a lot of that can be subjective, which this thread has discussed.

Even big corporations are open to refactoring when you put it in the context of data integrity and consistency (foreign keys), because data inconsistency causes tickets which cause churn which is a number the CEO reports to the board.

Every time I’ve seen an engineering organization run with rewriting the whole thing, they/we figured out 6 months later a more effective data model. That’s usually the root problem.

Rails can do many things but no framework can design a product’s data model, and when you have an excellent one Rails will sing.

Also sometimes you need some separate services for GPU/security/reasons. That’s fine.

As I understand it, the concurrency-safe lock is built into Rails for a while. Step 3 shouldn’t be necessary.

https://github.com/rails/rails/pull/22122

It seems launch costs are the impeding factor right now. One approach to making it feasible would be to get good at asteroid mining.

https://en.wikipedia.org/wiki/Space-based_solar_power

My experience is that customers/executives will accept latency but not inaccuracy. In practice this may be the same thing, it just depends how you position it. “Reports are accurate but may be up to 5 minutes out of date” is a very easy sell to a corporate worker who logs in to check a dashboard once a month.

Primary/replica is probably the correct way to solve this. In some places, I have also shunted writes through SQS queues, which in practice protects us from a locking operation in one place impacting other operations in a customer-facing way. I don’t think this is strictly necessary but it is a nice technical guard against the sociological problem of a contractor merging code like that. They don’t feel the pain of locks gone bad because they (per contract) can’t be on call.

Que also has a Golang port [1], which can be a tool to get towards The Citadel [2] for performance or dependency-heavy jobs without going full SOA

[1] https://github.com/bgentry/que-go

[2] https://m.signalvnoise.com/the-majestic-monolith-can-become-...