skysight-inc/HackerNews huggingface dataset:
Great list -- A few thoughts:

1. Writing and lingustics are fundamentally different and while serve similar goals, it's important to think about them separately[1]. Basically all human groups create spoken language but we only know of 1 (I think) time a phonetic writing system appeared. There is some limit how well writing can help you communicate with spoken word, but it's probably pretty far out.

1a. I always think of Cormac McCarthy books for this tip. Don't be like Dickens -- you're not doing a serial and getting paid per word. Know where the extra detail is warranted. [2]

1b. Expand your vocabulary but always remember your audience and speak at their level. Your goal is to effectively communicate ideas or persuade not self aggrandize.

2b. empathy and EQ I think are the biggest thing most people can improve easily that will improve communication. We don't think about how much the symbols in our heads vary. Tree conjures some TX pine for me but some other tree probably for you. This doesn't stop us from communicating about trees and probably poses little problems. If we talk about the word 'freedom' you can see the variations are much bigger and more important.

I also think you can improve communication by being open and yourself. The more masks you wear, the less effective you will be with each mask due to time in seat. The more you can consolidate all the yous, and bring the primary you into your interactions, you may find you are a better communicator than you thought[3]

[1]: https://www.youtube.com/watch?v=Q-B_ONJIEcE
[2]: https://www.bookbrowse.com/excerpts/index.cfm/book_number/16...
[3]: https://www.amazon.com/Weekend-Language-Presenting-Stories-P...
Technically true, but you're leaving out any possible visual insights if you do that.
> OpenBSD developers pretend Linux doesn't even exist

What is the point of this statement? OpenBSD devs are focused on OpenBSD. Importing Linux is not their goal. That is their choice. If you don't like it, then don't use it. People are allowed to do as they please.

Edit: If you need Linux use Linux. Stop demanding other OS's bloat their code base so you can run foreign code.
> I’m aware of your sarcasm, but it did bother me that my Tesla used a proprietary port that made it more difficult to use other charging locations, such as the charger next to my apartment. Electric vehicle charging ports need standardization as well.

This is happening in europe, tesla is switching to type 2 connectors. I think these laws certainly play a role in motivating the company.
My high school mentor loved to say "beware of inconvenient fictions!".

The most boring choice would be "section", and boring might be good here.

We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round".

I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling in dinner a few times. this isn't normal, and can't be normal, and everyone gets to rest after, but it's something we have to do".

Instead it's just a way of saying two weeks.
Right but really, no one actually is sprinting. Devs aren't leaving standup to type as fast as humanly possible for seven hours straight. It's jargon that just means "week".
Right, this is exactly what GP is talking about. When you prioritize "doing predictable sprints" and a stable point velocity over releasing features to production, you reduce your team's throughput and productivity. When you prioritize shipping features to production over "predictable sprints", then things can be successful. You're proving GPs point, not contradicting it.
I'm not sure that the writer has a clear idea of what free markets are or what peace is. You couldn't by any exaggeration describe the trade situation between China and the US since 2008 as a "free market". Nor could you describe the system under which EU members buy Russian fuel as one; as long as governments pursue political goals by economic means, the market isn't free — and I don't think I'm moving the goalposts in saying that.

And peace doesn't require that the Russians and Chinese become our friends; it requires that they recognize that trade would be a greater loss than any gains from war could recompense.
As a senior dev I hate this. Of course I'm going to drop everything, if what I do stops making sense on an org level. Why would I do anything else.
Disagree.
In one of the companies I worked for. Management decided to adopt safe agile.
We had a dedicated agile coach for the whole department. Each team went to learn the safe agile principles and framework. The main focus was how do three teams get more aligned when building a solution: edge software, cloud software, application layer.
I can say after 3 months of sprints. The productivity improved, people were happier and now we know which feature is used by whom. The requirements were forced to become clear so it be translated into designs and then dev work with the definition of done.
When properly applied with the right intentions it is transformative.
You aren't likely to find the word "neoliberalism" used in politico, I don't think. All sources of news have an inherent bias that will constrain the acceptable range of discourse, along with terminology used.
How does something like this take 30% of your time? On my calendar it's two hours out of 80, or 2.5%. One hour per sprint for planning, one hour for retro, why would it be longer?

My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%.

My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.
Thousands of years of pre Adam smith history where the concept of macroeconomics did not exist. Obviously a naive implementation of monetary expansion causes price inflation, that doesn’t mean a well implemented monetary expansion does though.
Umm, who said that the global markets were free to begin with? It may be “free” for the west, but as soon as you step out of line with Washington, it doesn’t appear all that free. And I’m not talking about the most egregious actions like invading Ukraine, I am talking about things like monetary and energy policy.
Even if this was done 100% correctly, I still see a big problem with this approach:

The vulnerable function is unreachable now, but that could change with the very next commit.

So you are basically trading less work now for more work before the next release (which could sometimes make sense)
I only spoke for myself and it is quite... creative from you to assume otherwise. That aside I know many open source developers from various backgrounds and non of them is forced to write open source software in any kind of condition that would even remotely compare to slavery.

Maybe you know better and can educate me.
I don’t get your hero worship mentality. Talk about pessimism.
Step one is to be aware of your capacity to hurt; it seems like you have this covered. I find that over time my awareness has grown, which has caused me to care more (and be more careful) about the feelings of who I am communicating with.

I used to think something like, "If I can just get them to see that I didn't mean to hurt/mean it that way, they clearly won't be hurt!" This is not at all true for many (most?), and like many matters of emotion that's ok. I was not originally aware of the phrase "intent is not impact" but this idea is what I'm trying to describe above.

It is very important to approach this from a place of humility and non-defensiveness. Be eager to apologize for the hurt you caused. I'm sure you're a great person who doesn't wish to hurt people; apologizing doesn't mean that you're sorry you tried to hurt them but that you're sorry that you did. Think of it as the equivalent of apologizing for accidentally elbowing someone in the head. It's not like you meant to, but their head still hurts where you elbowed it.

Actually caring helps a lot; it helps remind you to think before you speak or write, and to pay attention to reactions. If you care, you tend to get better over time.
National debt surpasses $31T
You're supposed to be integrating everything and evaluating the big picture every sprint. You run into the mindless sub tasks if you don't look at the big picture, sprints or not.
Since chess.com ranks similar players against each other, and I'm not planning on tournament play at all, I actually wouldn't care in the slightest if I played someone who was consistently cheating. That would mean I'm playing a hybrid human/computer instead of a pure human, but I'd still be playing someone with a consistent ranking and it would still in some sense be a fair fight.

I would be upset if someone was inconsistently cheating, and so I'm playing someone nominally at 1400 but for this game they're actually playing 2100.

Of course for true tournament play, the rules are the rules, whatever they may be, and they must be followed for it to have any meaning.
Pine and Mutt were my jam back in those days. It really did depend on whether you were keen to use Pico or Vim as your reading/composing tool. (Although you could pretty much use whatever you wanted)
I think sprints (I've almost never used this in work and am not anti) are lacking something, limiting scope is one thing but do they ensure framing the problem / solution / design well too ?

The few times we've used sprints it was just issue dispatch and see you later, not really a guarantee of anything, but maybe I'm missing some information.
Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all.

The sprint forces a "this is what we're doing in these 2 weeks" with a deliverable at the end. If, at the end of the first sprint, you only got half the things done because of challenges, ok that's what it is. Next sprint you pick up only half as much work and you get that done.

Now, the PM can look at all the work that needs to be done and the rate of work that needs to be done and the amount of work and realizes that instead of the initial "yea, we can do this MVP in 3 months" that you're closer to having it out in 8 months if everything remains the same rate.

That is something actionable for project management to say "nope, can't have the MVP in 3 months with this scope" after only 4 weeks and the project can get canceled earlier.

Sprints try to make management realize overly optimistic estimates and timelines and either have things get adjusted (staff, scope, or time) or have it canceled sooner. Having a sprint based project canceled after 4 weeks rather than embarrassed and dragging out at 12 weeks is good for the organization to not spend resources on things that won't get done in the required timeframe.

The goal of the short framed boundaries is to force this decision sooner.
And probably replies with a 200 and a blocked page.

What you tend to see is the web firewall is administered by someone who has only one duty (manage this firewall) and very narrow set of skills (certification in this appliance). They probably have a very shallow understanding of the http protocol.
I teach a nonfiction "writing at work" workshop that's all about effective communication. The format is simple:

We work together on your writing as you’re writing. You send me your work in progress, I'll respond promptly with feedback and advice. I'll ask questions, flag awkward sentences, and help find the right language to get your point across. My focus is less on grammar and syntax, more on structure and framing, and even more on the content of the argument itself.

We'll exchange a bunch of email back-and-forths until you have a well-written message. It's free, email is in my profile if you're interested.
Ultima online just seems to have so many awesome stories.
> When a sprint starts, what QAs people are expected to do ?

Dedicated QA folk are redundant! The devs write automated tests for all the code they submit. It's 20 years since I spotted a dedicated QA person in the wild.
The are certainly available online. You just need to know where to look.
I agree that the employees do things for themselves and their own feelings rather than considering the market. But I also don't think you need to be a massive scale to make a successful alternative.
You missed one of the most important: to provide slack time. Ideally, the team will only commit to less than they can accomplish, so there is built in slack time to do research, training, tech debt, and proof of concepts.
‘Nobody can spell avocado ’ – shopping lists as works of art
Some background here: https://www.sciencedirect.com/topics/engineering/compressed-...
To me, a 10-hr window (eg 8am-6pm) doesn’t seem restrictive or even mildly inconvenient (definitely not enough to classify as IF), so maybe the insight here is that people regularly eat across all their waking hours - and not doing that is better.
> Real numbers are discrete at the infinitesimal limit (grab your torch and pitchforks).

I don't even know what that means. If you embed the real numbers in the hyperreals, where you do in fact have "infinitely close" numbers, those numbers aren't discrete either, as the hyperreal numbers are dense too.

> Loops roughly = integrals

I think this is the wrong way around. Loops loosely correspond to mathematical sums (finite or possibly countably infinite). We got integrals once people started asking themselves "what if you could have something like sums, but over intervals that are arbitrarily/infinitely small?". In that sense, integrals are an extension or generalisation of sums/loops - in the sense that sums are basically integrals with a discrete measure - but you don't need to more complicated, general concept to understand the simpler one.

Of course, different areas of maths (and CS is basically a branch of maths) are inter-linked. That's the beauty of maths. Some people will see calculus everywhere, others will immediately see connections to category theory, logic, topology, etc. Maybe in 50 years we will discover a new branch of maths and suddenly see that it can be found everywhere, but that doesn't mean that we needed to know that branch to do all the things we were doing up until that point.

But I don't think calculus is as fundamental to CS/programming as it is to, say, physics or much of the rest of the natural sciences. You do mention some examples (optimisation problems), but by and large I don't need to understand limits and Cauchy sequences to program a loop or even to prove statements about push-down automata or graphs or my favourite type system.

(You mention topology. Topology is an abstraction over analysis which can be used in discrete settings too, it doesn't fundamentally require the real numbers.)
(Sigh) This is just a religious pronouncement in a religious war. There are many processes out there - not just sprint, kanban, water fall, or "no process". Pick the process that works for your team.

As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benefits. It's a question of what works for the team.

Personally, I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say. Sprints with a heavy planning component work very well for that. But that's just my preference.

Teams should decide what method they're going to use and commit to making it work. They should also be open to recognizing when it isn't working for one reason or another and be willing to try something different occasionally.

The only piece of process I will always insist on is some sort of regular check in where we can introspect about the process and determine what aspects of it are and aren't working.
A cellular modem requires a crapload of power though, unless you keep it off most of the time. There's a reason why modern phones have batteries as huge as they do.
btw, seems there's a small typo (see wikipedia article "Immanentize the eschaton", from adjective "immanent")
> What is DocArray?

Still don't know what it is.
If anybody is interested in old brick building architecture revitalisations I strongly recommend visiting warsaw. It has:

- Powiśle Power Plant [1]

- Koszyki Hall [2]

- Norblin Hall [3]

- Praga Koneser Center [4]

to name just a few. There are more to come. The grounds are not broken by prime ministers, since they’re much more of a common occurrence. It’s a really nice sight and they also usually combine office space with retail space and sometimes apartments. Worth checking out

[1] https://elektrowniapowisle.com/en/o-elektrowni/

[2] https://en.m.wikipedia.org/wiki/Hala_Koszyki

[3] https://fabrykanorblina.pl/en/norblin-factory/

[4] https://en.m.wikipedia.org/wiki/Praga_Koneser_Center
Ok, nice idea with the qrcode, but (as far I can tell from a quick view into the source) it uses plain http?

On Android I'm happy with the apps I use anyway, e.g. Termux which offers ssh (both client and server), rsync, … or sftp via Solid Explorer.
College professor required this book and it is great. It's small, direct, and to the point. I highly recommend it.
What does this add to inotifywait? That does exactly the same as this project, which uses inotifywait to reimplement inotifywait.

For example:

dnf install inotify-tools
or
apt-get install inotify-tools
Free webinar training on public communication
Companies that are highly exposed to price volatility like wholesale electricity and gas prices can include some kind of energy hedging in their risk management portfolio. It will cost them money in good years but it keeps them from going out of business in bad years.

Companies that choose not to hedge make more profit in good years but must come begging to the government for bailouts or price controls in bad years. (i.e. shareholders pocket the profit while taxpayers cover the losses)

Depending on the government's response to those kinds of requests, you end up with more of one sort of company or the other.
This folds in with the mantra of "Do NOT think about blockers and interruptions when estimating your story points, only think about the task in a vacuum"... and then not looking at blockers and interruptions when judging your velocity and results, either.

The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.
The "essentially the plant is the brain" part is super-sensationalized nonsense. To the extent of the information provided, the robotic arm is just a visualizer of the electrical activity of the plant. And the machete is there only for the extra clicks.
Email list building made simple for NFT Collection owners
You can also use preact without a build step via htm

https://github.com/developit/htm#installation
More analogous to software development is the design of the house with the blueprints as output, and regulations, client review, and architect creative inspiration as the software specs. Nobody complains about blueprints being delivered too slowly. They just happen on a competitive landscape where two people are racing to deliver to the client so the slowest person loses.

I like kanban, a stack of tasks with predefined dependencies determining if a card can be picked up, and sorted in priority order once they can be picked up. When something critical goes wrong, the entire team stops and works the problem individually, competitively , until the problem is solved, and the team then resumes their prior work. CI/CD delivers to production, features are enabled when they are ready and the customer is ready. Feedback goes immediately back into the stack and delivery leads constantly manage the feature flags, the stack priority, and inter team communication. The devs just dev and stop the line. The team tech lead, product lead, delivery lead, architect, and program/product lead do all the negotiations and priority setting. There are no estimates. You deliver constantly. You need strong leads and architects to run this way, and you should probably coach your client to expect slow change at first, and rapid change after the first release.

Done this at several clients, for several different domains, with lots of interdependent teams as a consultant, and it is highly productive. The one time it failed, we didn't get buy-in on feature flags in production and the client insisted on batched release branches and long-term maintenance branches for those cut releases.

The other, minor failure, is that it is very prone to momentum. That's when teams get overconfident that they can fix problems in-band with tasks (because they've been successful for so long), and are resistant to stopping the line. This can be spotted by a person not delivering a pr for more than two weeks, or not transitioning a card to done for more than two weeks. Tech lead calls a meeting, determines the issue, decides on stop the line or not.

It works. It's iterative. It keeps the number of communications channels and decision stakeholders low. It cross-polinates through linked dependencies. It ensures product cohesion thru feature flags. It evades critical missteps and bugs via stop the line. And it works well with our modern SSO dev/platform ops and integrated toolsets (Atlassian/clickup + ci pipeline of choice where docs, features, delivery can all talk to each other and reports can be generated for leads that pull from the integrated tools). It doesn't fix Conway's law, but I am not sure that actually needs fixing in truly large development houses.
https://ajkueterman.dev/posts/make-the-thing-better/
> OK, I take it your answer for visibility is management reporting, I am not sure about predictability

Not reporting. Reporting is an internal function. People would like to know what's happening and what's going to happen, so that they know roughly what to expect for planning purposes elsewhere in the business, e.g. marketing. Not just reporting for its own sake.
and android - https://play.google.com/store/apps/details?id=au.com.shiftyj...
Show HN
have a game at play.numberhive.org

Would love to hear your thoughts. MVP will be available for free download monday 10th Oct.
0% inflation is incredibly dangerous. Deflation is just about the worst possible thing that can happen to an economy. It instantly kills money market liquidity as real interest rates rise as they hit the lower bond for nominal rates. People stop spending as much as they can since their money will be worth more in the future. So the question is how can we guarantee no deflation. And the only answer is target 1-2% inflation.

By the way the us was in a recession for practically the entirety of the second half of the 19th century, mostly because of absolutely garbage monetary policy.
If I'm right the venerable ThinkPad X220 (T420 and so on) with Sandy Bridge (Intel HD3000) does use LVDS instead of eDP. And only some generations later Intel supported PSR with eDP. So it is safe?
That's fine, I wouldn't tell you otherwise. You just complained about a missing feature that isn't actually missing if you use the service properly and treat servers like cattle.
Why You Should Still Switch Envelopes
The category error of thinking scrum is the same as agile is a big contributor to the complaints.
I did see a round of speed chess between Magnus and Hans, I think it was 60 seconds on the clock. Does speed chess have the same cheating problem is the regular format?