Or don't. I've done both, published OSS projects and sold some software. The level of entitlement in some comments I received on the OSS side was pretty crazy at times. While with the paid software, all of the interactions I had were so much more constructive. YMMV, but willingness to pay is a great filter.
I’ve also done both, and I found both kinds of users in both situations. There have been cases on the commercial front where I just felt like giving customers their money back, even after years of having used the software, and told them to not come back. There’s a lot of entitlement and craziness from paying users too, and those are harder to ignore. With open-source it’s much simpler to drive a hard line.
My “favourites” are the ones threatening to abandon the tool, despite having never made a single positive contribution. On open-source that’s an easy laugh and a “good riddance”. On commercial cases it’s more frustrating and nuanced.
I disagree willingness to pay is that meaningful of a filter, in the cases I experienced. And it’s getting worse; many people are getting too impatient and act like everyone works for them specifically and only their needs matter.
> There’s a lot of entitlement and craziness from paying users too, and those are harder to ignore.
Somebody paying for your product is very strong signal. You know that such a person represents real world use cases for your product, and that their issues and feature requests are based on real world problems. Otherwise the chances are low that they would be paying for the software.
So helping them with what they want could mean that you've just tipped the scale enough for hundreds or thousands of people to become new customers.
And of course you should give them their money back to get rid of them if they're any kind of headache. Or tell them that their requested feature will be in the next versions, which is a new purchase.
> So helping them with what they want could mean that you've just tipped the scale enough for hundreds or thousands of people to become new customers.
Sure, if the request is reasonable and sensical. I entertain those and even help them formulate the request better if needed. That’s true of both commercial and open-source.
But I’m more talking about the users who demand features. Those who say the tool needs to have whatever idea they just thought of 2 minutes ago, despite no one else ever having asked for it and it not really making sense. Those users who only think of themselves and suggest features which require fundamental changes which would modify the behaviour for everyone, or the feature is in itself contradictory and there’s no way it could work.
No other customers asking for the feature is not a signal that its not wanted by many others. Other people suggesting the same thing is a terrible measurement, as suggestions from paying users is already an incredibly small amount of users and some users may just thing it would be nice but not enough to warrant sending in a request. For example: it would be nice if I had a one-click export of my favorites on HN to a markdown. I'm not going to write to them to suggest it because it's not a big deal, but that doesn't mean it wouldn't improve my experience using the the product.
> Those who say the tool needs to have whatever idea they just thought of 2 minutes ago, despite no one else ever having asked for it and it not really making sense.
If no one is bothered enough by the lack of the feature to mention it, then the software doesn’t need it. And you’re ignoring the “and it not really making sense” part. If a feature is well-reasoned and makes sense in scope, I always consider it.
Suggestions from paying users are the only suggestions which have any value, since they represent the type of people who are willing to pay for the software.
If you have users who aren't paying you, there is no reason at all to pay any heed to what they say.
There’s no cost to me to stop an entitled disruptive user with zero positive contributions from destabilising the project. No cost to my volunteers either. The opposite is true in both cases; removing that user is a net benefit and I’ve done so in the past specifically to protect the experience of the volunteers.
As for tokens, there have been exactly zero cases where someone has submitted LLM code to one of my repos that has been up to my standards and I have accepted it. Yes, I can say that with certainty. If I wanted LLM code I’d ask for it myself, having an intermediary in that process is worse than useless.
> There’s no cost to me to stop an entitled disruptive user with zero positive contributions from destabilising the project.
Having to spend time reviewing a PR or issue is “no cost”?
I’m not convinced yet.
> As for tokens
I did not mean LLM contributions…I meant using AI tools to automate the reviews of contributions and users you seem to think cost no time or attention, but I do..
Yes, all of them if you want to. It's 100% up to you whether and how you deal with other people and their contributions, and it's completely orthogonal to being FLOSS or using a git hosting.
That's just one way to do it. Even if you let them send you PRs or whatever, you can still act on them or not depending on how they behave, your available resources, health, mood or just whim. You don't owe anyone anything and "creating a community around a project" is not a goal you have to be striving for regardless of whether you take contributions or provide some user support or not.
A TV-presenter of a fairly popular TV-show with an audience in my country once told an anecdote that they wanted the admission for the audience to be free. But when the tickets were free, a lot less people showed up. When they changed the ticket to be the quite arbitrary amount of 7 EUR, suddenly the theater was full every time.
A long time ago I was helping a friend with her hand-made candles stall at a craft fair. A particular thpe of candle wasn't selling - so we talked about it and she reduced the price of each candle. But they still weren't selling. So we talked about it some more, and she priced them at 3x the original price. They all sold.
Yeah. If it's free or cheap, people don't value the thing. It's something called "price sensitivity". Some things are expensive (luxury brands), and people want it for that reason alone (status symbol).
I've discovered this when trying to get rid of low value stuff. If I put it up for free, there's usually either no response or a bunch of "I'll take it" and then never showing up. But if I put some minimal price on it, it usually goes quickly.
> But when the tickets were free, a lot less people showed up.
I can think of several reasons for that. It would be nice to know for sure which was the right one (or if there’s a combination).
E.g. Maybe being free, people reserved the tickets but then didn’t show up. Or if you didn’t have to reserve, people only went on a whim. Or they always assumed they would all be reserved in advance so didn’t bother to try.
I suspect that when you pay for an event you’re more likely to make a concerted effort to attend lest you “lose the money”.
We naturally go for scarce things first. A few examples of this:
- I'm not particularly into castles, but I've visited a fair few while travelling. I lived in Norwich for 10 years, home to one of the finest Norman castles in the country. Did I visit? Did I heck.
- When your favourite film was on TV you'd watch it every time. Then when you got it on DVD you'd never watch it again.
- Give a dog some miscellaneous leftovers and notice how they prioritise ingestion.
Not sure it's really the same entitlement phenomenon the GP was talking about, though.
Context is king. A famous cello player playing on streets is valued less and is valued more when playing in a stadium. This is the typical framing phenomenon which psychology has discovered about humans. Even what colour we perceive changes based on surrounding context so not surprising.
I've regularly heard something similar said of consulting work, too. Many people new to the game worry about charging too much, because if a client is paying more then surely the pressure will be higher. Instead they end up experiencing the opposite: charging a higher rate tends to get them a better kind of client.
I'm not sure what the exact lesson is here. Something about stingy people not being nice to work with, perhaps?
Stingy people are indeed not nice to work with, which is why I raised my prices as a freelance coder through the roof about 20 years ago, usually pacing about triple the going market rate. But filtering out stingy people isn't the main factor in the phenomenon you're describing, because some of my happiest customers have been stingy people who capitulated to paying much more than they initially thought the work was worth. They tend to also be the ones who are most prone to congratulating themselves and bragging to their friends on springing for the most expensive option, and when they do, they invariably (even pathologically) need to assert to themselves and everyone else that they paid for "the best".
The name for this is the Veblen Effect [0], and it applies to all irrational market behaviour where people are actually happier with luxury goods the more they pay for them.
Funnily enough, I've seen some of the exact same clients brag about how cheaply they got something else. The lesson I've drawn is that they're mostly looking for approval, so they're equally interested in buying status as they are in getting real stuff done. It's a win/win if you deliver a great product that they can brag about, because they'll do the hard work of selling it to themselves for you.
A corollary of that psychology is that some, maybe even most people are never happy with stuff they paid market price for. They either think they could've gotten it cheaper, or they think they could have gotten more for their money. Paying market price makes them feel like a chump. But paying way more than market has to be justified to themselves first. It's simply too embarrassing to admit that they might have overpaid an arm and a leg. So as a contractor, pricing your work as either very cheap or very expensive, on the margins of the parabola, alleviates this vague sense of dissatisfaction from your clients' internal debate, and gives them the peace of mind that they're actually trying to buy.
Value is relative. Effort-to-income ratios vary significantly between traders.
The pragmatic accept that work ≠ value, some do so permanently. But someone newly aware of this may deem it unfair, and react with totally disproportionate demands, some do so permanently.
Then you come across those who already benefit greatly from the imbalance, yet still make disproportionate demands. These tend to be good at it, subtle, strategic. Which may explain why they end up on the benefiting side.
Broadly, you find three types: the greedy, the balanced, and the generous pragmatic.
The greedy exploits relativity. The balanced respects it. The generous navigates it without resentment. Whether consciously or not.
Not to mention that "OSI open source" is basically sponsored and advocated by the firms that stand to benefit the most: hyperscalers that will embrace, extend, and encrust the thing you built with their monetization tendrils and leave you without a way to make money on it yourself.
See: Redis, Elastic, etc.
Not an ounce of AWS or GCP is open source, yet they'll happily spin up a managed version of your thing and make hundreds of millions without cutting you in.
We need new licenses that are more "shareware" like. That permit individuals, but slap big trillion dollar companies.
"Fair source", "Fair code", the defold license, etc. are all pretty good.
I agree. Free Software is a good idea in concept, but it is the foremost reason there exist billion dollar tech monopolies today built on the free work of idealists worldwide.
In the age of LLMs and entitled users, I must be selfish and cannot release my work as free software any more. The best of all worlds, for me, is to provide source code along with binaries to paying customers.
Firecracker and gVisor are used by AWS and GCP, respectively, are open source. That's just off the top of my head, I'm sure there's more, there's also the whole Open Compute Project, after all.
They'll find loopholes around that too, in time - they already found some, which led to the SSPL being created.
What you actually want is some kind of noncommercial clause: you can use my free shit as part of your free shit. If you want to make money off my shit, the rules change to "fuck you, pay me"
"But what if a company just wants to try it out?" well they can live within the already existing exception called "not telling me you're breaking my license". If I don't know about it I can't impose any penalties on you. Every good business already knows how and when they can break the law with impunity, and that's one of them.
What are some good licenses for that? I generally do want fellow programmers to enjoy my work but I don't really want corporations finding ways to make trillions off of it and leaving me with nothing. I've been slapping AGPLv3 on everything I make for that reason. Any "open source" nonsense is just wealth transfer from well meaning developers straight into the pockets of corporations, so I picked the most copyleft license imaginable. I'm open to even stronger AGPLv3 alternatives. Anything that helps individual hackers and gets corporations to pay.
When I make open source software, it's a gift to the commons for the enrichment of all mankind. It doesn't cost me, or humanity, one bit if a big tech company benefits from it. The idea that companies shouldn't be able to benefit from contributions to the commons is not really justifiable.
> No, this begging is particularly different because it capitalizes on the good will of open source developers. Microsoft, Apple, and Google are standing on the internet in their trillion dollar business suits with a sign that reads "Starving and homeless. Any free labor will help." They aren't holding people up at gun point. Rather they hold out their Rolex encrusted hand and beg, plead, and shame open source developers until they get free labor.
> Once they get this free labor they rarely give credit. They're ungrateful beggars that take their donated work hours, jump in their Teslas, and ride off to make more trillions proclaiming, "Haha! That open source idiot just gave me 10 hours of free labor. What a loser."
Humanity benefits more if poor people can use it for free and big companies have to pay for it, than if both can use it for free. Companies having to pay for stuff is the only reason they don't have 100% of the money, which would be bad.
That was my experience. When I first started consulting 20 years ago I stupidly charged $40/hour because I was young and dumb I stupidly discounted the time it took to find clients (and things like health insurance, etc...). I quickly adjusted and started charging $120/hour. I got much better clients and the projects I worked on became that much more interesting.
In my experience charging too little is one of the biggest mistake to do when starting.
I don't think it's subconscious at all. If, for instance, you contract something on fiverr for $5, you expect $5 of work. If you contract something for $1000 you expect $1000 of work. And the former's probably going to take a lot more feedback to get to where you want than the latter.
Basically, you get what you pay for. That's not always true, but it holds pretty reliably.
It's totally fine to turn off issues and pull requests, and refuse all contributions. The problem is many maintainers create undue responsibility for themselves with snide responses like "PR welcome" to every issue or request. When people show up with the patches after a response like that, I'd say that they are very much owed some of the maintaner's precious time.
Agreed, if a patch is offered after being suggested then some reaction should take place, even if to clarify that currently there is not enough resource to accept/reject it and thus it might be better to temporarily rely on their own fork.
I'd say it comes off as more of a challenge than a suggestion. "I don't care, do it yourself if you care so much". Most people just go away when they get told that. Some people actually rise up to the challenge.
> even if to clarify that currently there is not enough resource to accept/reject it
That's fine if clarified beforehand. The CONTRIBUTING.md from the above comment is an excellent example. It clearly communicates the maintainer's stance.
If it's coming from someone who previously "welcomed PRs", that sort of reply is extremely rude. Learning and modifying someone else's project is a major undertaking, and it's very disrespectful when maintainers don't match that effort, especially when they invited it upon themselves.
As someone who once had a popular open-source project. Opensource is just harder because you've to write code for <optics>. When I am working with a small team, I do not care if my commits are ugly or repetitive. Despite what people here say, all these things have very little to do with the reliability of actual code.
Same software i offer for free will take 2-5x more time if i did it opensource way.
> When I am working with a small team, I do not care if my commits are ugly or repetitive.
thats interesting because for me its the opposite: working in a team boosted my code quality and cleanliness much more than something open source i did precisely because people on my team would be looking at it and reviewing it...
I personally give away free software, and actually don't get bothered by comments as much. The catch? I write the software to fulfill my needs, and may or may not take anyone's suggestions at heart.
If they are so inclined, they can fork it and patch it. It's out there after all. As long as they obey the terms of the license I put forth, it's all fair.
I like the idea of creating a OSS project, and then build extra on top of it for selling.
The OSS part ensured that even if I went full Sam Altman, the user will still have an absolute baseline they can fallback on. And given how lazy I am, the OSS is often basically 70% of the project. This also has the benefit that the significant part of the code can be audited for security/etc, sometimes even for free.
"While with the paid software, all of the interactions I had were so much more constructive. YMMV, but willingness to pay is a great filter."
That's in line with my experience on both consulting and selling software. The more they pay, the easier and reasonable they are to work with.
Years ago, I put out some free software and there were a lot of users who seemed to be on a power trip to show me who is the boss. I assumed they were some lonely guys in a basement who had nothing else going on, so they best they could come up with is to beat up an author of the only software they can afford.
If you've got some time, I highly recommend going through the exercise of trying to change the prompt in a way that would produce code similar to what you've achieved manually. Doing a similar exercise really helps to improve agent prompting skills, as it shows how changing parts of the prompt influences the result.
I haven’t had any luck prompting LLMs to “have taste.” They seem to over fixate on instructions (e.g. golfing when asked for concise code) or require specifying so many details and qualifications that the results no longer generalize well to other problems.
Do you have any examples or resources that worked well for you?
Yeah prompting doesn't work for this problem because the entire point of an LLM is you give it the what and it outputs the how. The more how that you have to condition it with in the prompt, the less profitable the interaction will be. A few hints is OK, but doing all the work for the LLM tends to lead to negative productivity.
Writing prompts and writing code takes about the same amount of time, for the same amount of text, plus there's the extra time that the LLM takes to accomplish the task, and review time afterwards. So you might as well just write the code yourself if you have to specify every tiny implementation detail in the prompt.
Makes me think of this commitstrip comic: https://i.xkqr.org/itscalledcode.jpg (mirrored from the original due to TLS issues with the original domain.)
A guy with a mug comes up to a person standing with their laptop on a small table. The mug guy says, "Some day we won't even need coders any more. We'll be able to just write the specification and the program will write itself."
Guy with laptop looks up. "Oh, wow, you're right! We'll be able to write a comprehensive and precise spec and bam, we won't need programmers any more!"
Guy with mug takes a sip. "Exactly!"
Guy with laptop says, "And do you know the industry term for a project specification that is comprehensive and precise enough to generate a program?"
You know, this makes me wonder... is anybody actually prompting LLMs with pseudocode rather than an English specification? Could doing so result in code that that's more true to the original pseudocode?
You can give the macro-structure using stubs then ask the LLM to fill in the blanks.
The problem is that it doesn't work too well for the meso-structure.
Models tend to be quite good at the micro-structure because they've seen a lot of it already, and the macro-structure can easily be promoted, but the levels in between are what distinguishes a good vs bad model (or human!).
Goodhart's Law of Specification: When a spec reaches a state where it's comprehensive and precise enough to generate code, it has fallen out of alignment with the original intent.
Of course there are some systems where correctness is vital, and for those I'd like a precise spec and proof of correctness. But I think there's a huge bulk of code where formal specification impedes what should be a process of learning and adapting.
My dream antiprogram is a specification compiler that interprets any natural language and compiles it to a strict specification. But on any possible ambiguity it gives an error.
?
This terse error was found to be necessary as to not overwhelm the user with pages and pages of decision trees enumerating the ambiguities.
Openspec does this. But instead of "?" it has a separate Open Questions section in the design document. In codex cli, if you first go in plan mode it will ask you open questions before it proceeds with the rest.
The UX is there, for small things it does work for me, but there is still something left for LLMs to truly capture major issues.
> Do you have any examples or resources that worked well for you?
Using this particular example, if you simply paste the exact code into the prompt, the model should able to reproduce it. Now, you can start removing the bits and see how much you can remove from the prompt, e.g. simplify it to pseudocode, etc. Then you can push it further and try to switch from the pseudocode to the architecture, etc.
That way, you'll start from something that's working and work backwards rather than trying to get there in the absence of a clear path.
That’s an interesting approach, but what do you learn from it that is applicable to the next task? Do you find that this eventually boils down to heuristics that generalize to any task? It sounds like it would only work because you already put a lot of effort into understanding the constraints of the specific problem in detail.
What worked for me was Gemini 3 Pro (I guess 3.1 should work even better now) with the prompt "This code is unnecessarily complicated. Simplify it, but no code golf". This decreased code size by about 60 %. It still did a bit of code-golfing, but it was manageable.
It is important to start a new chat so the model is not stuck in its previous mindset, and it is beneficial to have tests to verify that the simplified code still works as it did before.
Telling the model to generate concise code did not work for me, because LLMs do not know beforehand what they are going to write, so they are rarely able to refactor existing code to break out common functionality into reusable functions. We might get there eventually. Thinking models are a bit better at it. But we are not quite there yet.
I have a stupid solution for this which is working wonders. It does not help to tell the LLM "don't do this pattern". I literally make it write a regex based test which looks for that pattern and fails the test.
For example I am developing a game using GDscript, LLMs (including codex and claude) keep making scripts with no classnames and then loading them with @preload. Hate this, and its explicitly mentioned in my godot-development skill. What agents can't stand is a failing test. Feels a bit like enforcing rules automatically.
This is a stupid idea but it works wonders on giving taste to my LLM. I wonder if I should open source that test suite for other agentic developers.
I really should spend some time analyzing what I do to get the good output I get..
One thing that is fairly low effort that you could try is find code you really like and ask the model to list the adjectives and attributes that that code exhibits. Then try them in a prompt.
With LLMs generally you want to adjust the behavior at the macro level by setting things like beliefs and values, vs at the micro level by making "rules".
By understanding how the model maps the aspects that you like about the code to language, that should give you some shorthand phrases that give you a lot of behavioral leverage.
Edit:
Better yet.. give a fresh context window the "before" and "after" and have it provide you with contrasting values, adjectives, etc.
Concise isn't specific enough: I've primed mine on basic architecture I want: imperative shell/functional core, don't mix abstraction levels in one function, each function should be simple to read top-to-bottom with higher level code doing only orchestration with no control flow. Names should express business intent. Prefer functions over methods where possible. Use types to make illegal states unrepresentable. RAII. etc.
You need to think about what "good taste " is to you (or find others who have already written about software architecture and take their ideas that you like). People disagree on what that even means (e.g. some people love Rails. To me a lot of it seems like the exact opposite of "good taste").
I spend much more time refactoring that creating features (though, it is getting better with each model). My go-to approach is to use Claude Code Opus 4.6 for writing and Gemini 3.1 Pro for cleaning up. I feel that doing it just one-stage is rarely enough.
A lot of prompts about finding the right level of abstraction, DRY, etc.
I actually don’t think golfing is such a bad thing, granted it will first handle the low hanging fruits like variable names etc, but if you push it hard enough it will be forced to think of a simpler approach. Then you can take a step back and tell it to fix the variable names, formatting etc. With the caveat that a smaller AST doesn’t necessarily mean simpler code, but it’s a decent heuristic.
I appreciate that your message is a good-natured, friendly tip. I don't mean for the following to crap on that. I just need to shout into the void:
If I have some time, the last thing I want to do with it is sharpen prompting skills. I can't imagine a worse or more boring use of my time on a computer or a skill I want less.
Every time I visit Hacker News I become more certain that I want nothing to do with either the future the enthusiasts think awaits us or the present that they think is building towards it.
While I somewhat understand the impact on the craft, the agents have allowed me to work on the projects that I would never have had enough time to work on otherwise.
You dont need to learn anything, it needs to learn from you. When it fails, don't correct it out of bounds, correct it in the same UI. At the end say "look at what I did and create a proposed memory with what you learned" and if it looks good have it add it to memories.
This better reflects what I thought about the other day. You either, let clankers do its thing and then bake in your implementation on top, you think it through and make them do it, but at the end of the day you've still gotta THINK of the optimal solution and state of the code at which point, do clankers do anything asides from saving you a bunch of keypresses, and maybe catching a couple of bugs?
Also useful to encode into the steering of your platform. The incremental aspect of many little updates really help picking up speed by reducing review time.
Big bang approach could be a start, but a lot of one line guidance from specific things you dont want to see stack up real fast.
My mildly amusing anecdote is that, whenever Claude Code produces something particularly egregious, I often find it sufficient to reply with just "wtf?" for it to present a much more sensible version of the code (which often needs further refinement, but that's another story...)
What's incredibly ironic is that research labs are releasing the most advanced hacking toolkit ever known, and cybersecurity defence stocks are going down as a result somehow. There’s no logic in the stock markets.
In Theory There Is No Difference Between Theory and Practice, While In Practice There Is.
In large projects, having a specific AGENTS.md makes the difference between the agent spending half of its context window searching for the right commands, navigating the repo, understanding what is what, etc., and being extremely useful. The larger the repository, the more things it needs to be aware of and the more important the AGENTS.md is. At least that's what I have observed in practice.
Great article! Just yesterday I watched a Devoxx talk by Andrei Pangin [1], the creator of async-profiler where I learned about the new heatmap support. To many folks it might not sound that exciting, until you realise that these heatmaps make it much easier to see patterns over time. If you’re interested there’s a solid blog post [2] from Netflix that walks through the format and why it can be incredibly useful.
Great that you had the time to be curious and dig into what was going on. QEMU is quite an amazing tool.
I'm kind of surprised there isn't a fairly robust kernel test around this issue, since it locks the machine down and I think the fix was to prevent a stuck CPU last time as well?
It's also vaguely surprising that this hasn't been encountered more often, particularly by the https://news.ycombinator.com/user?id=everlier talking in links to this HN post about "20-30 containers" running simultaneously and occasionally locking up the machine.
If you're still thinking about the bug a little, you could look over how other kernel tests work and implement a failing test around it....?
I imagine the tests have some way of detecting a locked up kernel... I don't know exactly how they'd do it, but they probably have a technique. Most likely since the kernel is literally in a loop it won't respond to anything.. so starting any process, something as simple as creating any process, even one as simple as printing "Hello World!!" would fail and indicate the machine is locked.
Perhaps this is one of those cases where something like UserModeLinux would allow a test to be easily put together, rather than spawning complete VMs via some kind of VM software. Again, would be interesting to know what Linux does with this kind of test.
Definitely not the first AI generated font. One can find an enormous amount of research in AI font generation on https://scholar.google.com/ going back many years. This could possibly be the first one that used Nano Banana though, and the result is impressive for sure!
I believe there is no contradiction with the definition from the linked article?
> A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline:
> Hard – missing a deadline is a total system failure.
> Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
> Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.
> I guess I just have to accept that the term has lost it's meaning at this point and can be used for whatever whoever wants to use it for
It's maybe more like you point out: realtime in the OS context vs realtime in an event processing context. The latter is certainly not defined as strictly and often just means push-based. It has been a popular moniker, e.g. in kafka-land, for a while. I'm not sure it intrinsically takes away from the OS context - it doesn't need to be a deep dish pizza situation.
The highest level of cringe you can feel is when you see people you know well in real life post on LinkedIn. The contrast between the way they speak in real life and on LinkedIn is often immense, you don't feel that level of contrast with random internet strangers.
On the other hand, people have commented (in real life to me) that my linkedin comments are bold, hilarious and entirely unprofessional- earning me a sort of credibility in their eyes for being authentic and having integrity.
(and probably more privately, they believe I am too outspoken..)
Pro’s/Con’s; just like with all public broadcast information.
Also, its always embarrassing when someone talks about a linkedin comment I have made, not because I am ashamed but because I am sort of used to a semi-anonymous shouting into the void style forum like hackernews.
Reminds me of a blog post I once read from a manager writing about all the qualities of being a good manager. I read it nodding along that they all seemed like good traits. Then in the comment section there was a post from someone saying something like "You were my manager at one point and honestly you were one of the worst managers I've had in my career. I didn't see many of these behaviours from you". The author responded with something like "I don't disagree. There's sometimes a gap between knowing and doing"
In my professional network, people mostly just reshare and like things their peers are doing or that they want to boost engagement for (mainly job postings, which they also post occasionally).
I _do_ have acquaintances I made outside of working life on LinkedIn, though - the only two that are really active are a mechanical engineer who mostly just posts about robotics and someone in marketing. I don't know if it's because I'm just really good friends with the latter person, but I've never felt annoyed reading their posts; they mostly seem to just talk about enjoying conferences or new externally facing projects - ad campaigns, large-scale promotions, etc - wherever they are currently working. I don't know if part of that is they're in the EU and the culture for marketers there is different?
I have a friend who behaves similarly on linkedin and in real life, and he's very blunt. I like how he calls out some crap on linkedin posts, and nobody dares to like his comments, even though I'm sure everybody approves.
Overall, I don't see anyone I know being a cringe bootlicker on LinkedIn. These people are very visible, but probably a small minority of users.
I'm curious about how their internal policies work such that they are allowed to publish a post mortem this quickly, and with this much transparency.
Any other large-ish company, there would be layers of "stakeholders" that will slow this process down. They will almost always never allow code to be published.
Well… we have a culture of transparency we take seriously. I spent 3 years in law school that many times over my career have seemed like wastes but days like today prove useful. I was in the triage video bridge call nearly the whole time. Spent some time after we got things under control talking to customers. Then went home. I’m currently in Lisbon at our EUHQ. I texted John Graham-Cumming, our former CTO and current Board member whose clarity of writing I’ve always admired. He came over. Brought his son (“to show that work isn’t always fun”). Our Chief Legal Officer (Doug) happened to be in town. He came over too. The team had put together a technical doc with all the details. A tick-tock of what had happened and when. I locked myself on a balcony and started writing the intro and conclusion in my trusty BBEdit text editor. John started working on the technical middle. Doug provided edits here and there on places we weren’t clear. At some point John ordered sushi but from a place with limited delivery selection options, and I’m allergic to shellfish, so I ordered a burrito. The team continued to flesh out what happened. As we’d write we’d discover questions: how could a database permission change impact query results? Why were we making a permission change in the first place? We asked in the Google Doc. Answers came back. A few hours ago we declared it done. I read it top-to-bottom out loud for Doug, John, and John’s son. None of us were happy — we were embarrassed by what had happened — but we declared it true and accurate. I sent a draft to Michelle, who’s in SF. The technical teams gave it a once over. Our social media team staged it to our blog. I texted John to see if he wanted to post it to HN. He didn’t reply after a few minutes so I did. That was the process.
> I texted John to see if he wanted to post it to HN. He didn’t reply after a few minutes so I did
Damn corporate karma farming is ruthless, only a couple minute SLA before taking ownership of the karma. I guess I'm not built for this big business SLA.
We're in a Live Fast Die Young karma world. If you can't get a TikTok ready with 2 minutes of the post modem drop, you might as well quit and become a barista instead.
> I read it top-to-bottom out loud for Doug, John, and John’s son. None of us were happy — we were embarrassed by what had happened — but we declared it true and accurate.
I'm so jealous. I've written postmortems for major incidents at a previous job: a few hours to write, a week of bikeshedding by marketing and communication and tech writers and ... over any single detail in my writing. Sanitizing (hide a part), simplifying (our customers are too dumb to understand), etc, so that the final writing was "true" in the sense that it "was not false", but definitely not what I would call "true and accurate" as an engineer.
I'm not sure I've ever read something from someone so high up in a company that gave me such a strong feeling for "I'd like to work for these people". If job posts could be so informal and open ended, this post could serve as one in the form of a personality fit litmus test.
How do you guys handle redaction? I'm sure even when trusted individuals are in charge of authoring, there's still a potential of accidental leakage which would probably be best mitigated by a team specifically looking for any slip ups.
Team has a good sense, typically. In this case, the names of the columns in the Bot Management feature table seemed sensitive. The person who included that in the master document we were working from added a comment: “Should redact column names.” John and I usually catch anything the rest of the team may have missed. For me, pays to have gone to law school, but also pays to have studied Computer Science in college and be technical enough to still understand both the SQL and Rust code here.
Probably because he could check legalities of a release himself without council. It is probably equivalent to educating yourself on your rights and laws so if you get pulled over by a cop who may try to do things that you can legally refuse, you can say no.
The person who posted both this blog article and the hacker news post, is Matthew Prince, one of highly technical billionaire founders of cloudflare. I'm sure if he wants something to happen, it happens.
I mean the CEO posted the post-mortem so there aren't that many layers of stakeholders above. For other post-mortems by engineers, Matthew once said that the engineering team is running the blog and that he wouldn't event know how to veto even if he wanted [0]
There’s lots of things we did while we were trying to track down and debug the root cause that didn’t make it into the post. Sorry the WARP takedown impacted you. As I said in a comment above, it was the result of us (wrongly) believing that this was an attack targeting WARP endpoints in our UK data centers. That turned out to be wrong but based on where errors initially spiked it was a reasonable hypothesis we wanted to rule out.
Why give this sort of content more visibility/reach?
I'm sure that's not your intent, so I hope my comment gives you an opportunity to reflect on the effects of syndicating such stupidity, no matter what platform it comes from.
Mainly to make others aware of what’s happening in the context of this Cloudflare outage. Sure I can avoid giving it visibility/reach but it’s growing and proliferating on its own, and I think ignoring it isn’t going to stop it so I am hoping awareness will help. I’ve noticed a huge rise in open racism against Chinese and Indian and workers of other origin, even when they’re here on a legal visa that we have chosen as a nation to grant for our own benefit.
The legislation that MTG (Marjorie Taylor Green) just proposed a few days ago to ban H1B entirely, and the calls to ban other visa types, is going to have a big negative impact on the tech industry and American innovation in general. The social media stupidity is online but it gives momentum to the actual real life legislation and other actions the administration might take. Many congress people are seeing the online sentiment and changing their positions in response, unfortunately.
I'm not the person you were replying to, but there is a rule I often see about not directly replying/quote tweeting because "engagement" appears to boost support for the ideas expressed. The recommendation then, would be to screenshot it (often with the username removed) and link to that.
FWIW it seems pretty obvious that this was ragebait. OP's profile is pretty much non-stop commentary on politics with nearly zero comments or submissions pertaining to the broader tech industry.
Posts like that deserve to be flagged if the sum of their substance is jingoist musing & ogling dumb people on Twitter.
> Let me save you fifteen minutes, or the rest of your life: They aren’t.
Knowing that all profilers aren't perfectly accurate isn't a very useful piece of information. However, knowing which types of profilers are inaccurate and in which cases is indeed very useful information, and this is exactly what this article is about. Well worth 15 minutes.
> And that often involves ignoring the fancy visualization and staring at the numbers.
Visualisations are incredibly important. I've debugged a large number [1] of performance issues and production incidents highlighted by the async profiler producing Brendan Gregg's flame graphs [2]. Sure, things could be presented as numbers, but what I really care about most of the time when I take a CPU profile from a production instance is – what part of the system was taking most of the CPU cycles.
Isn’t not that they’re “not perfectly accurate”, it’s that you can find half an order of magnitude of performance after the profiler tells you everything is fine.
That’s perfectly inaccurate.
Most of the people who seem to know how to actually tune code are in gaming, and in engine design in particular. And the fact that they don’t spend all day every day telling us how silly the rest of us are is either a testament to politeness or a shame. I can’t decide which.
> Isn’t not that they’re “not perfectly accurate”, it’s that you can find half an order of magnitude of performance after the profiler tells you everything is fine.
> That’s perfectly inaccurate.
That's a very strong claim, and it's not true in my experience as I've showed above.
