Hasty Briefsbeta

All tags

#software-development

175 stories total

Bilingual

Five Years of Tinygrad
4 months ago
- First commit to tinygrad was on October 17, 2020.
- The company has grown to 6 people and the codebase is 18,935 lines (excluding tests).
- The goal is to compete with NVIDIA by focusing on a sovereign software stack before taping out a chip.
- Tinygrad is removing LLVM dependencies to run on AMD GPUs with pure Python.
- The project outperforms PyTorch on many workloads and aims to be around 20,000 lines when complete.
- Tinygrad follows the 'Elon process' for software: 'Make the requirements less dumb. The best part is no part.'
- The tiny corp operates openly with a Discord and GitHub, funding through a computer sales division ($2M revenue/year).
- AMD contract secured via public Twitter negotiation to get MI350X on MLPerf for Llama 405B training.
- Hiring is based on contributions to the repo, with minimal meetings and a focus on improving tinygrad.
- Mission: 'Commoditize the petaflop.'
The AI Noise
4 months ago
- AI is essential in the workplace for effective time use.
- Romantic engineers resist AI, preferring traditional coding methods.
- AI has changed software development, reducing focus on low-level design.
- AI tools are proliferating, creating overwhelming choices.
- Cognitive offloading is a risk with excessive AI tool use.
- The TIE framework helps manage AI tool integration effectively.
- Upcoming series will explore AI's role and human relevance in work.
Build Software. Build Users
4 months ago
- Vibe coding accelerates software development but raises questions about software quality.
- Quality software isn't guaranteed by extensive testing alone; understanding users is crucial.
- The 'bar explodes' meme illustrates how focusing only on code testing can miss user needs.
- LLMs can help understand users deeply by leveraging vast internet knowledge.
- Vibe coding users involves creating detailed user profiles and simulating their interactions.
- A suggested folder structure includes user groups, profiles, and happy paths for user flows.
- The workflow is iterative: vibe code users, then software, refining understanding continuously.
- Simplicity in software requires deep user understanding and fits into their workflows.
- Simulated users (as agents) can provide feedback to simplify and improve software quality.
- This approach differs from personas and user stories by starting with user simulation first.
- It also differs from traditional testing by prioritizing user understanding before development.
- Conclusion: Build agentic users first, then iterate with real and simulated users for quality software.
Building an internal agent: Code-driven vs. LLM-driven workflows
4 months ago
- The article discusses the comparison between code-driven and LLM-driven workflows for building internal agents.
- Initially, the author believed LLM plus tool-usage could solve complex workflows but later realized some problems are simpler with software.
- A real-world example is given where an LLM-powered workflow was used to mark merged pull requests in Slack but sometimes incorrectly, causing inefficiency.
- The solution involved implementing support for both LLM and code-driven workflows, allowing custom Python scripts to handle cases where LLMs aren't reliable.
- The hybrid approach uses LLMs for initial workflow handling and switches to code-driven workflows as a progressive enhancement when needed.
- The author concludes that even as models improve, using them narrowly for cases requiring intelligence rather than iterative workflows is a long-term strategy.
The Cost of Software Libraries
4 months ago
- The article discusses the hidden costs of using software libraries, arguing that they are not free and come with trade-offs.
- Using libraries can lead to increased executable size, slower execution speed, and reduced maintainability.
- The author provides examples comparing custom command-line parsing code with the 'clap' library in Rust, showing significant differences in performance and size.
- Maintainability issues arise when depending on external libraries, as fixing bugs or adapting to changes can be time-consuming.
- The author suggests considering libraries only when their benefits significantly outweigh the costs or when under time pressure.
- The article concludes by emphasizing that libraries impose real costs on both users and developers, often leading to bloated and slow applications.
Cold-Blooded Software (2023)
4 months ago
- The author recalls a university lecture where a baby painted turtle, capable of surviving being frozen, was used to demonstrate cold-blooded animals' ability to adapt their metabolism to environmental temperatures.
- Cold-blooded animals, like the painted turtle, become active in warmth and slow down as temperatures drop, contrasting with warm-blooded animals that maintain a stable body temperature.
- The author draws a parallel between cold-blooded animals and software projects, distinguishing between 'warm-blooded' projects that require constant activity to survive and 'cold-blooded' projects that can be paused and resumed without issues.
- Cold-blooded software projects use stable, boring technology, avoid external dependencies, and can remain functional over long periods without maintenance, exemplified by the author's 12-year-old blog software written in Python 2.
- The author's blog software, relying on vendored dependencies and local operations, has required minimal updates over the years and is expected to remain functional for many more.
LocalFirst: You Keep Using That Word
4 months ago
- Local-first software is hard to define and exists on a spectrum rather than being a binary label.
- Local-first implies multi-device but is often conflated with offline-first; servers are allowed but should be optional.
- True local-first software requires owning your data, implying the need for open-source applications.
- Webapps are not ideal for local-first due to their inherent need to 'phone home'.
- Multiplayer features are not essential for all local-first apps; some apps benefit from avoiding them.
- Solutions for local-first include building native apps, open-source development, and avoiding spinners.
- Future challenges include adapting email, chat, and social media to local-first models.
I like when apps are "finished"
4 months ago
- The author advocates for normalizing the idea of software being 'finished' rather than continuously updated.
- Many apps are functional as they are and don't need constant updates, but users often mistake lack of updates for abandonment.
- Open-source projects are particularly susceptible to being labeled 'unmaintained' if they haven't had recent commits, even if they work perfectly.
- The author contrasts software with art, arguing that most software is utilitarian and doesn't need endless refinement.
- The post suggests that the tech industry should embrace more 'finished' apps and move away from subscription models.
Developers Are Solving the Wrong Problem
4 months ago
- Vibe coding is a controversial topic, seen as either revolutionary or harmful to code quality.
- Traditional coding values like clean, modular, and concise code aim to ease debugging, extending, and maintaining.
- The shift to vibe coding reflects a focus on solving problems quickly rather than perfecting code structure.
- Vibe coding's popularity stems from its ability to allow users to iterate and solve problems rapidly without deep coding knowledge.
- Generative AI in vibe coding requires good underlying models, context, and robust testing tools to ensure quality.
- The future may see 'developer-less' companies as more people use generative AI to create solutions without traditional developers.
- Adapting to vibe coding involves treating it as a tool, improving prompts, and embracing rapid iteration and learning.
Maybe the database got it right
4 months ago
- The article discusses the historical distancing of databases in software development, favoring in-memory models and object-oriented programming.
- It highlights how despite efforts to minimize database influence, databases indirectly shaped system designs.
- The rise of ORMs and NoSQL movements further distanced relational databases, yet applications remained CRUD-heavy and relational.
- Modern frontend development and the need for expressive data queries led to solutions like GraphQL, reintroducing database-like features.
- Relational databases evolved, incorporating features from systems meant to replace them, suggesting they might have been right all along.
- The article questions whether the reflexive hiding of databases still serves current needs and suggests reevaluating their role in system design.
The spectrum of isolation: From bare metal to WebAssembly
4 months ago
- Execution environments are crucial for reliable software development, testing, and deployment.
- Isolation exists on a spectrum: hardware, kernel, process, filesystem, and language runtime.
- Physical machines (bare metal) offer maximum performance but are expensive and inflexible.
- Virtual machines (VMs) provide strong isolation but have significant overhead due to full OS instances.
- Containers are lightweight, share the host OS kernel, and are ideal for microservices.
- Process sandboxes restrict process interactions with the system for security purposes.
- Virtual environments manage language-specific dependencies but don't provide OS-level isolation.
- Modern toolchains combine runtime managers, path isolation, and package management for efficiency.
- Layered approaches (VM + containers + virtual environments) offer robust workflows.
- Future trends include containers as default interfaces, serverless computing, and WebAssembly (Wasm) for portable execution.
IKEA for Software
4 months ago
- The article discusses the challenges of building a production-grade software platform for managing solar mini-grids, highlighting the time-consuming process of setting up essential components like RLS rules, social login, and timeseries databases.
- It explores existing options for accelerating software development, including closed-source systems, low-code platforms, database wrappers, and AI, but notes their limitations in providing fully customizable, battle-tested solutions.
- The author compares the current state of software development to an artisanal craft, lacking standardized blueprints, and questions why a top-to-bottom approach (starting with pre-configured templates) isn't more common.
- Potential barriers to a top-to-bottom approach include system diversity, developers' preference for building from scratch, and the need for extensive documentation.
- The article proposes an 'IKEA of software' concept, where developers could share standardized, pre-configured cloud applications, reducing repetitive setup tasks and enabling passive income for creators.
- The conclusion suggests that while current tools focus on bottom-to-top efficiency, the future of software might lie in 'flat-pack' systems that allow starting at the top and customizing as needed.
The recurring dream of replacing developers
4 months ago
- The recurring cycle of promises to simplify software development has persisted for fifty years, from COBOL to AI, without eliminating the need for specialized developers.
- Historical attempts like COBOL, CASE tools, and Visual Basic aimed to democratize software creation but ultimately required specialized knowledge due to inherent complexity.
- AI coding assistants represent the latest advancement, enhancing developer productivity but not replacing the need for human judgment in handling complexity.
- Software development is fundamentally about managing complexity, which cannot be shortcut by tools alone, requiring thoughtful reasoning and expertise.
- Business leaders should focus on leveraging tools to enhance productivity while recognizing that human expertise remains essential for solving complex problems.
- The persistent dream of replacing developers drives innovation, leading to valuable tools that improve efficiency, even if the ultimate goal remains unfulfilled.
The Cathedral, the Megachurch, and the Bazaar
4 months ago
- The essay 'The Cathedral and the Bazaar' contrasted old open-source (cathedral) with new open-source (bazaar), but modern open-source has evolved into 'megachurches' like Linux, Python, and Node.js.
- Megachurch open-source projects are well-structured organizations with strict contribution rules, often supported by large companies and foundations.
- The bazaar still exists, representing most open-source projects—small, chaotic, and often maintained by single individuals without strict governance.
- Modern infrastructure relies heavily on the bazaar, but funding and sustainability for these small projects remain challenges.
- Initiatives like the Sovereign Tech Agency are exploring ways to fund open-source without strings attached, while policy suggestions aim for long-term solutions.
- Readers are encouraged to explore and support small open-source projects, understanding their role in the broader ecosystem.
Pushing the smallest possible change to production
4 months ago
- Pushing a small, insignificant change to production helps the author learn the new work environment.
- Examples include fixing a typo or deploying a 'Hello world!' app to understand workflows.
- This exercise answers key questions about source code access, version control, CI/CD, and deployment processes.
- It helps avoid frustration later when building features by understanding constraints early.
- Engaging with co-workers during this process builds relationships and camaraderie.
- Ending the first week with a tangible change sets a positive tone for the working relationship.
Gas Town's Agent Patterns, Design Bottlenecks, and Vibecoding at Scale
3 months ago
- Steve Yegge's Gas Town is a speculative agent orchestrator that runs dozens of coding agents simultaneously, sparking debates in the software engineering community.
- Gas Town is inefficient, burning thousands in API costs, but serves as a provocative piece of speculative design fiction, exploring future agentic coding systems.
- Design and planning become the bottleneck when agents write all the code, as human context, taste, and vision are irreplaceable.
- Gas Town's chaotic design reflects Yegge's ad-hoc approach, making it difficult for others to use but revealing potential patterns for future agent orchestration.
- Key patterns in Gas Town include specialized agent roles, hierarchical supervision, persistent agent identities, and ephemeral sessions.
- Gas Town uses a 'Beads' system for tracking atomic tasks and agent identities, stored in Git, enabling persistent work across sessions.
- The system employs continuous work streams, merge queues managed by agents, and aggressive prompting to keep agents on task.
- Gas Town is expensive, costing thousands monthly, but its potential value in speeding up development could justify the cost for some companies.
- Yegge advocates for 'vibecoding,' never looking at the code, raising the debate on whether developers should still review code in an agent-driven future.
- The right distance from code depends on factors like domain, risk tolerance, project type, team size, and developer experience.
- Future tools will need to balance speed with quality, focusing on thoughtful design, planning, and coordination as development accelerates.
Joel Spolsky: Painless Software Schedules (2000)
3 months ago
- Amtrak's Acela express train marketing campaign ran before the service was available, highlighting the importance of timing in product launches.
- Lotus delayed their 123 version 3.0 by 16 months to fit it into older hardware, by which time the hardware was obsolete and Microsoft had a lead with Excel.
- Netscape's decision to rewrite their browser from scratch led to a significant loss in market share, demonstrating the risks of major overhauls without a clear schedule.
- Creating a schedule is essential for software projects, yet many programmers avoid it due to perceived pain and lack of belief in its value.
- Using Microsoft Excel for scheduling is recommended over complex tools like Microsoft Project, as it simplifies the process and avoids unnecessary complexity.
- Schedules should include fine-grained tasks measured in hours, not days, to ensure accuracy and better planning.
- Only the programmer who will write the code should schedule it, as they understand the necessary steps and time required.
- Including time for debugging, integration, vacations, and buffer in the schedule is crucial for realistic planning.
- Managers should not force programmers to reduce estimates, as this leads to unrealistic schedules and demotivation.
- Schedules help in prioritizing and cutting unnecessary features, leading to a better product that ships on time.
37signals Isn't Smarter Than You, but They Are Different
3 months ago
- 37signals' engineering strategy includes staying small, ruthlessly cutting scope, and hiring top engineers.
- Their codebases are significantly smaller in lines of code (LOC) compared to typical companies, with fewer lines per developer.
- Most companies follow a 'more features equals more money' mindset, leading to bloated codebases and compromised hiring.
- 37signals' strategy creates a flywheel effect: cleaner code, reduced headcount, and attracting top talent.
- Many businesses can't adopt 37signals' strategy due to lack of product-market fit or unwillingness to cut scope.
- 37signals' success isn't due to genius but a disciplined strategy that prioritizes quality over quantity.
Package Management Is a Wicked Problem
3 months ago
- Horst Rittel and Melvin Webber introduced 'wicked problems' in urban planning in 1973, describing them as problems that change when you try to solve them.
- Package management is a wicked problem due to its complexity, involving millions of packages, versions, and downloads, with small improvements affecting all dependent projects.
- Rittel and Webber identified ten characteristics of wicked problems, each applicable to package management.
- 1. No definitive formulation: The problem and solution are intertwined, with different interpretations of terms like 'package management'.
- 2. No stopping rule: Package managers evolve continuously without a definitive endpoint.
- 3. Good-or-bad rather than true-or-false: Solutions are subjective, based on stakeholder perspectives.
- 4. No immediate or ultimate test: Consequences of decisions emerge over time, making it hard to evaluate alternatives.
- 5. Irreversible consequences: Decisions leave lasting impacts, like typosquatting in PyPI or version ranges in npm.
- 6. No well-described set of solutions: Conflicting stakeholder goals make it impossible to enumerate all solutions.
- 7. Essential uniqueness: Solutions are context-specific, as seen in npm, Cargo, and Python's different approaches.
- 8. Symptoms of other problems: Issues like supply chain security are entangled with broader systemic problems.
- 9. Multiple causal explanations: Different stakeholders propose competing theories for problems and remedies.
- 10. No right to be wrong: Package manager designers face high stakes, with no room for errors.
- The wicked problem framework explains why progress in package management is slow and solutions create new problems.
- Rittel and Webber advocated participatory planning, emphasizing stakeholder collaboration and continuous iteration.
- The article suggests shifting focus from perfect tools to better communication and interfaces, like a shared protocol for package management.
Lobsters Vibecoding Challenge (Winter 2025-2026)
3 months ago
- The author challenges the claim that generative chatbots can develop any software by proposing a series of tasks to test their capabilities.
- Three main tasks are outlined: improving a Brainfuck interpreter's performance, porting a Raku compiler to a statically compiled language, and optimizing a Python-based task for speed.
- Each task has specific requirements, grading tiers based on performance and code quality, and estimated timeframes for completion.
- Solutions must be 'vibecoded' (prompt-based), functional, compile with Nix, and include context and work logs for verification.
- The author emphasizes readability, security, and ethical considerations in the development process.

first prev6next

About|Login

#software-development

Five Years of Tinygrad

The AI Noise

Build Software. Build Users

Building an internal agent: Code-driven vs. LLM-driven workflows

The Cost of Software Libraries

Cold-Blooded Software (2023)

LocalFirst: You Keep Using That Word

I like when apps are "finished"

Developers Are Solving the Wrong Problem

Maybe the database got it right

The spectrum of isolation: From bare metal to WebAssembly

IKEA for Software

The recurring dream of replacing developers

The Cathedral, the Megachurch, and the Bazaar

Pushing the smallest possible change to production

Gas Town's Agent Patterns, Design Bottlenecks, and Vibecoding at Scale

Joel Spolsky: Painless Software Schedules (2000)

37signals Isn't Smarter Than You, but They Are Different

Package Management Is a Wicked Problem

Lobsters Vibecoding Challenge (Winter 2025-2026)