Reinventing the wheel, but every time different. The author shares its experience.
Consider standards for it: they are powerful.

Some wheels I see that I think could use some new takes but which I don’t have the time/energy to do myself:

• Web browsers - probably the most significant. The browser market is essentially a monopoly right now. And Firefox is pretty much the only alternative option, somewhat of a monopoly in itself. We need to have many independent browser projects going on, not just an alternative.
• Higher education - this is probably too big a project for any one person, but I think there’s a lot of ground that needs new work and reevaluating in the world’s current higher education system.
• Task management - there are a lot of task management systems out there, but I think there’s still definitely room for more. I’m personally beginning to settle on a hybrid analog/digital task management system I’m designing myself.

The problem with that is, if everything is highlighted, nothing stands out.

Broken syntax should not be highlighted too. So Tonsky recommends to

Highlight names and constants. Grey out punctuation. Don’t highlight language keywords.

and because developers are not payed to the line of code anymore, "Comments should be highlighted, not hidden away."

Many developers prefer the dark mode because the dark mode can have less vibrant colors.

I suspect that the only reason we don’t see more restrained color themes is that people never really thought about it.

The term was coined to explain a deliberate process where you write software quickly to gain knowledge

"If you discover a better way to do things, the old way of doing it that is embedded in your code base is now “debt”:

• you can either live with the debt, “paying interest” in the form of all the ways that it makes your code harder to work with;
• or you can “pay down” the debt by fixing all the code in light of your new knowledge, which takes up front resources which could have been spent on something else, but hopefully will make sense in the long term.

Technical debt isn’t just bad code—it represents the lessons you’ve learned about how to build software better. Refactoring isn’t “paying off a debt,” but investing in applying that knowledge. Ignoring it wastes what you’ve learned and, over time, leads to lost value and competitive disadvantage compared to those who actively improve their code.

Can I really say “we now know” that the existing code is inferior? Is it true that fixing the code is “investing my knowledge”?

1. Feature complete. Features do not need to be added.
2. It is secure.
3. No maintenance needed (can broke while

Implications: if build tools change, then we may not be able to modify our software. If hardware, platforms, interpreters or external APIs change, the software may stop working. That's the implication.

Examples of finished software:

1. The Nintendo Gameboy
2. Job Sheet Manager
3. A multitude of embedded systems (DVD player, ...)
4. Some small JS apps and libraries

How to make them?

1. Understand the requirements. There must be a definition of done.
2. Keep scope small and fixed
3. Reduce dependencies
4. Produce static output
5. Increase quality assurance: don't fix bugs - avoid them

(via https://sebsauvage.net/links/?nhyv5A)

1. Find out what is seen as valuable
2. Deliver value as often as possible to get feedback
3. Write and maintain integration tests that survive refactoring
4. Avoid Object-Oriented Programming, or at least be extra careful with it
5. Remember you can still add in that complication tomorrow
6. Be conscious of what makes you over-engineer
7. Get yourself a better definition of perfection

A collection of antipatterns and how to avoid them

Time management can be useful

1. Organizations don't use that much data.

Of queries that scan at least 1 MB, the median query scans about 100 MB. The 99.9th percentile query scans about 300 GB.

but 99.9% of real world queries could run on a single large node.

I did the analysis for this post using DuckDB, and it can scan the entire 11 GB Snowflake query sample on my Mac Studio in a few seconds.

When we think about new database architectures, we’re hypnotized by scaling limits. If it can’t handle petabytes, or at least terabytes, it’s not in the conversation. But most applications will never see a terabyte of data, even if they’re successful. We’re using jackhammers to drive finish nails.

As an industry, we’ve become absolutely obsessed with “scale”. Seemingly at the expense of all else, like simplicity, ease of maintenance, and reducing developer cognitive load

Years it takes to get to 10x:
10% -> ~ 24y
50% -> ~ 5.7y
200% -> ~ 2.10y

Scaling is also a luxurious issue in many cases: it means the business runs well.

2. Hardware is getting really, really good

In the last decade:
SSDs got ~5.6x cheaper, 30x more on a single SSD and 11x faster in sequential reads and 18x in radom reads.
CPUs core count went up 2.6x, price went down at least 5x per core, each Turin core is also probably 2x-2.5x faster.

Distributed systems are also overkill as hardware progresses faster.

I think taste is the ability to adopt the set of engineering values that fit your current project.

map and filters looks good in JS for arrays, but they are absent in Golang for example. "[...] it would be far too arrogant for me to say that engineers who prefer for loops are simply less skilled. In many cases, they have technical capabilities that I don’t have. They just care about different things. In other words, our disagreement comes down to a difference in values."

About arguing the best solution:

Even if the big technical debates do have definite answers, no working software engineer is ever in a position to know what those answers are, because you can only fit so much experience into one career.

Almost every decision in software engineering is a tradeoff, and immature engineers are too inflexible about their taste.

The taste is a mix of priorities over resiliency, speed, readability, correctness, flexibility, portability, scalability and development speed. There are many other engineering values: elegance, modernness, use of open source, monetary cost of keeping the system running, and so on. All of these are important, but no engineer cares equally about all of these things.

A bad taste means values that are not a good fit for the project.

good taste is the ability to select the right set of engineering values for the particular technical problem you’re facing

#define MAKE_U32_FROM_TWO_U16(high, low) ( ((uint32_t)(high) << 16) | ((uint32_t)(low) & 0xFFFF) )

Piccalilli shares links!

When we look around in our field, everyone in Tech seems to focus on one thing: "How can we adopt AI in our tooling and in our processes?"

So it is a proof of a bubble. Everyone is enthusiasts but it doesn't solve real use cases.

A rightful question can be: "How can we set up our engineers for long-term career success?"

Jens Meiert ask pertinent questions to solve this big up question.

What can be done reasonably well with AI today? (And tomorrow? And the day after tomorrow?)
How are our engineers affected by AI?

• Are our engineers using AI?
• How are our engineers using AI?
• What are realistic expectations for our engineers in terms of AI use and proficiency?
• Are we setting clear expectations for use of and proficiency with AI in our job descriptions as well?
• Do we document and anchor these expectations in our competency and skill matrixes?
• Are we watching the AI market, and are we evaluating tooling?
• While the AI market is in flux—which it may be for some time—, do we have enough flexibility (budget, processes, room for errors) to test AI tooling?
• If our engineers leave the company, would they find a new job—or would their profile make them less interesting?
• If they would not necessarily find a new job, what extra skills and experience do they need?
• How can we make our engineers ready for the AI age?

As you can tell, we cannot have all those answers yet—this is precisely why this is so important to get on top of, and it’s also the reason why I say “start answering.”

Now, everyone’s a prize exhibit in the FAANG zoo, because mastering this tangled mess is what opens their gates. Being just a CRUD monkey doesn’t feel fun anymore. If this is what “progress” looks like, I don’t want any part of it.

The technologies to build for 10 years ago dramatically improved!

As mentionned by LeHollandaisVolant, one thing the article doesn't mention is that:

• 1 the pages are more interactive
• 2 the data changes in real time

(via https://sebsauvage.net/links/?IVGhhg)

Hi, I’m Rob Weychert. I make art and design, obsess over film and music, hoard trivial archival data, and share it all on this here website. Enjoy your stay.

This manifest critics modern (bloated, unreliable and worsening over time) softwares.
It favorises self-reliant programming (few features and simplicity, minimum amount of dependencies, write your own tools). It has benefits such as learning, improving skills, simpler code, simpler tools, easy modification and deployment.

1. Adopting: A small group of enthusiastic engineers selects and introduces the stack while building a prototype or MVP.
2. Expanding: The stack proves useful… so it spreads. More features, more developers, more tooling.
3. Normalizing: The stack becomes the default. Teams standardize around it. Hiring pipelines and best practices emerge.
4. Fragmenting: Pain points surface. Teams bolt on new tools or sidestep old ones. Internal consistency erodes.
5. Drifting: the stack feels sluggish. Upgrades are deferred. The excitement is gone.
6. Debating: conversations shift to rewrites or migrations. Confidence is shaken.
7. Recommiting: teams pause, reflect, and decide to reinvest the stack... and their shared future with it.

These stages are a spiral and are detailed in-depth in this post.

About adoption: Are you adopting this stack because you believe in its long-term fit… or because it feels exciting right now?

An organization of developers dedicated to writing free and open source software for everyone.

What if we were to model a typical software development lifecycle in code?

1. Breaking it down into small parts that are more approachable for solving, and also give us a steady sense of progress.
2. Priorise: ship the most valuable parts first and perhaps discard some low priority slices.
3. Over its life, it gathers context about various things.
4. Solving: define acceptance criteria then solve until we meet them
5. Verifying

When is a unit considered done? When the slice has been served. When it’s in the hands of the user, in production, potentially behind a feature flag.

Kent Beck's writing about measuring developer productivity:

Be suspicious of anyone claiming to measure developer productivity. Ask who is asking & why. Ask them what unit they are measuring & how those units are connected to profit.

I am 100% pro-accountability. Weekly delivery of customer-appreciated value is the best accountability, the most aligned, the least distorting.