If success is posting stupid click bait questions on twitter, then yes, I refuse to do that.
I’m not a clown or an entertainer. I share my journey and provide value to people. The people who are drawn to click bait content, are not the people I want to interact with.
If we are talking about syndromes, then I think you might have a Stockholm syndrome.
On a more serious note, marketing is an umbrella term. There is clever marketing out there. It’s, however, rare. Most of the marketing is trash in a form of click baiting and being a morale-less clown. And the saddest part, is that it works. That’s why algorithms reward it.
I feel with you, but don't delude yourself in to avoiding any kind of marketing. Marketing is an evil necessity, especially if you are starting from scratch by yourself. That's just the nature of our reality. To scoff and say you're content is an ego-fuelled move, one that pushes the problem off for later.
Don't do that to yourself. Learn to market ethically at least, or else it's a real waste of time as your next startup fails because you avoided marketing.
> It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is.
My hypothesis is the design of the page and the images played a big role in convincing people this is "legit".
Because feature flags often intersect with segmentation and AB testing.
So it's not just a byte in memory, but often also correlating the status of said byte with a users identity and then tracking and summarising user behaviour based on that relationship.
It's become fairly standardised and requires engineer time to setup and maintain the services behind all that, so it's valid to go third party for less than the cost of said engineer time, if all you want is standard.
Edit:it's also hard to always predict when a standard flags going to become part of a test, so just integrating for every flag and making that a standard process for your teams becomes the simplest approach.
I am not a fan nor a user of backend feature flags, so don't ding me for relaying this: they tout features such as central management of these settings, bringing them in the hands of the product team rather than being tugged away in code, allowing for canary deployments where you fade in a feature based on performance metrics, a/b testing, and so on. In their own interest, these folks take an as broad as possible view on what is a feature flag, often including things that you'd otherwise call system configuration or entitlements or permission toggles. It's not a new trend, LaunchDarkly is probably the best known commercial party here, and they've been around for about ten years, and I don't think they were first.
I wouldn't say a new trend, it did go through a hype cycle a few years ago, and some teams have adopted it. I definitely wouldn't call it a standard practice though, as it brings with its own overhead. In effect you've got "byte in memory as a service" with its own deployment, maintenance, and statefulness. It's only useful if you have a business model that really relies on having this capability. That could be in a sufficiently large, already complex, sprawling application estate, having a single flag in a central location could be useful if several pieces of your sprawling estate need it.
Aren't there common patterns of good "just code" and bad "just code"? I've been told for a long time that global variables are a bad pattern. Maybe feature flags are a bad pattern too.
One concern about feature flags is testing, and the added permutations of testing needed to include all the feature flags in testing. You tested with flag A on and off, you tested with flag B on and off, but did you ever test with them both on and both off? Without feature flags, a big change that could have been represented by a feature flag would hopefully have to make its way past some quality gates. With feature flags, the exact permutation that you're going to cause later today by flipping on some feature flags may well not have been tested. Not that forgetting to test is something you can't protect yourself against with tools and processes, but testing all the permutations may be expensive.
You may not have to test all the permutations, if you can predict which permutations are relevant for your flipping feature flags later today. But a lot of organizations have poor discipline in cleaning up old feature flags, so it may not be so predictable. Maybe that's not a feature flag problem but an organizational problem, but the feature flags are gonna get blamed at some point, nonetheless.
I was hoping one can setup a "modern" C development environment without resorting to Docker.
Using Docker for setup a C development environment indicates that there are too many moving parts and the development environment is essentially very complex and that there's nothing that one do about it.
I wish more people would write such guides with the aim of reducing the development environment to its essentials that can be installed system-wide without being disruptive and thus not needing "Docker".
I have a C project template for VSCode that I just copy whenever I start a new C-project.
Inspiration for it was mostly because I don't want to rewrite the same CMake code constantly.
But I think there are a lot of these kind of projects floating around out there on github.
I use mingsys though . But theoretically it should be no trouble to change the compiler.
Obviously it is goal dependent, but if you eventually want your code to run on a variety of machines and systems, I find docker to actually be a barrier. Having a different environment in CI than local can be annoying, but it’s also the first time you are forced to confront the “but it runs on my laptop!” problem
But drinks barely have any features you can market. If they do, they're front and center (less sugar or calories, more vitamins or minerals, sparkling or non sparkling)
Same for cigarettes and other similar products.
Some people may prefer the flavor of one product over the other, but at the end, it's purely about lifestyle and the feeling of a brand, and that is shaped by marketing.
So if I create a brand around a drink I can just run a few commercials on TV to associate my brand with something people want (like I don't know, being percieved as sexy by the opposite sex) then I will have a successful business?
It only appears to work if you think that kind of advertising is how they got to their market position. Usually it's not.
Let's Docker for an example.
Docker did not get adoption because of some cliche marketing on their landing page. It got adoption from people doing tech talks and tech demonstrations and several companies writing blog posts about how migrating to Docker saved them from the headaches of deployment they were having before with the ad-hoc systems.
Complex enterprise tech gets sold by other means, usually personal relationships with key decision makers, and maybe some amount of bribery, who knows.
Docker failed to sell its commercial products to enterprises relative to the OSS adoption of its container runtime, at least at the venture scales they committed themselves to
Afaict what was being sold:
* Artifactory (hub): plenty of companies doing fine.. for product different than what docker did
* DC OS (swarm): managed k8s etc doing fine too.. but diff product again
They seemed close to PMF for both... But never quite hit it?
Selling to enterprises is hard.. I'm not sure what the lesson is here beyond git stars not being revenue, nor guaranteeing that it can turn into revenue. Successfully building one thing but selling another means you have to do 2 hard things not just 1.
Maybe a good analogy: Bloomberg has great reporters whose content goes out for free... But that's not what sells the terminal and data feeds
as a solo developer, you are free to commit however you want
I use commits as rollback points. If something works and I want to try something risky, I commit first. I don't care about the commit message. I basically never look at any commit older than one month
I do the same. I also commit at logical completion points that build cleanly.
I hardly ever look at commits older than the last commit.
I don't often create branches for features; I find having permanent Production / Test / Dev branches is sufficient for most work. But I will create other branches as needed.
Git worktree is awesome for having multiple branches checked out all at the same time. At this point, I almost never switch branches and instead check them out into their own directory.
If I can’t remember the reason for a piece of code, and it wasn’t obscure enough to comment, I need to use “git blame” and then look at the message from the commit.
According to the comments, the author has only just today learned that Substack added this new popup without asking him, after he got them to disable the previous popup. So hopefully you're right that it's possible for him to turn off.
It's like economic transactions, which the state already tracks.