Skip to main content

Links from my inbox 2024-12-01

· 42 min read

Good Reads​

2024-12-01 Legacy Shmegacy - David Reis on Software { davidreiscto.substack.com }

image-20241201132743791

People call some code legacy when they are not happy with it. Usually it simply means they did not write it, so they don’t understand it and don’t feel safe changing it. Sometimes it also means the code has low quality1 or uses obsolete technologies. Interestingly, in most cases the legacy label is about the people who assign it, not the code it labels. That is, if the original authors were still around the code would not be considered legacy at all.

This model allows us to deduce the factors that encourage or prevent some code from becoming legacy:

  1. The longer are programmer’s tenure the less code will become legacy, since authors will be around to appreciate and maintain it.
  2. The more code is well architected, clear and documented the less it will become legacy, since there is a higher chance the author can transfer it to a new owner successfully.
  3. The more the company uses pair programming, code reviews, and other knowledge transfer techniques, the less code will become legacy, as people other than the author will have knowledge about it.
  4. The more the company grows junior engineers the less code will become legacy, since the best way to grow juniors is to hand them ownership of components.
  5. The more a company uses simple standard technologies, the less likely code will become legacy, since knowledge about them will be widespread in the organization. Ironically if you define innovation as adopting new technologies, the more a team innovates the more legacy it will have. Every time it adopts a new technology, either it won’t work, and the attempt will become legacy, or it will succeed, and the old systems will.

The reason legacy code is so prevalent is that most teams are not good enough at all of the above to avoid it, but maybe you can be.

đŸ„’ 2024-12-01 Tech's $90B Ghost Engineer Problem: Stanford Study Finds 9.5... { socket.dev }

Beyond the economic and productivity concerns, ghost engineers pose significant security risks. Their lack of meaningful engagement can lead to a few critical issues: unreviewed or improperly tested code changes, unnoticed vulnerabilities, and outdated systems left unpatched. A disengaged engineer might also miss—or deliberately ignore—critical security protocols, creating potential entry points for malicious actors.

When these engineers aren't actively involved in maintaining secure practices, they can create blind spots in a company’s defense strategy, increasing the risk of breaches or compliance failures. Threat actors can exploit disengaged engineers through phishing, social engineering, or leveraging neglected updates and poorly reviewed code to infiltrate systems and compromise security. Addressing these gaps requires better oversight and collaborative practices.

Before you start side-eyeing your coworkers, it’s worth noting that measuring productivity in software engineering is notoriously tricky. Commit counts or hours logged are often poor indicators of true impact. Some high-performing engineers—the mythical “10x engineers”—produce significant results with fewer, well-thought-out contributions.

However, the “ghost engineer” trend exposes systemic inefficiencies in talent management and performance evaluation. Remote work policies, once heralded as a game-changer, are now under the microscope. They’ve enabled flexibility for many but have also given rise to the ghost engineering phenomenon. The tug-of-war over remote versus in-office work is likely to intensify as companies grapple with these kinds of leadership and accountability issues.

image-20241201002539567

2024-11-30 The deterioration of Google { www.baldurbjarnason.com }

I'm Baldur Bjarnason, a web developer and writer. In my latest essay, I wrote about the decline of Google and its impact on independent publishers.

image-20241130153023657

Here's a quick summary:

  1. Independent Publishers Struggling: Many independent sites are shutting down due to a lack of traffic from Google and Facebook.
  2. Google's Machine Learning Issues: Google's attempt to improve search results with machine learning has backfired, letting spam through and delisting quality content.
  3. Economic Impact: Even frugally run sites can't survive on the remaining traffic, leading to significant financial struggles for creators.
  4. Algorithm Black Box: Google's algorithm has become so complex that even their engineers can't fully understand or fix it.
  5. Monopoly Power: Google's monopoly allows it to capture value without improving product utility, leaving users with fewer alternatives.

2024-11-30 15 Lessons From 15 Years of Indie App Development { lukaspetr.com }

Hey there, I'm Lukas Petr, an indie iOS app developer from Prague. Over the past 15 years, I've learned a lot about the ups and downs of indie app development. Here are some key takeaways:

image-20241130153146170

  1. Enjoy the Process: Loving what you do is crucial. If you don't enjoy the journey, it will be tough to stick with it.
  2. Understand Your Motivation: Know why you're doing this. For me, it's about creating something meaningful and useful.
  3. Risk and Reward: The risk is high, but the reward of fulfilling work and ownership is worth it.
  4. Find Your Niche: Focus on what you believe in and what scratches your own itch.
  5. Provide Additional Value: Aim for sustainable value over time, not just quick gains.
  6. Wear Many Hats: Be prepared to handle everything from development to marketing.
  7. Reflect Regularly: Regular introspection helps you stay on track and improve.
  8. Learn and Apply Lessons: Keep evolving and improving based on your experiences.
  9. Find Support: Surround yourself with people who can help propel you forward.
  10. Luck: Sometimes, success involves a bit of luck, but you have to put yourself out there.

I hope you find these insights helpful. If you're pursuing any creative endeavor, I'm rooting for you! Feel free to reach out if you have any questions or comments.

2024-11-24 A career ending mistake — Bitfield Consulting { bitfieldconsulting.com }

A career-ending mistake isn't always a catastrophic error like shutting down a nuclear power station or deleting a production database; it's often subtler, like failing to plan for the end of your career. The article explores how many of us rush through our professional lives without a clear destination, highlighting that "career" itself can mean "to rush about wildly." It asks the critical questions: “Where do you want to end up? And is that where you're currently heading?” Instead of drifting, the piece advises us to define what we truly want, as "The indispensable first step to getting what you want is this: decide what you want." Whether you're content in your current role or seeking something more fulfilling, understanding your end goal and working intentionally toward it is key to avoiding a career that feels out of control.

Fun quote:

Engineering managers need a solid foundation of technical competence, to be sure, but the work itself is primarily about leading, supervising, hiring, and developing the skills of other technical people. It turns out those are all skills, too, and relatively rare ones.

Managing people is hard; much harder than programming. Computers just do what you tell them, whether that’s right or wrong (usually wrong). Anyone can get good at programming, if they’re willing to put in enough time and effort. I’m not sure anyone can get good at managing, and most don’t. Most managers are terrible.

That’s quite a sweeping statement, I know. (Prove me wrong, managers, prove me wrong.) But, really, would a car mechanic last long in the job if they couldn’t fit a tyre, or change a spark plug? Would a doctor succeed if they regularly amputated the wrong leg? We would hope not. But many managers are just as incompetent, in their own field, and yet they seem to get away with it.

2024-11-23 the tech utopia fantasy is over | ava's blog { blog.avas.space }

Growing up, I had a positive view of tech, believing it would bring comfort, less work, and personalized assistance. However, the reality has been different, with tech companies failing to deliver on their promises and instead contributing to issues like disinformation, economic inequality, and environmental harm. While there have been some benefits, such as increased political knowledge and social connections, the negatives now overshadow the positives. The tech utopia fantasy is truly dead to me.

2024-11-18 Good software development habits | Zarar's blog { zarar.dev }

  1. Keep Commits Small: Keep each commit focused on a single change to make it easier to track and revert issues. Code that compiles should be committable.
  2. Refactor Continuously: Follow Kent Beck's advice: make changes easy, then make the easy changes. Frequent, small refactorings prevent complex reworks.
  3. Deploy Regularly: Treat deployed code as the only true measure of progress. Frequent deployments ensure code reliability.
  4. Trust the Framework: Don’t test features already covered by the framework; focus on testing your unique functionality, especially with small components.
  5. Organize Independently: If a function doesn’t fit anywhere, create a new module. It’s better to separate logically independent code.
  6. Write Tests First (Sometimes): If unsure about an API’s design, start with tests to clarify requirements. TDD doesn’t have to be strict—write code in workable chunks.
  7. Avoid Duplication After the First Copy-Paste: If code is duplicated, it’s time for an abstraction. Consolidating multiple versions is harder than parameterizing one.
  8. Accept Design Change: Designs inevitably get outdated. Good software development is about adapting to change, not achieving a “perfect” design.
  9. Classify Technical Debt: Recognize three types of technical debt: immediate blockers, future blockers, and potential blockers. Minimize the first, address the second, and deprioritize the third.
  10. Prioritize Testability in Design: Hard-to-test code hints at design issues. Improve testability through smaller functions or test utilities to avoid skipping tests.

đŸ”„2024-11-14 Lessons from my First Exit · mtlynch.io { mtlynch.io }

Selling my first business was a journey filled with excitement, stress, and invaluable lessons. I want to share my experiences to help other entrepreneurs who might be considering a similar path. This post is especially relevant for small business owners and startup founders looking to navigate the complexities of a business exit.

Quote:

Used dedicated accounts for the business

Part of what made TinyPilot’s ownership handoff smooth was that its accounts and infrastructure were totally separate from my other business and personal accounts:

  • I always sent emails related to the business from my @tinypilotkvm.com email address.
  • I always used @tinypilotkvm.com email addresses whenever signing up for services on behalf of TinyPilot.
  • I kept TinyPilot’s email in a dedicated Fastmail account.
    • This wasn’t true at the beginning. TinyPilot originally shared a Fastmail account with my other businesses, but I eventually migrated it to its own standalone Fastmail account.
  • I never associated my personal phone number with TinyPilot. Instead, I always used a dedicated Twilio number that forwarded to my real number.
  • All account credentials were in Bitwarden.

After closing, handing over control was extremely straightforward. I just added the new owner to Bitwarden, and they took over from there. There were a few hiccups around 2FA codes I’d forgotten to put in Bitwarden, but we worked those out quickly.

For example, TinyPilot uses the H.264 video encoding algorithm. It’s patented, so we had to get a license from the patent holder before we shipped that feature. During due diligence, we discovered that the patent license forbade me from transferring the license in an asset sale.

I immediately started imagining the worst possible outcome. What if the patent holder realizes they can block the sale, and they demand I pay them $100k? What if the patent holder just can’t be bothered to deal with a tiny business like mine, and they block the sale out of sheer indifference?

đŸ”„ 2024-11-08 Blog Writing for Developers { rmoff.net }

Like a favourite pair of jeans that’s well-worn, comfy, and slightly saggy round the arse, I have a go-to structure for writing. Come to think of it, I use it for lots of conference talks too. It looks like this:

  1. Tell them what you’re going to tell them
  2. Tell them
  3. Tell them what you told them

What this looks like in practice is something along these lines:

  1. An intro

    What is this thing, and why should the reader give af be interested?

    This could be a brief explanation of why I am interested in it, or why you would want to read my take on it. The key thing is you’re relating to your audience here. Not everyone wants to read everything you write, and that’s ok.

    Let people self-select out (or in, hopefully) at this stage, but make it nice and easy. For example, if you’re writing about data engineering, make it clear to the appdev crowd that they should move on as there’s nothing to see here (or stick around and learn something new, but as a visitor, not the target audience).

  2. The article itself

  3. A recap

    Make sure you don’t just finish your article with a figurative mic drop—tie up it nicely with a bow (a đŸ™‡đŸ» or a 🎀, either works).

    This is where marketing would like to introduce you to the acronym CTA (Call To Action) 😉. As an author you can decide how or if to weave that into your narrative.

    Either way, you’re going to summarise what you just did and give people something to do with it next. Are there code samples they can go and run or inspect? A new service to sign up for? A video to watch? Or just a general life reflection upon which to ponder.

2024-11-07 Monorepo - Our experience { ente.io }

We switched to a monorepo nine months ago, and it’s been working well for us. Before, we had multiple repositories, which made things like managing pull requests or syncing changes a hassle. With everything in one place now, the workflow feels smoother and simpler. It wasn’t a decision we overanalyzed; it just felt like the right time to try it, and we’ve been happy with the results.

The main pros? First, there’s less repetitive work. Instead of opening multiple pull requests across repos for a single change, now it’s just one. Submodules, which were always a pain to manage, are mostly gone. Everything that needs to work together stays in sync naturally. Refactoring has also become easier because we can see the whole picture in one place, which encourages code improvements over time. Plus, being in the same repo has made us feel more connected as a team. Even small things, like seeing everyone’s changes when pulling updates, help us stay in the loop without extra effort.

As for cons, we honestly haven’t found many. A common concern is that monorepos can get messy or slow as they grow, but for our small team, it hasn’t been an issue. We kept it simple—no strict rules, just “don’t touch the root folder”—and it’s been fine. It might not work the same for larger teams or projects with different dynamics, but for us, it’s been a clear win.

2024-10-14 LogLog Games { loglog.games }

I spent three years using Rust for game development, and after shipping a few games and writing over 100,000 lines of code, I’m stepping away from it. Rust has some great qualities—its performance is top-notch, and it often lets you refactor confidently. But for fast, iterative development, which is crucial for indie games, it just doesn't align well. The borrow checker and Rust’s strictness often force unnecessary refactoring, slowing down the process of prototyping and testing new ideas. Tools like hot reloading, essential for quick feedback loops, are either clunky or nonexistent in Rust. And while the language excels in many technical areas, its game development ecosystem is still young, with fragmented solutions and limited support for things like GUI and dynamic workflows.

For small teams like ours, the priority is delivering fun, polished games quickly. With Rust, I found myself spending more time fighting the language and its ecosystem than focusing on gameplay. Moving forward, we’re transitioning to tools that better support rapid iteration and creativity, even if they’re less "perfect" on paper.

2024-09-29 It's hard to write code for computers, but it's even harder to write code for humans · Erik Bernhardsson { erikbern.com }

image-20241201135538368

Onboarding is Key: Users should get started quickly and see results fast. Fix: Simplify setup. Remove steps and make the tool easy to use immediately. For example, ensure API tokens are ready without extra configuration. The faster users see success, the more likely they’ll stick around.

Show Examples First: Abstract explanations confuse users. Fix: Use examples instead of long concepts. Show how the tool works with real use cases. When I write docs, I always start with practical examples users can copy and tweak.

Errors Need Solutions: Errors frustrate users. Fix: Make error messages helpful. Suggest fixes and show code snippets. A clear path back to success turns frustration into trust.

Avoid Too Many Ideas: Too much upfront information overwhelms users. Fix: Keep it simple. Focus on a few core ideas to start. When I design a tool, I aim for 3-5 basic concepts that cover most use cases. Fewer concepts, fewer headaches.

Use Familiar Terms: New words confuse people. Fix: Use common terms like "function" instead of inventing new ones. I think about how people already think about code and try to fit my tool into their existing mental model.

Flexibility Matters: Rigid tools frustrate creative users. Fix: Let users program their own solutions with APIs or scripts. Make everything programmable so users can adapt the tool to their needs.

Don’t Overdo Magic: Hidden behaviors often fail in edge cases. Fix: Keep defaults clear and reliable. Avoid adding unnecessary complexity. Unless I’m 99% sure a “magic” behavior will always work, I avoid it. Instead, I focus on being predictable.

Clarity Over Brevity: Short, clever code is hard to read. Fix: Write clear, readable code. Make it easy to follow. I remind myself: people read code far more than they write it.

2024-09-29 Too much efficiency makes everything worse: overfitting and the strong version of Goodhart’s law | Jascha’s blog { sohl-dickstein.github.io }

When you optimize too much, you can make things worse instead of better. This is the essence of the strong version of Goodhart’s Law: when a measure becomes the target, over-optimization can degrade what you originally cared about. This principle, often studied as "overfitting" in machine learning, also applies broadly to systems like education, economics, and governance.

The Problem: When proxies (measurements or secondary goals) are optimized too well, the actual outcomes worsen. For instance, standardized testing shifts focus from genuine learning to test preparation, undermining education. Similarly, rewarding scientists for publications incentivizes trivial or false findings over meaningful progress. Overfitting to proxies creates harmful side effects, from filter bubbles in social media to inequality in capitalism. How to Fix It: Lessons from Machine Learning

  1. Better Alignment: Make proxies closer to real goals. In machine learning, this involves better data collection. In broader systems, it means crafting laws, incentives, and norms that encourage genuine outcomes, like prioritizing long-term learning over test scores.
  2. Regularization: Introduce penalties or costs for extreme behaviors. Just as machine learning uses mathematical constraints, systems can add friction:
    • Tax extreme wealth disparities or excessive lawsuits.
    • Impose costs for high-volume actions, like bulk emails or algorithmic trading.
    • Penalize complexity to discourage harmful optimization.
  3. Inject Noise: Add randomness to disrupt harmful optimization. Examples include:
    • Randomized selection in competitive admissions to reduce over-preparation.
    • Random trade processing delays to stabilize financial markets.
    • Unpredictable testing schedules to encourage holistic studying.
  4. Early Stopping: Halt optimization before it spirals out of control. In systems, this could mean:
    • Capping time spent on decision-making relative to its stakes.
    • Freezing certain information flows, like press blackouts before elections.
    • Splitting monopolies to prevent market over-consolidation.
  5. Restrict or Expand Capabilities:
    • Restrict: Limit system capacities to prevent runaway effects, like capping campaign finances or AI training resources.
    • Expand: In some cases, more capacity reduces trade-offs, such as developing clean energy or transparent information systems.
BibTeX entry for post:
@misc{sohldickstein20221106,
  author = {Sohl-Dickstein, Jascha},
  title = {{ Too much efficiency makes everything worse: overfitting and the strong version of Goodhart's law }},
  howpublished = "\url{https://sohl-dickstein.github.io/2022/11/06/strong-Goodhart.html}",
  date = {2022-11-06}
}

2024-09-29 Measuring Developers' Jobs-to-be-done - by Abi Noda { substack.com }

2024-09-29 Measuring Developers' Jobs-to-be-done | Hacker News { news.ycombinator.com }

Google used to measure how well developer tools worked by evaluating how they supported certain tasks, like "debugging" or "writing code." However, this approach often lacked specificity that would be useful for tooling teams. For instance, "searching for documentation" is a common task, but the reason behind it—whether it's to "explore technical solutions" or "understand the context to complete a work item"—can meaningfully change a developer's experience and how well tools support them in achieving their goal.

To provide better insights, Google researchers identified the key goals developers are trying to achieve in their work and developed measurements for each goal. In this paper, they explain their process and share an example of how this new approach has benefited their teams.

image-20241201140955980

2024-10-05 Bureaucrat mode - by Andrew Chen - @andrewchen { andrewchen.substack.com }

As companies scale, they often shift from the agile, conviction-driven "Founder mode" to "Bureaucrat Mode," where decision-making slows, and processes dominate. While startups thrive on speed and direct action, large organizations tend to create committees, expand scopes, and reward consensus over outcomes. These tendencies, while rooted in good intentions like collaboration and stability, can cripple innovation and efficiency when scaled excessively.

The Problem: Bureaucrat Mode emerges as companies grow, driven by processes meant to manage complexity. However, these processes often become self-perpetuating, encouraging behaviors that prioritize internal metrics, visibility, and team expansion over meaningful results. Bureaucrats, focused on navigating processes rather than solving problems, replicate themselves by hiring others who thrive in such environments. This cycle of self-replication entrenches inefficiency and resistance to change.

image-20241201141318646

2024-10-10 How to make Product give a shit about your architecture proposal – Andy G's Blog { gieseanw.wordpress.com }

When dealing with Product teams about your architecture proposal, picture yourself as a plumber who's trying to sell different service packages. This analogy highlights how you should present your technical proposals to Product in a way that aligns with their focus on business value. They’re not interested in technical jargon; they want to know how your architecture decision translates into a return on investment.

Remember that Product people are looking for results. Instead of overwhelming them with details about OLTP systems or ETL processes, you need to frame your explanation as a negotiation — highlighting the costs and benefits of each option, just like the plumber did with his service packages.

"Product doesn’t give a shit about how your data is stored. Product cares about products."

The essence here is to avoid diving into the weeds of indexes or table joins until they understand the impact on their budget and timeline. When they ask, “Why is this so expensive?” that’s your cue to explain, in clear terms, the complexity involved in implementing things like OLAP systems or setting up ETL processes.

Approach your conversation by outlining different “packages” — starting with the đŸ„‡ platinum package that covers all technical needs but at a higher cost. This sets the stage for a value discussion, where Product sees the full picture and starts to understand the trade-offs involved.

"Now you can (gently) talk to them about the difference between online transaction processing systems (OLTP) and online analysis processing systems (OLAP)."

The trick is to guide Product through a step-by-step decision-making process, laying out each feature as a line item on an invoice. This approach helps them grasp which elements of your proposal can be trimmed down or delayed to fit within their budget constraints. For example, if they can't afford a new OLAP system, offer scaled-down options, and negotiate on scope and time rather than quality.

đŸ”„ One of the most crucial points is not to compromise on quality. In software development, you should avoid falling into the trap of lowering standards just to meet short-term goals. Sacrificing quality often leads to delivering subpar products that can damage customer satisfaction in the long run. As the article states, “What’s worse, delivering something a customer actually hates, or delivering nothing at all?” Maintaining a baseline of quality ensures that even with limited resources, you're delivering something worthwhile.

If the Product team suggests cutting corners to fit the project into a two-week sprint, resist the temptation. The iron triangle of software development — time, scope, and budget — should always consider quality as a non-negotiable factor.

Ultimately, you're helping Product to ruthlessly prioritize tasks to deliver the best possible outcomes within the given constraints. In these negotiations, scope will often be the main variable that can be adjusted to balance the budget and timeline. And when the tables turn, and it’s your idea that needs their buy-in, present it in terms of ROI to make a compelling case.

Think like a plumber: when you know the value of what you’re selling, it’s easier to convince others to invest in the right solution instead of a quick fix. Always push for a solution that maintains a minimum level of quality, even if it means delivering less within the same time frame.

2024-11-03 Get Me Out Of Data Hell — Ludicity { ludic.mataroa.blog }

đŸ“č 2024-11-03 Nikhil Suresh - Skills that programmers need, to defend both their code and their careers - YouTube { www.youtube.com }

This blog narrates an engineer's daily struggle with an overly complex and inefficient data warehouse system. Despite working within an ostensibly supportive team, the engineer describes their workplace as a "Pain Zone," rife with convoluted processes, unchecked errors, and cultural dissonance. Here’s a detailed breakdown of the main points:

The story begins with a ritual of starting the day with a senior engineering partner. Together, they embark on a shared mission to navigate the "Pain Zone," their term for the warehouse system plagued by unnecessary complexity. The data warehouse in question involves copying text files from different systems, and ideally, this process should require only ten steps. However, the engineer discovers over 104 discrete operations in the architecture diagram, a staggering example of the platform's inefficiency.

"Retrieve file. Validate file. Save file. Log what you did. Those could all be one point on the diagram...That's ten. Why are there a hundred and four?"

The engineer describes the necessity of "Pain Zone navigation," a practice where engineers rely on pair programming for moral support to withstand the psychological toll of working in such an environment. The issue isn’t only technical; it’s deeply cultural. A culture that demands velocity while disregarding craftsmanship fosters an atmosphere where complexity and inefficiency go unchallenged. This attitude, the author suggests, results in the degradation of code quality, with engineers penalized for trying to refactor code.

To illustrate the dysfunction further, the author recounts a routine task: checking if data from sources like Google Analytics is flowing correctly. What they find instead is garbled JSON strings dumped in the logs without logical structure, with 57,000 distinct entries where there should be fifty. This revelation shows that for over a year, the team has been collecting "total nonsense" in the logs.

"We only have two jobs. Get the data and log that we got the data. But the logs are nonsense, so we aren't doing the second thing, and because the logs are nonsense I don't know if we've been doing the first thing."

Rather than address this critical error, management insists on working with the erroneous logs to maintain "velocity," a term often implying efficiency but, in this case, prioritizing speed over accuracy. The author describes the frustration of being told to parse nonsensical data instead of fixing the core issues—a situation summarized by the team motto: "Stop asking questions, you're only going to hurt yourself."

The cultural disconnect deepens as the author tries to work with data from Twitter, only to find that log events lack an event ID. A supposed expert suggests using a column with ambiguous file path strings, each lacking logical identifiers, requiring complex regular expressions to infer events.

"I am expected to use regular expressions to construct a key in my query."

In yet another disheartening revelation, the author learns that the Validated: True log entries are merely hardcoded placeholders, not actual validation statuses. The logs fail to capture real system states, effectively undermining auditability.

By the end, the author reaches a breaking point, realizing their values diverge sharply from those of the organization. This disconnect prompts them to resign, choosing to invest their time in personal projects and consulting instead. In a closing reflection, they criticize the industry for investing in trendy tools like Snowflake and Databricks, without hiring engineers who understand how to design simple, effective systems.

"I could build something superior to this with an ancient laptop, an internet connection, and spreadsheets. It would take me a month tops."

This piece is a critique of both overly complex architectures and a corporate culture that prioritizes speed over quality. It highlights the importance of valuing craftsmanship and straightforward design in building sustainable and efficient data systems.

2024-11-24 SciFi book: Manna – Table of Contents | MarshallBrain.com { marshallbrain.com } (RIP Marshall)

With half of the jobs eliminated by robots, what happens to all the people who are out of work? The book Manna explores the possibilities and shows two contrasting outcomes, one filled with great hope and the other filled with misery.

Join Marshall Brain, founder of HowStuffWorks.com, for a skillful step-by-step walk through of the robotic transition, the collapse of the human job market that results, and a surprising look at humanity’s future in a post-robotic world.

Then consider our options. Which vision of the future will society choose to follow?

image-20241124100143433

  • đŸ˜ș The building we exited was another one of the terrafoam projects. Terrafoam was a super-low-cost building material, and all of the welfare dorms were made out of it. (Chapter 4)

Newsletters​

2024-09-20 JavaScript Weekly Issue 705: September 19, 2024 { javascriptweekly.com }

2024-09-29 Digital signatures and how to avoid them { newsletter.programmingdigest.net }

2024-09-29 Implementing Blocked Floyd-Warshall algorithm { newsletter.csharpdigest.net }

2024-10-18 JavaScript Weekly Issue 709: October 17, 2024 { javascriptweekly.com }

2024-10-20 How Discord Reduced Websocket Traffic by 40% { newsletter.programmingdigest.net }

2024-10-27 A Brief Introduction to the .NET Muxer { newsletter.csharpdigest.net }

2024-10-27 That's Not an Abstraction { newsletter.programmingdigest.net }

2024-11-17 Exploring the browser rendering process { newsletter.programmingdigest.net }

2024-12-01 Legacy Shmegacy { newsletter.programmingdigest.net }

Working with People​

2024-11-23 Take the Thomas-Kilmann Instrument | Improve How You Resolve Conflict {kilmanndiagnostics.com}

image-20241123122604326

Related:

In conflict situations, individuals often exhibit different behavioral strategies based on their approach to managing disagreements. Avoiding is one strategy, and here are four others, alongside avoiding, commonly identified within conflict management models like the Thomas-Kilmann Conflict Mode Instrument (TKI):

Avoiding

  • Behavior: The individual sidesteps or withdraws from the conflict, neither pursuing their own concerns nor those of the other party.
  • When it's useful: When the conflict is trivial, emotions are too high for constructive dialogue, or more time is needed to gather information.
  • Risk: Prolonging the issue may lead to unresolved tensions or escalation.

Competing

  • Behavior: The individual seeks to win the conflict by asserting their own position, often at the expense of the other party.
  • When it's useful: When quick, decisive action is needed (e.g., in emergencies) or in matters of principle.
  • Risk: Can damage relationships and lead to resentment if overused or applied inappropriately.

Accommodating

  • Behavior: The individual prioritizes the concerns of the other party over their own, often sacrificing their own needs to maintain harmony.
  • When it's useful: To preserve relationships, resolve minor issues quickly, or demonstrate goodwill.
  • Risk: May lead to feelings of frustration or being undervalued if used excessively.

Compromising

  • Behavior: Both parties make concessions to reach a mutually acceptable solution, often splitting the difference.
  • When it's useful: When a quick resolution is needed and both parties are willing to make sacrifices.
  • Risk: May result in a suboptimal solution where neither party is fully satisfied.

Collaborating

  • Behavior: The individual works with the other party to find a win-win solution that fully satisfies the needs of both.
  • When it's useful: When the issue is important to both parties and requires creative problem-solving to achieve the best outcome.
  • Risk: Requires time and effort, which may not always be feasible in time-sensitive situations.

Each of these strategies has its strengths and limitations, and the choice of approach often depends on the context of the conflict, the relationship between the parties, and the desired outcomes.

Wellbeing​

2024-11-03 On Burnout, Mental Health, And Not Being Okay — Ludicity { ludic.mataroa.blog }

In this deeply personal blog post, the author reflects on the mental health struggles that many people face, sharing candid experiences with burnout and severe depression. They emphasize that everyone will have times when they are "Not Okay," and it's important to acknowledge this without shame. Through their own journey of overcoming hardship—ranging from academic pressures to toxic workplaces—they highlight the significance of seeking help, making lifestyle changes, and understanding that recovery is possible. The author encourages readers to care for themselves and others, reminding us that empathy and support can make a profound difference in navigating life's challenges.

✹ New wiki category:

2024-12-01 Psy-Burnout (mental wellbeing) { blog.zharii.com }

image-20241201143408170

Fun / Retro​

2024-11-23 calculatorwords.pdf 344 Words You Can Spell On a Calculator

Compiled by Jim Bennett 2014

image-20241123191431682

ALL NUMBERS ARE HERE
EnglishNumbersEnglishNumbersEnglishNumbers
BE38BEE338BEEBE38338
BEES5338BEG638BEGS5638
BEIGE36138BELIE31738BELIES531738
BELIZE321738BELL7738BELLE37738
8ELLES537738BELLIES5317738BELLS57738
BESIEGE3631538BESIEGES53631538BESS5538
BESSEL735538BESSIE315538BIB818
BIBLE37818BIBLES537818BIBS5818
BIG618BILB00.8718BILE3718
BILGE36718BILGES536718BILL7718
BILLIE317718BILLIES5317718BILLS57718
BLESS55378BLESSES5355378BLIGH46178
BLISS55178BLISSES5355178BL0B8078
BL0BS58078B0B808B0BBI18808
B0BBIE318808B0BBIES5318808B0BBLE378808
B0BBLES5378808B0BS5808B0G608
B0GGLE376608B0GGLES5376608B0GIE31608
B0GIES531608B0GS5608B0IL7108
B0ILS57108B0ISE35108B0LE3708
B0LES53708B0LL7708B0LLS57708
BOO008BOOB8008B00BIES5318008
B00BS58008B00GIE316008B00GIES5316008
B00LE37008B00S5008B00ZE32008
B00ZES532008B0SE3508B0SH4508
B0SS5508B0SSES535508B0Z00.208
B0Z0S50208EBB883EBBS5883
EEL733EELS5733EGG663
EGGS5663EGGSHELL77345663EGGSHELLS577345663
EG00.63EG0S5063EL8E3873
ELEGIES5316373ELI173ELIGIBLE37816173
ELISE35173ELISEO0.35173ELL773
ELLIE31773ELLIS51773ELLS5773
EL0ISE351073ELSE3573ELSIE31573
ESSIE31553GEE336GEES5336
GEESE35336GEL736GELS5736
GE00.36GE0L0GIES531607036GIBBS58816
GIBE3816GIBES53816GIG616
GIGGLE376616GIGGLES5376616GIGOLO0.70616
GIGOLOS5070616GIGS5616GIL716
GILES53716GILL7716GILLS57716
GISH4516GLEE3376GLI88176
GLOB8076GLOBE38076GLOBES538076
GLOBS58076GL0SS55076GL0SSES5355076
GL0SSIES53155076G0B806G0BBLE378806
G0BBLES5378806G0BI1806G0BS5806
G0EBBELS57388306G0ES5306G0G606
G0GGLE376606G0GGLES5376606G0G0L70606
G0LLIES5317706G00GLE376006G00SE35006
G00SES535006G0S506G0SH4506
G0SHES534506HB00.84HE8E3834
HEEL7334HEELS57334HEGEL73634
HELI0S501734HELL7734HELLISH4517734
HELL00.7734HELL0S507734HELLS57734
HES534HESS5534HESSE35534
HIE314HIES5314HIGH4614
HIGHS54614HILL7714HILLEL737714
HILLS57714HIS514HISS5514
HISSES535514H0B804H0BBES538804
H0BBIES5318804H0BBLE378804H0BBLES5378804
H0BBS58804H0B00.804H0B0ES530804
H0B0S50804H0BS5804H0E304
H0ES5304H0G604H0GGISH4516604
H0GS5604H0LE3704H0LES53704
H0LLIE317704H0LLIES5317704H0LLIS517704
H0SE3504H0SES53504IBIS5181
IBISES535181IB00.81IGLOOS500761
ILL771ILLEGIBLE378163771ILLS5771
ISIS5151ISLE3751ISLES53751
LIZ217LIZZIE312217L0B807
L0BBIES5318807L08E3807L08ES53807
L08S5807L0G607L0GE3607
L0GES53607L0G00.607L0G0S50607
L0GS5607L0IS5107L0LL7707
L0LLS57707L00SE35007L00SES535007
L0SE3507L0SES53507L0SS5507
L0SSES5355070BESE353800BLIGE361780
0BLIGES53617800B0E30800B0ES53080
0BSESS5535800BSESSES535535800GLE3760
0GLES537600HI00.1400H00.40
0H0S50400HS5400IL710
0ILS57100ISE35100LE00.370
0LLIE3177000ZE320000ZES53200
0SL00.7500ZZIE31220SEE335
SEES5335SEIZE32135SEIZES532135
SELL7735SELLS57735SHE345
SHELL77345SHELLS577345SHEOL70345
SHES5345SHIES53145SHILL77145
SHILLS577145SHIL0H407145SH0E3045
SH0ES53045SH00S50045SIEGE36315
SIEGES536315SIGH4615SIGHS54615
SILL7715SILLIES5317715SILLS57715
SIL00.715SIL0S50715SIS515
SISES53515SISSIES5315515SIZE3215
SIZES53215SIZZLE372215SIZZLES5372215
SLEIGH461375SLEIGHS5461375SL0B8075
SL0BS58075SL0E3075SL0ES53075
SL0G6075SL0GS56075SL0SH45075
SL0SHES5345075S0B805S0BS5805
S0H00.405S0IL7105S0ILS57105
S0L705S0LE3705S0LES53705
S0LI1705S0LIS51705S0L00.705
S0L0S50705S0LS5705ZELIG61732
ZIB00.812Z0E302Z00S5002

2024-11-23 Rendering “modern” Winamp skins in the browser / Jordan Eldredge { jordaneldredge.com }

image-20241122173439101

2024-11-11 Pieter.com - Pieter's Official Homepage { pieter.com }

image-20241110220126116

2024-11-07 MAX SIEDENTOPF — Passport Photos { maxsiedentopf.com }

image-20241106225118042

2024-10-13 stenzek/duckstation: Fast PlayStation 1 emulator for x86-64/AArch32/AArch64/RV64 { github.com }

DuckStation is an simulator/emulator of the Sony PlayStation(TM) console, focusing on playability, speed, and long-term maintainability. The goal is to be as accurate as possible while maintaining performance suitable for low-end devices. image-20241201135052551

2024-06-18 Where Did You Go, Ms. Pac-Man? — Thrilling Tales of Old Video Games

image-20241201141626837

2024-06-27 Liquid Layers

2024-06-27 Liquid Layers | Hacker News

image-20241201141748969

2024-06-27 Science Fiction Writer Robert J. Sawyer: WordStar: A Writer's Word Processor

image-20241201141845220

2024-06-28 Advent of Code 2023 Day 19: Aplenty - YouTube

Advent of Code in Excel image-20241201142055161

2024-08-29 Web Design Museum - Discover old websites, apps and software { www.webdesignmuseum.org }

image-20241201142134615

2024-09-19 crowdwave.com { www.crowdwave.com }

Show HN: I made crowdwave – imagine Twitter/Reddit but every post is a voicemail

image-20241201142255701

2024-08-28 Monkeytype | A minimalistic, customizable typing test { monkeytype.com }

image-20240827232641786

Inspiration!​

2024-12-01 Andrew Ayer in the Fediverse { follow.agwa.name }

I honestly liked the design and layout

image-20241130200134882

2024-12-01 To the Fediverse! { www.fediverse.to } image-20241130200321657

2024-12-01 Pleroma — a lightweight fediverse server { pleroma.social }

image-20241130200618867

2024-12-01 src/App.scss · develop · Pleroma / pleroma-fe · GitLab { git.pleroma.social } Some good examples for using css variables with scss image-20241130201016998

2024-11-30 GitHub - tldraw/make-real: Draw a ui and make it real {github.com}

2024-11-30 make real ‱ tldraw {makereal.tldraw.com}

2024-11-30 GitHub - SawyerHood/draw-a-ui: Draw a mockup and generate html for it {github.com} ✹FORK SOURCE✹

image-20241130115413381 image-20241130115438468

2024-11-30 tldraw | Steve Ruiz | Substack {tldraw.substack.com}

image-20241130151615673

2024-11-27 Text Blaze: Snippets and Templates for Chrome {blaze.today}

image-20241127150049722

2024-11-26 Monocle · Access and transform immutable data { www.optics.dev }

image-20241125204603802

2024-08-28 The Monospace Web { owickstrom.github.io }

image-20241201135223177

image-20241201135322097

2024-11-24 triyanox/lla: A modern alternative to ls { github.com }

aww! ls with plugins!

image-20241124135202355

2024-11-24 I made an ls alternative for my personal use | Hacker News { news.ycombinator.com } elashri There seems to be a lot of projects that is now competing to replace ls (for people preferences)

For reference, those are the ones I am familiar with. They are somehow active in contrast to things like exa which is not maintained anymore.

eza: (https://github.com/eza-community/eza)

lsd: (https://github.com/Peltoche/lsd)

colorls: (https://github.com/athityakumar/colorls)

g: (https://github.com/Equationzhao/g)

ls++: (https://github.com/trapd00r/LS_COLORS)

logo-ls: (https://github.com/canta2899/logo-ls) - this is forked because main development stopped 4 years ago.

Any more?

Personally I prefer eza and wrote a zsh plugin that is basically aliases that matches what I have from my muscle memory.

2024-11-24 Frosted Glass from Games to the Web - tyleo.com { www.tyleo.com }

image-20241123212224379

2024-11-20 WebVM - Linux virtualization in WebAssembly { webvm.io }

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|                                                                             |
| WebVM is a virtual Linux environment running in the browser via WebAssembly |
|                                                                             |
| WebVM is powered by the CheerpX virtualization engine, which enables safe,  |
| sandboxed client-side execution of x86 binaries, fully client-side          |
|                                                                             |
| CheerpX includes an x86-to-WebAssembly JIT compiler, a virtual block-based  |
| file system, and a Linux syscall emulator                                   |
|                                                                             |
| [News] WebVM 2.0: A complete Linux Desktop Environment in the browser:      |
|                                                                             |
| https://labs.leaningtech.com/blog/webvm-20                                  |
|                                                                             |
| Try out the new Alpine / Xorg / i3 WebVM: https://webvm.io/alpine.html      |
|                                                                             |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

2024-11-08 Home: Mushroom Color Atlas { www.mushroomcoloratlas.com }

image-20241107222737497

2024-11-07 Your Hacker News { yourhackernews.com }

image-20241106225716990

2024-11-07 Aesop's Fables Interactive Book | Read.gov - Library of Congress { read.gov }

image-20241106224639993

image-20241106224700805

2024-11-07 McMaster-Carr { www.mcmaster.com }

McMaster-Carr’s website, www.mcmaster.com, is renowned for its speed, achieved through minimalist design, server-side rendering, and strategic use of technology like ASP.NET and JavaScript libraries. Prefetching techniques preload pages as users hover, ensuring near-instant navigation, while CDNs cache content globally to reduce latency. This streamlined, user-focused approach lets customers quickly access and order from McMaster-Carr’s extensive catalog, making it a leader in industrial supply and a favorite for its seamless, efficient experience.

image-20241106224136854

2024-10-05 Methods of Mandarin { isaak.net }

I got pretty good in Mandarin within 12 months of rigorous part-time study. I'm not even close to perfectly fluent, but I got far into intermediate fluency. Read my personal story of learning Mandarin here: isaak.net/mandarin

This post on my Methods of Mandarin (MoM) is for fellow language learners and autodidacts. This isn't a thorough how-to guide. I won't be holding your hand. It's more like a personal notebook of what worked for me. I'm sharing my personal Anki deck and then I'll describe all my methods and tips. People's styles and methods differ.

2024-08-29 sjpiper145/MakerSkillTree: A repository of Maker Skill Trees and templates to make your own. { github.com }

image-20241201134630051

2024-09-18 Dune Shell { adam-mcdaniel.github.io }

image-20241201134722315

2024-09-19 Comic Mono | comic-mono-font { dtinth.github.io }

image-20241201134806840

2024-09-20 Math4Devs: List of mathematical symbols with their JavaScript equivalent. { math4devs.com }

image-20241201134847457