In my opinion, nothing could be more wrong. GitHub's own ratings are easily manipulated and measure not necessarily the quality of the project itself, but rather its Popularity. The problem is that popularity is rarely directly proportional to the quality of the project itself.
I'm building a product and I'm seeing what important is the distribution and comunication instead of the development it self.
Unfortunately, a project's popularity is often directly proportional to the communication "built" around it and inversely proportional to its actual quality. This isn't always the case, but it often is.
Moreover, adopting effective and objective project evaluation tools is quite expensive for VCs.
I've seen the same devs refuse to use a library because the last commit was 3 months ago, despite the library being extremely popular, battle tested, and existing for 10 years.
> measure not necessarily the quality of the project itself, but rather its Popularity
Surely a project's popularity is often related to its utility. A useful and popular project seems like exactly the kind of thing a VC might be interested in.
> All "access control" logic lived in the JavaScript on the client side, meaning the data was literally one command away from anyone who looked
This is the top!
This is a typical example of someone using Coding Agents without being a developer: AI that isn't used knowingly can be a huge risk if you don't know what you're doing.
AI used for professional purposes (not experiments) should NOT be used haphazardly.
And this also opens up a serious liability issue: the developer has the perception of being exempt from responsibility and this also leads to enormous risks for the business.
The problem isn't AI, the problem is lack of an intelligent person somewhere in this whole situation. Way before AI I've seen a medical company create a service where frontend would tell backend what SQL queries to execute.
Claude, opencode etc. Are brute force coding harnesses that literally use bash tools plus a whole bunch of vague prompting (skills, AGENT.md, MCP and all that stuff) to nudge them probabilistically into desirable behavior.
Without engineering specialized harnesses that control workflows and validate output, this issue won‘t go away.
We‘re in the wild west phase of LLM usage now, where problems emerge that shouldn’t exist in the first place and are being solved at the entirely wrong layer (outside of the harness) or with the entirely wrong tools (prompts).
Many homosexuals are visually identifiable as such (with reasonable certainty), some by accident and some by deliberate signalling. I can easily see how the absence of any such signals could end up as a classification as heterosexual, even though it really should put them in the "unknown" category.
Of course any automated classification of that kind quickly gets problematic in multiple ways. In the EU it's a fast-track to getting your AI labeled as a "high risk AI system" that has higher requirements for quality control, ensuring fairness and user choice, etc
Tagged both me (male) and my male partner as heterosexuals. I think there is still some learning to do on that front. Rainbow merchandise has not been as widely adopted as you might think.
A bit like "they do not have cancer", if you are fitting to a distribution you will have the best results by estimating an average. Being hetero is the majority/average, so a good prediction.
But doing this on a 20-way parlay like in this case will almost always fail.
this doesn't even pass a basic logic test, why would be wounded make us seek something we want in ourselves and being whole make us seek something we aren't? there are plenty of people of any gender that have any quality you may be seeking
you can't just make something up in your head and apply it to everyone
I propose a further and different "key to understanding."
I would add: the second thing to decide, besides the scale, is the Plan.
What do we mean, for example, by the "Ethical Plan." By ethical plan, I mean the purpose... "WHAT do I use mathematics for"?
Mathematics can be something immensely BIG if I use it for something important.
Or it can be miserably SMALL if I use it for something petty and trivial.
In short: even in this case, greatness depends not only on the scale, but also on the eyes of the beholder, on the Context in which it is applied, and, why not?, also on the Purpose and the ethical plan.
If mathematics were, for example, something at the service of Justice, it would be something immensely Big.
> If a single writer handles batches of writes (or reads!), build each batch greedily: Start the batch as soon as data is available, and finish when the queue of data is empty or the batch is full.
> ..prioritize observability before optimization. You can't improve what you can't measure. Before applying any of these principles, define your SLIs, SLOs, and SLAs so you know where to focus and when to stop.
These principles apply not only to individual applications, but also to all systems as a whole. The single-writer principle improves performance both when writing/reading large databases and when reading/writing to RAM. Where input/output is intensive, performance improves even further.
> Commit count by month, for the entire history of the repo. I scan the output looking for shapes. A steady rhythm is healthy.
But what does it look like when the count drops by half in a single month?
Let's NOT jump to conclusions; it could mean many things. For example, a period with other priorities, different urgencies, other issues external to the project itself and beyond our control, vacations, illnesses, or anything else that could impact the commit history.
I think these considerations and the others expressed in this article can easily lead to hasty conclusions and erroneous deductions, too simplistic.
Coding flow, like business needs, cannot always be objectively and deterministically measured.
> The shed is where you take the blueprints you learned on the job and actually get to play with them.
> You try something in the shed on a weekend because you’re curious. You learn the tradeoffs, the rough edges, the things the documentation doesn’t tell you. Then months later, when the team at work is evaluating that same tool or approach, you’re not starting from zero.
These are two opposing concepts, but both True and complementary.
Working for clients (or companies) and home-based side projects are two sides of the same coin and complement each other. What must drive you, in both cases, is curiosity and the passion to do something useful.
My dream is to be able to turn a home-based project into something that generates income. My goal is to have the freedom to work on what I love and on a useful and profitable project of my own.
> Doing a day of manual labour, chatting shit, then going for the onsen and some BBQ and beers is far better than grinding away at some enterprise SaaS that will probably disappear in a few years.
I particularly agree with this statement.
I don't know why manual work has been so denigrated over the last century. We believed that office labor was more important and healthier than manual labor. I don't think so.
As a developer, sitting all day typing in a stuffy office, without natural light, without sun, without air, is certainly no healthier than being outdoors, connecting with nature and other people. We come from nature and are made to be active, outdoors, and in the sunlight.
Today, with AI, many white-collar jobs are being called into question, and perhaps we can go back to loving certain traditional jobs.
I don't think it's that deep: Obligatory manual labor destroys the body (and, often, the mind) and what time you have you spend exhausted. Being entirely sedentary remains a choice for us office workers—this is why people exercise and spend time outside.
Of course, I would like more flexibility in choosing how much I and where I do my sedentary labor, so I might devote time to, say, gardening. But it's easy to forget that humans have spent most of human history trying to escape subsistence farming.
I have worked subsistence farming for a small portion of my life, and I cannot tell you how hard it is, physically and psychologically. That was by choice, as part of essentially joining my wife's culture and family. If I were to do that for the remainder of my life it would destroy me.
Anyway, I'm going to go happily work from my desk 30 ft from my bedroom while drinking coffee likely farmed for about ~$0.30/hour while I make a few hundred times that.
> But it's easy to forget that humans have spent most of human history trying to escape subsistence farming.
Do you define human history as the last ~10k years or last ~100k-500k years?
But yes, certainly at least the last 3000 years for most humans have been spent farming to a large degree. But if we are even moderate in estimations of human origins, farming is very recent.
I think specifying "recorded history" would remove the confusion. Human history could refer to the history of anatomically modern humans, including before farming.
History is a bit of a confusing word that way; I suppose I can see it can be used in an informal sense to refer to any timeline outside of just historiography, which does tend to refer to a distinct study from archaeology and anthropology. Noted.
It truly is not a choice, as I cannot sustain my family / lifestyle with manual labor. Opting into working out for the sake of my health is not nearly the same.
>It truly is not a choice, as I cannot sustain my family / lifestyle
Success and failure are choices. Accepting this allows us to take responsibility for the worlds we've created. Ignoring this is self-destructive act of cognitive dissonance and we pay for it years later.
Tell that to crop failures of sustinance farmers. "Oh you just chose the weather to be bad/a fast soreading disease/a severe drought. Live with your choices".
The push to increase production and leave nothing on the table is insidious and will turn every work environment, be it manual labor, design, programming or excel factory into shit.
You'll end up burn out and hating the job (no matter the job) if the company you work for doesn't give a considerable weight to the wellbeing of employees (at the percieved cost of productivity and raw revenue).
I’d love to do manual labor as long as: I have a decent house, decent health insurance, can afford decent food/stuff, can afford taking sabbaticals, can afford getting sick and not losing my income, can afford decent education for kids, etc.
Unfortunately, many of us are chained to the modern way of life.
Don’t forget doing only enough manual labour not to get hurt, killed or develop a chronic condition.
You can make a lot of money doing many skilled manual jobs in my country. Trades are highly paid and there is not enough supply. Better money than software development.
They often wreck their backs, or develop other chronic conditions. The successful ones stop doing manual work by the time they are in their 40s and move to running their own businesses employing 20 year olds.
A friend of mine just lost a family member a few weeks ago. He slipped on a roof.
Forestry is well paid in NZ, the average forester is probably better paid than the average developer. Although the ceiling for software devs is much higher.
But Forestry also has the highest number of industrial accidents.
We have a strong health and safety regime and culture. Most primary industries are heavily automated. Yet it only takes a simple mistake to cause injury.
> I don't know why manual work has been so denigrated over the last century.
As a farmer, it is funny to see how people react to you based on the current profitability winds. When farming is a money maker, everyone acts envious and treats you like a king. When times are tough, they think you're a slack-jawed yokel.
I expect in that lies the answer to your question: We denigrate anything that isn't, as a rule, making a lot of money. Manual jobs generally haven't made much money in the last century, and humorously the exceptions, like professional athlete, get exempted from being considered manual work.
In my opinion, nothing could be more wrong. GitHub's own ratings are easily manipulated and measure not necessarily the quality of the project itself, but rather its Popularity. The problem is that popularity is rarely directly proportional to the quality of the project itself.
I'm building a product and I'm seeing what important is the distribution and comunication instead of the development it self.
Unfortunately, a project's popularity is often directly proportional to the communication "built" around it and inversely proportional to its actual quality. This isn't always the case, but it often is.
Moreover, adopting effective and objective project evaluation tools is quite expensive for VCs.
reply