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.

I think part of the value that senior people (those of us who have been in the industry for decades) bring is the wisdom of when a system has gone from uncool to dangerously unmaintainable.

Part of me wonders if it's because we old-timers ourselves know what it's like to be on that specific journey personally.

The Serverless Revolution is still happening all around us, with products like Netlify and the new DO App platform, not to mention all the enterprises moving into the cloud and moving more of their systems into managed products, using serverless components to tie it all together.

Serverless is part of many different mini-revolutions that have been going on for around the same amount of time, with micro services, rebalancing to have more processing on the client side, managed cloud services within private clouds, and the no-code/low-code movement.

Some applications aren't meant for serverless; they need containers or even on-prem on occasion. But most applications are clients with some basic APIs, and many of those are being thrown up on Netlify and AWS and no one outside of the developers are really noticing.

I've heard many teams are breaking repos up by team, and I think that makes sense for many non-Google companies, but what I wonder about is whether or not clients and backends should ever be bundled in one repo.

My gut tells me they should be separate, but I'm curious what other people think.

I added a whole bunch of features a year or two ago, including a wide range of new goods (cochineal, indigo, etc.) and the repugnant feature of slavery (repugnant, but I would think it would be very tempting to a player economically), but I foolishly forgot to push it off my old computer.

I always wonder if such content (and no functional improvements) would even be welcome in a pull request, not to mention how controversial adding slavery to a game might be.

I think the danger is not just unrealistic expectations from a point of view of "I'm just not that much of a genius/producer", but (not necessarily article-related) I think it's important to realize how unusual the story is of the "super successful" and "driven" people we so often compare ourselves to.

Now that I'm older, I realize that where I am is not surprising despite the work I've put in; what would have been far more unexpected would be for everything to have worked out and grown so large that I'd be one of the big successes.

That measuring stick would need to be configured against the mean, assuming it's needed at all (and it likely isn't).

I personally don't feel contentment can come without some form of productivity, not that it has to be a traditional concept of work. I think not having goals is a breeding ground for discontent and depression.

But like everything else, it often depends on personal experience.

I don't think that is the case for many people, myself included. There are two sides to this not being the best way to think of it for some:

- slipping on deadlines becomes cumulative and does affect your career or business; the more work that is delayed, the most difficult it seems to be to ever catch up

- there is a fast-approaching deadline for all of us, and I don't want to look back on what may be my last decade of high productivity and realize I spent most of it on Netflix and Steam

As said by others, procrastination is often a symptom of negative visualization of a task; if you can train yourself to drop the fixation of a task being unpleasant, you can overcome most procrastination.

That has worked for me; now, when I miss deadlines, it's more due to overestimating my energy than falling victim to my own procrastination.

I found it strange that there was not one mention of the ancient Stoics, who, disregarding their non-materialist viewpoints, came up with much of this philosophy. I'd argue they are a more accurate original source of these viewpoints on mindfulness and contentment than the Epicureans.