parsley27

I'm thinking it depends on the purpose of the software and how much customization and integration is required. A peripheral application may be a stronger BUY than something that is deployed at the core of the business process.

This is a great explanation of overhead and opportunity cost. I'm always trying to make that pitch for selling my product, but the biggest issue is that I think many companies are just jumping in on BUILD without even researching BUY.

I think there are two kinds of Production Engineers:

- DevOps only, as in Terraform or CloudFormation or CDK but not much else

- DevOps/SRE/DX, where you have engineers who handle DevOps as part of a mix of Platform Engineering, where your Platform team is able to guide and assist Product /Experience and Data teams on every part of the Developer Experience, from infra to on-call

I think it's the Platform Engineering model that has the most value; I don't know that DevOps without the rest of the package is as valuable

An interesting note in there about Meta not having a freeze on Production Engineers. I think that engineers who are worried about economic instability should consider moving closer to production/delivery/sustainment/SRE; it's not always as fun as building new features, but it is definitely a valued area of expertise.

The first point covered, giving away your core IP, is definitely one that resonates with me. We went open core with our headless document management system (https://github.com/formkiq/formkiq-core), and there is always a worry in the back of my mind that we are providing such a solid foundation with the open core/source components that we may be undercutting our enterprise modules.

But on the other hand, I don't know that we're popular enough for someone to come along and build free modules on top of our product. So maybe this isn't a problem we'd need to worry about.

Until it is... ??

Not related to books/blogs/tweets, but if you are looking at space tech for 5-10 years from now, it might make sense to pay attention to 3D printing and anything around resource extraction robotics.

Exploiting offworld resources (like Trojan asteroids) will soon be possible with machines we can design, build, and test on Earth.

That assumes operating costs go up with cloud providers. Some orgs see savings, but obviously not all.

I like to believe that serverless technologies and cloud services reduce complexity for the org, but obviously that's at the cost of offloading that complexity to the cloud providers (and welding an org's software to that provider for years, if not decades).

So different, but not less complex overall. But maybe there is value in having some of that complexity consistent across a small number of cloud providers.

I meant serverless in the context of not having defined server instances, allowing the applications to be run within resources allocated on demand by the cloud provider. It can be a difficult thing to search for, to be honest.

The idea is that an organization can have full control over their applications while gaining scaling capabilities compared to resources that run on server instances.

This helps with security/compliance, customization, cost management, etc. For smaller orgs, some of this software could be run at incredibly low costs of a few dollars a month or even within cloud free tiers.

In the case of Ghost, while it can be hosted on cloud providers like AWS, its default/recommended stack isn't serverless as it uses a server instance. However, you can use something like https://github.com/jeshan/serverless-ghost to make it mostly serverless.

Thanks!

I think around half of these examples are blatant theft, and half are just the most poorly-executed versions of what I would expect most founders to do.

Of course, since their goal seems to have been to copy rather than improve on Eco's idea, maybe step one of their plan was just as irredeemable as any of the other actions they've taken.

One thing you could consider is short-term versus long-term gain in future decision making. You already know that the colleagues who offer help and information are finding success at a greater rate than you.

Consider that information the next time you are approached. The short term cost of helping or sharing information will pay back in that longer-term success.

While some people may expect you to change your actions to be a good person, in reality, helping others and sharing helpful information will give you an advantage in future.

That's one of the things about doing good; it pays off in the longer term through personal contentment and often (but not always) in meaningful success.

So would you say RapidAPI would be better off as a discovery service as opposed to a provider?

Interesting. Did you look into this Rapid API stuff as well?

I wonder if smaller companies/projects creating APIs suffer from people not trusting longevity enough to build on top of them, but I'm not sure if Rapid API has found a solution to this problem.

I think that is true in the case of the growth startup I work at; probably 25% of the leadership started out as early individual contributors, and if things go as expected over the next few weeks, I will be making my first big step toward leadership after just six months at the company.

I never had any internal career growth at other jobs in larger or more established orgs.

Sometimes something can seen as an obvious or easy choice of action after the time for decision has passed, but when an event or emotion first strikes, that choice is often obscured by passions or require more effort than you want to expend.

That's where the words of previous Stoics, or a recent Podcast, or advice from /r/stoicism helps many of us to make that choice at that moment, before it has become obvious or easy in hindsight.

I missed your post when it came out the first time, but I don't think you need to add a rebuttal about "The Best"; I think the message is clear and hasn't changed. Now your view on if Silicon Valley has fallen would be something I'd like to read.

But as far as your original post, I couldn't find anything polarizing and controversial about why seeking and trusting the best would bring peace of mind, or how that is somehow a call for overconsumption.

It's strange how differently the same words can be understood by different people.

The author mentions what may be an effective way of viewing SRE, that it's only for the most critical of systems that SRE would run, but doesn't mention clearly a secondary goal of SRE (in my opinion), which is to standardize and support teams running their own products.

Having worked for a company where outages have clearly defined revenue loss amounts in the hundreds of thousands per hour, the biggest issue to implementing SRE was around the IT as a Cost Centre model, not anything wrong with SRE itself.

Do employees get screwed, or is it just that too many of us employees sign on and see the word equity and think that means we're suddenly co-founders?

Do you mean that perspectives change into the 40s and 50s?

I find that I'm considering this much more now that I'm in my 40s, because I know that as a generalist developer, I will be slowing down in skills compared to the younger devs, so I need to make sure my career is developing in areas that value my experience and soft skills.

I think it's even easier to get complacent with not challenging those soft skills and "tech wisdom" by staying too long in one role.

Are any of those platforms ready yet for everyone to use? I feel like we're getting closer, and devs and most designers probably can leave WP behind, but if I have a friend who wants a site and I don't want to ever touch it for them, I'm not sure I know of a non-WP option that is ready for that.

Ghost, maybe?

I think the effect of remote-only onboarding will be seen mostly in junior hires, since they do not have much experience in getting up to speed with a company's tech and its culture.

As a senior dev about to start a new remote position at a company that's still mostly non-distributed, I'm probably a little more nervous than I've been at previous first days, but I think the bigger risk is that I'm considered a more distant team member if ever there were cutbacks.

But I guess that's less of a risk if you can provide unique value in a specialized role.