In today’s rapidly evolving development landscape, harnessing the power of AI can feel like a superpower—giving you instant feedback, brainstorming partners, and even automated testing. This guide is a deep dive into how I currently integrate AI into my workflow to write, test, and deploy code faster than ever before. If you’re an experienced developer who’s already comfortable slinging code but wants to take advantage of AI’s productivity boosts, you’re in the right place.

👨‍💻 Who This Guide Is For

This isn’t a beginner’s guide to programming. Rather, it’s for seasoned engineers looking to optimize their existing workflow. You’ll see how AI can act as a brainstorming buddy, a design consultant, and a coding partner all rolled into one. The key is figuring out how to best orchestrate these tools so they complement your developer intuition without taking it over.

🛠️ My Toolkit

I use three main models, each with a distinct role:

• GPT-o1: My brainstorming collaborator, helping shape project requirements and architecture discussions.

• Claude 3.5 Sonnet: My go-to implementation partner for actual coding tasks.

• GPT-4o: Handling multimodality, such as converting my whiteboard sketches to Mermaid.js diagrams.

I access these models primarily through two tools:

1. macOS ChatGPT client: Great for voice-enabled Q&A and chatting with models.

2. Cursor: Perfect for feeding in specific instructions, generating code, and handling version control details like pull requests and commit messages.

Other tools I use:

• Claude Chat: Access Anthropic models via chat client

• Tabby & Ghostty: Tabby is my daily driver terminal, slowly starting to use Ghostty.

• Amazon Q (Formerly Fig): Terminal Autocomplete, if anyone knows of more modern open source alternatives to this — please let me know!

• DeployMate: Autogenerate my CI/CD Pipelines

I will cover my terminal and Cursor extension set up in another post if there interest — let me know!

📚️ What You’ll Learn

Over the course of this guide, I’ll walk you step by step through:

• Brainstorming & Requirements Gathering: Forming a clear project scope with GPT-o1.

• Design & Architecture: AI Augmented Whiteboard sessions to design and refine refine architectures.

• Instructions Documents: Creating detailed Markdown instruction files for Cursor to create amazing code.

• Cursor Integration: How to give Cursor precise prompts and structure your debugging workflow.

• Code Generation & Testing: Getting the most out of AI Augmented Coding while maintaining full control and oversight.

By the end, you’ll see how all these pieces come together, creating a seamless pipeline that transforms your ideas into working code—almost as quickly as you can think it up.

Let’s jump right in and explore how AI can supercharge your development process, starting with how I translate raw ideas into actionable requirements.

🧠 Brainstorming & Requirements Gathering

When I’m starting a new project, my first step is brainstorming and gathering high-level requirements. Here’s where GPT-o1 shines as a thoughtful brainstorming buddy—someone (or, well, something) that can push me to ask the right questions about the problem I’m trying to solve and the people I’m solving it for.

🤔 Understanding the Problem & Audience

I often begin with very open-ended questions about the domain, target users, and the core issues they face. For instance:

• “I want to build a product that helps construction workers create quotes faster. What problems do they typically face in that process?”

• “Which types of construction workers struggle most with quote generation—large companies or smaller contractors?”

• “How do these construction workers currently create quotes, and what are some pain points in that workflow?”

GPT-o1 will respond with ideas about inefficiencies, potential user personas, or overlooked challenges—often prompting me to think about features or angles I hadn’t considered.

🎯 Zeroing in on Features & Requirements

Once I have a clearer picture of the problem space, I use GPT-o1 to brainstorm features that could alleviate the identified pain points. This conversation might look like:

• “Given these challenges, what key features would help streamline quote creation?”

• “How might we integrate real-time price lookups or cost estimation tools?”

• “What kind of reports, dashboards, or analytics might these users need?”

GPT-o1’s suggestions here help shape a high-level feature set. For the quote creation example, it might propose:

1. Automated Cost Calculation based on materials, labor rates, and regional factors.

2. Template Library for common project types (e.g., roofing, foundation work, renovations).

3. Collaboration Tools to share or edit quotes with team members.

4. Version History to track changes and maintain transparency with clients.

📝 From Brainstorm to High-Level Requirements

Once these potential features are on the table, I’ll ask GPT-o1 to consolidate them into a list of initial requirements. These requirements usually include:

• Feature Name: A concise title (e.g., “Automated Quote Templates”).

• Short Description: One or two lines about the user need it addresses.

• Notes/Questions: Outstanding unknowns or assumptions (e.g., “Should we offer different templates by state or region?”).

This final list serves as my starting framework for the entire project. I save it as a reference in a simple text file or an early draft of my instructions.md—the same file I’ll later refine with more detailed specs.

🏁 What’s Next?

With a high-level outline of who we’re building for and what problems we want to solve, I’m ready to start thinking about how to implement these features. That’s where the AI-augmented design process comes in. In the next step, I’ll grab a whiteboard and ChatGPT Voice Mode to begin turning these raw ideas into tangible architecture and workflow diagrams.

🎤 Designing with a Whiteboard & ChatGPT Voice Mode

Designing the system architecture is where those raw ideas and high-level requirements start to take shape. Here’s how I use a good old-fashioned whiteboard—plus ChatGPT Voice Mode—to refine and validate my design concepts in real time.

✍️ Whiteboard for Big-Picture Design

I like to begin by sketching out the overall flow of the system on a whiteboard. This is the moment to visualize:

• Core Components (e.g., front end, back end, database).

• User Flows (In this example: creating a quote, editing a quote, approving a quote).

• Key Integrations (e.g., payment gateways, third-party APIs for cost lookups, etc.).

Why a Whiteboard?

• Tactile Feedback: Drawing arrows, erasing things, and physically standing in front of the design helps me think through problems in a spatial way.

• Iterative: Quick to adjust or pivot—just erase and redraw.

• Shared View: When collaborating with others on-site, it’s easy for everyone to gather around and point at specific parts of the diagram.

🎤 Real-Time Conversations with ChatGPT Voice Mode

While I’m sketching, I’ll have ChatGPT Voice Mode running on my Mac. This lets me ask questions out loud as I go:

By speaking these questions, I can get quick insights without breaking my flow to type them out. ChatGPT might point out performance considerations, remind me of best practices, or even suggest alternative approaches I hadn’t thought of.

💡 Why Voice Mode?

1. Speed of Thought: It keeps the brainstorming momentum going.

2. Less Context Switching: No need to stop drawing just to type; I can keep my hands on the markers.

3. Immediate Feedback: Helpful for sanity checks like, “Is this layer too coupled?” or “Are there libraries that handle this pattern well?”

🏗️ Evolving the Architecture

As my sketch becomes more concrete, I’ll often revise it in real time:

1. Identify Bottlenecks: ChatGPT might highlight areas that could become performance hotspots.

2. Validate Dependencies: If the design includes external APIs, I’ll confirm with ChatGPT that they can handle the expected load or provide the necessary data.

3. Tackle Unknowns: Questions like, “How should I layer multiple user roles within an organization?” can spawn deeper design discussions.

I’ll keep refining until the major building blocks feel logically sound.

📸 Converting Whiteboard Sketches to Mermaid.js

Once the main design is settled, I snap a photo of the whiteboard and feed it to GPT-4o through ChatGPT to convert the rough diagram into Mermaid.js code. This will then be used in an instructions.md file (more to come about that), ensuring the design is both visually clear and AI-friendly for subsequent steps.

📝 Creating the Instruction Documents

After sketching out your big ideas on the whiteboard, you’re ready to officially document your project’s purpose, scope, and implementation details in a way for AI tools—like Cursor—to parse understand what to build. We do this through multiple instruction documents, each focusing on a different aspect of the project.

🗂 Why Multiple Instruction Documents?

It might be tempting to dump everything into one massive file. But splitting your instructions into separate, focused documents makes it easier for Cursor to pinpoint relevant information based on the current coding task.

Key Benefits

• Modular Clarity: Each file covers a specific domain (database, backend, frontend, testing), so Cursor doesn’t get confused irrelevant details to the specific task at hand.

• Focused AI Prompts: Cursor can parse smaller, topic-specific files more thoroughly.

• Easier Maintenance: Updating one dedicated file is simpler than scanning a giant, all-in-one doc.

📂 The instructions/ Folder

I like to create a folder called instructions/ at the root of my project. Inside, I’ll include multiple Markdown files, each tailored to a specific part of the system:

1. instructions.md – Grand overview of the entire project.

2. database_instructions.md – Schema design and database references.

3. backend_instructions.md – Endpoints, authentication, server architecture.

4. frontend_instructions.md – UI mock-ups, tech stack decisions, and workflows.

5. testing_instructions.md – Guidelines for unit, integration, and E2E tests.

Depending on your project, you might add or rename these to fit your needs.

✨ instructions.md: The Grand Overview

This file serves as your central hub, laying out the crucial context that Cursor and other readers will need.

For my overview I like using Simon Sinek’s “Start With Why,”:

• Why: The core motivation or user problem behind your project. Providing this context helps Cursor make better implementation decisions when details aren’t explicitly spelled out. For instance, if the why is to boost performance for users on slow networks, Cursor might automatically recommend more efficient data-fetching patterns.

• What: The features and scope you plan to address. This is the roadmap of your project, giving the AI a clear idea of exactly what needs to be built.

• How: The chosen technologies, coding style, or architectural patterns you want to follow. Specifying your coding philosophies (e.g., modular microservices vs. monolith, React vs. Vue) tells Cursor how to approach each feature so it remains consistent with your standards. This is where you incorporate your Mermaid.js diagrams as well as drafting out your desired file structure for the project.

You might also list major milestones or release phases in the main instructions.md file.

🗃️ database_instructions.md

Here’s where you specify:

• Chosen Database: Whether you’re using Supabase, Firebase, MongoDB, etc.

• Schema Definitions: Tables/collections, relationships, indexes.

• Performance Considerations: Any caching strategies or indexing best practices to keep queries fast.

• Relevant Documentation: Providing references to any SDKs, Libraries you want to use for your database interactions.

By detailing this, you give Cursor enough background to generate coherent model definitions, data-access layers, or migration scripts.

⚙️ backend_instructions.md

Cover all things server-side:

• Architecture: Monolith vs. microservices, or perhaps a serverless approach.

• Authentication: How you plan to handle user logins and permissions (JWT, OAuth, sessions).

• Endpoints: REST/GraphQL endpoints, including expected inputs/outputs.

• Security: Guidance on handling secrets, API keys, and data sanitization.

Cursor uses this to scaffold your backend files and ensure each endpoint aligns with your security and performance needs.

🖥️ frontend_instructions.md

Focus on the user interface and client-side:

• Frameworks: Next.js, React, Vue, etc. TailwindCSS for CSS framework, etc.

• Component Libraries: 21st.dev, Shadcn, DaisyUI, etc.

• Data Flow: How state is managed and how data is fetched from the backend.

• Styling & Theming: Brand guidelines, color schemes, typography rules.

Giving Cursor these design details helps it propose front-end structures and even generate boilerplate code consistent with your layout.

🧪 testing_instructions.md

Testing is essential to reliability and maintainability:

• Test Types: Unit, integration, end-to-end (E2E).

• Frameworks: Jest, Pytest, Cypress, etc.

• CI/CD Integration: How tests run in your pipeline (GitHub Actions, GitLab CI).

• Coverage Goals: How much of your codebase should be tested.

With these guidelines, Cursor can generate test scaffolding that aligns with your chosen tools and coverage requirements.

🖼 UI Mockups

If you’re exporting wireframes or high-fidelity screens from Figma (or any other design tool), you can attach them directly to your prompts in Cursor Compose. This way, the AI has a visual reference for what the UI should look like and can tailor its code suggestions accordingly.

• File Placement: Store your PNG exports (e.g., login_screen.png, dashboard_mockup.png) in the instructions/ folder.

• Attaching in Cursor Compose: When writing your prompt, reference your mockup file explicitly so Cursor can factor it in. For example:

• Keep Images Updated: If you tweak your design in Figma, remember to re-export the PNG and re-attach it. This ensures Cursor sees the most accurate, up-to-date reference for your UI.

By including these PNGs in your Cursor Compose prompts, you help the AI generate code that aligns with your exact visual layout and user experience goals.

Armed with these instruction documents, you’ve given both yourself and Cursor a clear framework to follow. Next up, you’ll see how to feed this information into your coding environment so you can start building your project with AI guidance at every step.

🤖 Interacting with Cursor

Now that you’ve created your instruction documents—it’s time to put them to work in Cursor. This section covers how to structure prompts and optimize your workflow for both straightforward code generation and deeper debugging sessions.

🧐 What Model Do I Use?

Cursor supports a large variety of models and even allows you to run your own model for some features.

As of January 2025, I’ve prefer Claude 3.5 Sonnet and found it provides the highest quality code generation for my use cases.

🏷 Bringing Instructions into Cursor

Cursor offers two main interfaces for AI interaction: Composer and Chat. Each one can consume your prompts differently:

1. Cursor Compose

   • Ideal for generating or refactoring code.

   • You can attach specific Markdown files (like instructions.md or database_instructions.md) and reference them in your prompt.

   • Perfect for step-by-step feature implementation or larger codebase changes.

2. Cursor Chat

   • Functions like a conversation: helpful for debugging, clarifying questions, or exploring multiple approaches interactively.

   • You can paste snippets of your instructions here or reference them as needed to give the AI context.

💡 Prompt Strategies for Cursor

When you prompt Cursor, clarity and context are key. Here are some best practices:

🔖 Reference Relevant Instruction Docs

• Attach specific sections from your instructions documents.

• Identify the specific part of your instructions to build.

• Step by Step thinking through the implementation (adding this to the prompt helps improve output in chat client).

• For example:

This ensures Cursor understands the exact requirements and how you want those requirements built out.

📃 Summaries and Checkpoints

• After Cursor suggests code, review each suggestion, and approve one by one. It is best to review each change and comment on which changes need improvement rather than blindly accepting all proposed changes.

In the event Cursor has overlooked important constraints or design choices you outlined you can prompt around implementing the specific missed requirements.

🔍 When to Use Composer vs. Chat

Cursor Compose is best for implementation or large-scale refactors. You provide:

• A code file or multiple files.

• Relevant instruction docs.

• A structured prompt outlining what you want changed or added.

Cursor Chat works better as your live debugging buddy. If something isn’t compiling or a certain function is misbehaving:

Chat will propose fixes or alternative approaches, and you can keep iterating until it’s resolved.

🔧 Example Flow

1. Planning a Feature: Attach your instructions.md or relevant sub-file to Cursor Compose, specifying which feature you want to build first.

2. Generating Code: Let Cursor generate the logic.

3. Debugging: Switch to Cursor Chat if you hit a roadblock or want interactive Q&A.

4. Refinement: Return to Compose with updated instructions or code files to refine or extend the solution.

📌 Tip: Maintain Context

Cursor’s output depends heavily on the context it’s given. Make sure to:

• Attach or paste only the relevant instruction docs or code sections.

• Update your prompts with the latest insights or changes.

• Re-run the prompt if you add new info or instructions partway through.

By keeping Cursor “in the loop,” you’ll get outputs that consistently align with your project’s requirements.

With this interaction workflow in place, you can start building out your project feature by feature, using Cursor’s AI to move fast while maintaining quality. In the next section, we’ll dive into practical code and prompt examples, showcasing real-world snippets of how this process looks in action.

🧩 Code & Prompt Examples

Now that you know how to interact with Cursor and leverage your instruction documents, it’s time to see these concepts in action. In this section, we’ll walk through some practical scenarios—from generating new features to troubleshooting bugs—to illustrate how you can seamlessly integrate AI into your coding workflow.

⚙️ Generating a New Feature From Instructions

Let’s say you’re ready to implement a “Create Quote” feature in your backend. You have a solid outline in backend_instructions.md describing the endpoint behavior and authentication flow, plus a schema in database_instructions.md detailing how quotes should be stored.

Example Prompt in Cursor Compose

Let's complete feature 2 in @backend_instructions.md -- Please generate a new Fast API endpoint called /create-quote that:
1. Accepts JSON containing project details and user info.
2. Validates the data against our "quotes" schema in database_instructions.md.
3. Inserts the new quote into the "quotes" table/collection. Reference @database_instructions.md for database configuration.
4. Returns a 201 status with the newly created quote data.

Remember, follow the authentication rules in @backend_instructions.md (use our JWT-based auth).
Think step by step through the implementation

What Happens Next?

1. Context Check: Cursor reads the instructions on both the backend and database instruction files.

2. Generation: It outputs an Fast API endpoint based on the requirement.

3. Review & Refine: If you notice requirements are missing, you can ask Cursor compose to add those — such as if it forgot error handling.

4. Testing: Once generated, if something doesn’t work as expected, you should move to Chat for interactive debugging.

🐛 Debugging in Real Time

Let’s say the CREATE QUOTE endpoint runs into a runtime error. You jump into Cursor Chat:

When sending a POST request to the /create-quote endpoint I keep getting a 500 error, here's the logs @terminal line 20-55

Think step by step through the resolution of this bug, remember it is supposed to respond with the API message outlined in feature 2 of @backend_instructions.md

Make sure to use Command Enter when running the prompt in Cursor Chat, this will contextualize the question around your whole codebase.

Keep working through the bug with Cursor Chat until you are satisfied it’s resolved and then move back to Composer to implement tests before building the next feature.

🧪 Test Generation

Now that the CREATE QUOTE endpoint is running well. You want to create unit tests for it. Let’s go to Cursor Composer and enter:

Let's now test the /create-quote endpoint using a mock as described in @testing_instructions.md -- make sure this test has verbose logging for debugging purposes
Think step by step

In your testing instructions, specify that Cursor should provide a test suite covering both success and failure scenarios—using mocks for any external dependencies. This ensures your logic is thoroughly vetted and also makes debugging easier.

With the tests in place, you can quickly validate each new feature before moving on to the next item on your roadmap.

🚀 Conclusion & Future Outlook

As you’ve seen, integrating AI into your development workflow—from brainstorming with GPT-o1, sketching architecture with ChatGPT Voice Mode, organizing detailed instruction documents, to interacting with Cursor—creates a streamlined, context-aware process that accelerates both productivity and code quality.

Key Takeaways

• Holistic Context: By documenting the details of your project, you ensure that AI tools like Cursor make informed, context-rich decisions.

• Iterative Workflow: Whether it’s generating new features, refining existing code, or debugging on the fly, the combination of Compose and Chat keeps your development agile.

• Testing: Integrating automated tests ensures that your endpoints and components not only work but are also easier to troubleshoot.

• Visual Guidance: UI mockups attached directly in your Cursor Compose prompts help align generated code with your intended user interface.

🔭 Looking Ahead

AI technology is evolving at breakneck speed—and so is its role in software development. As AI continues to reshape our workflows, I’ll keep you posted on the latest strategies I use to maximize developer productivity.

If there’s interest, I’ll also dive into my project, DeployMate, which auto-generates CI/CD pipelines for me to streamline builds and deployments.

Happy coding, and see you in the next update!

-Justin

Cofounder & Head of Technology @ BetterFutureLabs

Website | LinkedIn | X

I’ve been finding NotebookLM super helpful for breaking down large bodies of text into more consumable formats like podcasts and casual summaries.

Check out Notebook LM’s take on the new Phi-4 model that Microsoft just launched.

Alright, let's talk about Phi-4. You know how everyone's been obsessed with making models bigger and bigger? Well, the folks behind Phi-4 decided to go a different route, and it's pretty interesting. Instead of just throwing more compute at the problem, they focused on something way more important: data quality. And guess what? It worked! This 14-billion parameter model is proof that you can achieve serious performance gains, especially in reasoning tasks, by being smart about your data, especially synthetic data. So, let's dive into how they did it.

Synthetic Data: Not Just a Cheap Trick

So, forget about just scraping the web and hoping for the best. The Phi-4 team went all-in on synthetic data, and not just as a stand-in for "real" data. They used it strategically because it has some real advantages:

• It's like spoon-feeding for models: Synthetic data lets you control the learning process, presenting challenges in a nice, gradual way, so the model can actually grasp complex patterns.

• It matches what the model will actually see: You can format your synthetic data to look like the kinds of outputs you expect from your model, which is super useful for things like chat interactions, where web forum data might not be the best fit.

They used some cool methods for creating this synthetic data, like multi-agent prompting, self-revision workflows, and instruction reversal. These techniques helped them build datasets that boost problem-solving skills, which is awesome.

Organic Data Still Matters (But It Needs a Makeover)

Okay, so synthetic data is a big deal, but the organic data used as the "seeds" is also important. The team didn't just grab any old data; they were super picky. They carefully filtered web content, books, and code repos, looking for the stuff that had real educational value and encouraged deep reasoning. They then used these high-quality "seeds" to generate their synthetic data.

Pretraining, Midtraining, and Post-Training: It's a Journey

The Phi-4 model went through three main stages of training, and each had some clever twists:

• Pretraining: This is where the model sees a ton of synthetic data, which helps it learn those complex reasoning skills. They mixed in web rewrites, filtered web data, and code data. What's cool is they realized that doing more rounds of training on the same synthetic data was better than just adding more web data.

• Midtraining: Here, they stretched the model's context window from 4K to 16K, which is a fancy way of saying the model can now handle longer bits of text. They also gave extra attention to data that was already longer than 4K.

• Post-Training: This stage is all about fine-tuning the model to be a helpful AI assistant. They used supervised fine-tuning (SFT) and something called Direct Preference Optimization (DPO). They also came up with a very smart technique called Pivotal Token Search (PTS) to make their DPO training even more effective.

Performance: It's a Reasoning Machine!

Phi-4 really shines when it comes to reasoning-heavy tasks. It can hang with much larger models, even beating its "teacher" model, GPT-4o, on some benchmarks. It also nailed a brand-new math competition, which is a solid sign that it's actually generalizing instead of just memorizing.

Of course, it's not perfect. It struggles a bit with:

• Strict instructions: It's not always great at following very specific formatting rules.

• Factual knowledge: It's a relatively small model, so it can sometimes make up facts, especially if they are obscure.

Pivotal Token Search (PTS): The Secret Sauce

This is where things get interesting. The Pivotal Token Search (PTS) is a way of finding those key tokens that really make or break a model's answer. By focusing on these pivotal tokens, the team was able to train the model more effectively. Here's how it works:

• They look at how each token affects the chance of getting a correct answer.

• They find the tokens that cause big swings in success probability.

• They then use those tokens to create DPO pairs, training the model to favor the "correct" token.

What Does This Mean for Us?

Phi-4 is a big deal because it shows that you don't need to make your models massive to get awesome results. By focusing on data quality and using smart techniques like Pivotal Token Search, you can achieve significant gains. It's a reminder that being creative and thoughtful with your data is just as important as having the latest hardware.

Some things we should keep exploring include:

• Optimizing the mix of data used for training while also considering how the model is fine-tuned later.

• Creating synthetic data that can help the model get better at instruction following.

• Finding better ways to prevent those pesky factual hallucinations.

In short, Phi-4 is a win for data-centric AI, showing that smart data strategies can lead to big improvements in LLM performance!

Source: https://arxiv.org/abs/2412.08905

While security has long been touted as a priority for organizations, the reality on the ground paints a different picture. According to a recent GitLab Developer Survey, a staggering 41% of engineers find it difficult to prioritize fixing security vulnerabilities [1]. Why? As one Site Reliability Engineer succinctly puts it👇️ 

The statistics back this sentiment—while 56% of organizations claim to implement security-centric methodology of DevSecOps, less than a quarter actually implement its crucial components [1]. This lack of comprehensive security practices isn't just concerning; it's a ticking time bomb for software vulnerabilities.

Status of Implementing Key DevSecOps Components in 2023 [1]

Enter Shift Left Security—the practice that aims to integrate security seamlessly into the software development process, right from the get-go.

In this Bug Driven Development guide, we'll dissect the key elements of DevSecOps and Shift Left Security. We'll offer actionable insights on how developers can implement these practices based on the size and demands of their engineering teams.

We’ve got a lot to cover, but before we do, just wanted to say a big thanks to everyone who helped with this guide. In addition to several industry guiding surveys and my own personal experience having led a ~50 engineer organization in the telehealth space, I was fortunate enough to bounce ideas around several engineers and engineering leaders to put together the recommendations in this guide. So let’s dive in 👇️ 

🔺The Security Testing Pyramid

Many of you may be familiar with the popular software testing metaphor, the Testing Pyramid, popularized by Mike Cohn from Mountain Goat Software and Ham Vocke’s post in Martin Fowler’s blog. The Security Testing Pyramid is an adaptation of the original concept, introduced by Andreas Falk at the 2022 Global AppSec Conference in the EU hosted by the OWASP Foundation. While Andreas’ Security Test Pyramid is a great start, I think it misses some areas like Secret & Credential Detection. In the chart below, the items in black text are from Andreas’ original Security Test Pyramid and the items in blue are ones I added.

Modified Security Test Pyramid [2]

The Security Test Pyramid has three layers:

1. Security Unit & Component Tests + Static Application Security Testing (SAST)

2. API / Service Security Tests

3. Dynamic Application Security Tests (DAST)

🏗️ Foundational Layer: Security Unit & Component Tests + Static Application Security Testing (SAST)

The foundational layer primarily comprises tests that can be integrated into a Continuous Integration (CI) pipeline.

These tests focus on:

• Identifying code vulnerabilities potentially exploitable by attackers

• Scanning for vulnerable dependencies (like if your code consumes an open source library that contains a vulnerability)

• Scanning for vulnerable dependencies (like if you store an API Key in your code instead of consuming it as an environment variable)

🥪 Middle Layer: API / Service Security Tests

This layer zeroes in on service-level tests, including:

• Authentication & Authorization Paths

• Injections (like a SQL Injection)

• File uploads vulnerabilities (like if a user can upload an executable file when your application is supposed to just store PDFs)

🪂 Top Layer: Dynamic Application Security Tests (DAST)

This layer operates in a deployed environment, focusing on vulnerabilities that can only be detected in a running application.

DAST tests aim to identify:

• Real-world attack vectors like Cross-Site Scripting (XSS)

• Vulnerabilities in third-party services and APIs

• Logical flaws that might escape static tests

⬅️ Practical Strategies for Shifting Security Left

Alright, let's get into the meat of the matter—how do you shift security left within your development process?

🏢 Foundation Layer

The cornerstone of the foundational layer in the Shift Left security model is running security checks continuously as part of the code check-in process. Ideally, this means that every time a developer pushes a commit, these checks are executed within the Continuous Integration (CI) pipeline.

While there are a variety of security tests that can be ran in your foundational layer of your security testing pyramid, I think the following three are the most practical in balancing the level security testing coverage while minimizing adding hurdles to your development process.

1. Code Security Scanning

2. Dependency Security Scanning

3. Secret / Credential Scanning

Code Security Scanning

When we talk about code security scanning in this context, we are specifically focusing on automated scans that are integrated into your Continuous Integration (CI) pipeline—not the traditional, manual scans that require sending off your source code to auditors for one-off analyses, such as Synopsis Black Duck audits. Those traditional methods are labor-intensive and not seamlessly incorporated into your workflow. I've been through a few of those, and trust me they're far from enjoyable 🤮.

In contrast, the code security scanning we advocate for is tightly integrated into your development process through a CI job that scans your code for vulnerabilities upon each commit. Not to point favorites in terms of tool selection (this is more for a reference so you know what is out there) you should be looking for something like a GitHub Code Scanning or a Snyk type of tool. This approach not only saves time but also fosters a culture of continuous security awareness among developers.

📦️ Dependency Security Scanning

I've seen two effective approaches to dependency scanning, and I recommend employing both. The first identifies new dependencies as you commit code and checks for known security issues within those dependencies. This is done as a job in your CI pipeline which reviews the newly added dependencies in your commit and flags them appropriately.

The second continuously monitors your existing dependencies and alerts you about vulnerabilities in the versions you're using. This helps you ensure your existing dependencies are always on a secure version and are doing frequent updates to dependencies. Both methods are equally useful and I recommend using them concurrently.

By the way, this is commonly known as a part of software composition analysis, which is typically abbreviated as SCA.

🕵️‍♂️ Secret / Credential Scanning

Sensitive authentication data, like API keys and passwords, should ideally be stored as secrets. Sure, there are some exceptions but even Google now recommends storing Firebase API keys as secrets (nice try Firebase devs 👀).

Secret scanning jobs in your CI pipeline scan your code for strings that look like these sensitive types of credentials. Typically there are three ways to resolve a scanned secret, the first is to remove the secret from your code and wipe the commit which contains the secret from your git history, the second is to flag it as a false positive when it finds something that looks like credentials, but is not, and the third is to confirm it's a credential that's safe to store in code by dismissing the scanned secret.

🛡️ Service Security Testing Layer

The Service Security Testing Layer is geared towards ensuring robust defenses at the service level. It is pivotal to focus on this layer, as APIs and services often act as the gateways to your application's core logic and data.

🔐 Authentication & Authorization Paths

When considering security at the service level, a critical area of focus is the integrity of your authentication and authorization paths. This involves not only basic username/password combinations but also more advanced schemes like OAuth and JWT (JSON Web Tokens).

Integrating OAuth or JWT testing into a CI pipeline might sound unconventional, but it's actually a strong practice. Utilize mock services that emulate your actual OAuth or JWT token generation and validation. These mock services, coupled with test scripts simulating various authentication scenarios, seamlessly fit into your CI/CD pipeline.

By incorporating these tests, you're achieving two key outcomes: ensuring the robustness of your authentication and authorization mechanisms and halting the merging of code that introduces potential vulnerabilities.

💉 Injections

Injections remain a notorious risk in API and service layers. They most commonly occur when inputs aren't properly sanitized or validated, allowing attackers to inject malicious code. At the service testing layer, you can implement static analysis tools that scan your application's code to detect vulnerabilities related to SQL injections. These tools can be seamlessly integrated into your CI pipeline, right alongside your existing unit and integration tests.

📁 File Upload Vulnerabilities

When it comes to file uploads, this layer ensures that only the intended file types (e.g., PDFs, JPEGs, etc) are uploaded and executed. Tests should verify that the application restricts file types to prevent the system from security threats like a user uploading an executable.

These types of tests should also be executed in your automation pipelines continuously.

🔭 Dynamic Application Security Testing (DAST)

Dynamic Application Security Testing (DAST) serves as your real-world security scout, focusing on vulnerabilities that only manifest in a running application. By integrating DAST into your CI/CD pipeline, these tests operate in a staging environment that mirrors your production setup, triggered automatically by changes to the codebase or infrastructure.

🔍 Real-world Attack Vectors

One of the core strengths of DAST is its ability to uncover real-world attack vectors, such as Cross-Site Scripting (XSS). Unlike SAST, DAST tests your application from an external perspective, simulating how an attacker might exploit vulnerabilities. You'll want to use automated scanning tools specifically designed for dynamic testing to identify these types of issues. These scans can be scheduled to run at regular intervals or triggered by specific events like major code merges.

🧠 Logical Flaws

Logical flaws, or vulnerabilities that stem from the application's business logic, are often hard to catch with static tests. DAST can help identify these by simulating various user roles and performing sequences of actions that may expose flaws in the application's logic.

🛠️ Integrating DAST into CI/CD

Incorporating DAST into your CI/CD pipeline typically involves running these tests in a staging environment after the application has been built but before it is deployed to production. While DAST tests can be more time-consuming than their static counterparts, the additional runtime context they provide is invaluable. To make the most of your CI/CD pipeline's efficiency, you might schedule DAST scans to run at other low-activity times or when a PR is close to being merged.

Thanks for diving into this Bug Driven Development post with us! We're mixing it up a bit by switching to two deep-dive articles a month instead of our usual weekly quick takes. If you are interested in finding out more about how to incorporate security into your developer workflow check out my session at last year’s GitHub Universe 👇️ 

Cheers,

Justin

Follow Justin on Twitter here

Additional Sources

1. 2023 GitLab Global DevSecOps Report Security Without Sacrifices

2. Shift Left Security with the Security Test Pyramid - Andreas Falk

In this issue, we are taking a deep dive into the state of software development as it stands in late 2023. Specifically, we will examine:

1. The evolving landscape of cloud platforms, rise of Hetzner and decline of Heroku

2. Current trends in frontend frameworks and languages

3. The state of automated testing and its importance in developer productivity & retaining developers

4. Emphasis on security and incorporating it into the developer workflow

5. The evolution of the day-to-day developer experience in 2023

6. The pathways to becoming a developer in 2023

I gathered insights from several industry guiding surveys such as Stack Overflow’s Annual Developer Survey, GitLab’s Annual DevSecOps Survey, and GitHub’s Innovation Graph, as well as from discussions with engineers and engineering managers in a variety of industries to confirm our findings – big thanks to everyone who helped. We've got a lot to cover, so let's dive in.

☁️ The Cloud

This year there have been some interesting developments with the cloud. AWS is still the leader amongst the big 3 cloud players with Google losing usage and Microsoft slightly gaining. Hetzner has reinvented itself, a move that has not gone unnoticed by developers. Heroku is declining sharply after the Salesforce acquisition and the removal of their free tier. What’s especially interesting is that an increasing number of organizations are making the move back to on-premises data centers from the cloud.

🥇🥈🥉The Big 3 Cloud Players

Year-over-Year Cloud Platform Usage Change: 2022 vs 2023[1]

According to StackOverflow’s 2023 Developer survey, out of professional developers utilizing the big 3 cloud providers (Amazon, Microsoft, Google) there has been little shift in usage. AWS has seen a slight increase by 2.5%, and Google has seen a slight decrease by 2.8%. Azure stayed relatively flat with a 0.2% increase [1].

Professional Developer Usage in 2023 of the Big 3 Cloud Providers[1]

AWS remains the leading cloud provider used by professional developers, but not without stiff competition. Azure's focus on enterprise solutions and both Azure & GCP's heavy investment in AI services make them strong contenders, closing in on AWS's lead. Despite AWS's expansive service offerings and strong infrastructure, the other giants are not far behind. In fact, the competition has sparked innovation across the board, leading to improved services and tools for us developers. Among my favorite innovations are significant advancements in developer-centric security tools, like Amazon’s CodeGuru Security which launched this June, Microsoft bolstering GitHub Advanced Security, and Google’s OSV Scanner that launched in late 2022 (more on developer security tools later).

As we look ahead to 2024, we anticipate that the competition among cloud providers will only intensify. This fierce rivalry will hopefully continue to fuel innovation, resulting in more frameworks, tools, and infrastructure to help make us more productive.

🧗‍♂️The Rise of Hetzner

One of the standout trends in our analysis is the rise of the cloud platform Hetzner. While Hetzner’s adoption by professional developers was not included in Stack Overflow’s 2022 developer report, this year it is reported to be used by 4.44% of professional developers [1,2]. Even more telling is that Hetzner is the most admired cloud provider, with 70.09% of its users expressing a desire to continue using it—compared to AWS's 62.24% [1]. Personally, I jumped on the Hetzner bandwagon this year and couldn't be happier. The UI is simple to navigate, yet comprehensive, and paired with an open source PAAS like CapRover, deployments seamlessly integrate with your development workflow.

📉 Heroku on The Decline

Another significant shift in the cloud landscape is the steep decline of Heroku. Although Salesforce's acquisition of Heroku may be deemed successful by some from a business perspective, the platform has seen a sharp drop in usage and developer satisfaction.

Professional Developer usage of Heroku [1,2,4]

The elimination of Heroku’s free tier last year might have been the final nail in the coffin, as only 21.97% of Heroku users plan on continuing to use the platform [1]. We anticipate this downward trend will continue unless substantial changes are made to regain user trust.

🏢 The Return to On-Prem and Traditional Architectures

We're also seeing a resurgence of companies turning away from cloud services in favor of more traditional on-premises or virtual machine setups. Several key events have catalyzed this shift. For instance, Amazon revealed that they slashed Amazon Prime Video's video monitoring cloud costs by 90% by transitioning from serverless functions to virtual machines. Additionally, David Heinemeier Hansson's (Creator of Ruby on Rails) company, 37 Signals, announced a complete migration from cloud services to on-premises data centers. They even released Kamal (formerly known as MRSK) to streamline the management of on-prem servers. This trend suggests a thoughtful reconsideration of the 'cloud-first' mantra that has dominated the industry.

🖥️ Frontend

🏳️ The Javascript Framework battle

The competition among JavaScript frameworks remains as fierce as ever, with no clear indication of any of them waiving the white flag soon, especially in their collective bid to dethrone React.

Professional Developer usage of FE Frameworks [1,2,4]

A couple of pivotal shifts to spotlight:

• Angular experienced a dip in popularity between 2021 & 2022 but seems to be regaining traction in 2023.

• Next.js is hot on the heels of Vue.js. Given its inherent performance advantages over conventional React and its foundation on React, we expect Next.js to continue gaining in popularity. It offers a familiar environment, making it a relatively lightweight transition for React developers compared to other FE Frameworks.

🧐 TypeScript's Moment: A Temporary Trend or Here to Stay?

As 2023 kicked off, notable figures in the developer world, like Kent C. Dodds, warmed up to TypeScript. Some accepted its benefits while others embraced it wholeheartedly.

Twitter tweet

Yet, the tide seemed to turn recently when David Heinemeier Hansson, the creator of Ruby on Rails, opted to remove TypeScript from his open-source project, Turbo 8.

Twitter tweet

While following the Twitter (X) battles between developers is certainly entertaining. I believe this is more noise rather than a signal of the decline of TypeScript.

However, the proposal to add type annotations directly into JavaScript is certainly not noise. If you can add type annotations natively to JavaScript, it would make TypeScript nearly obsolete. I plan to be closely following this proposal as it works its way through the approval process.

🧪 The State of Testing: Engineers Take the Helm

The trend of engineering teams owning the testing process, largely without the aid of a dedicated QA team, has not only taken hold but truly matured. In this section, we'll delve into how engineers have adapted to this paradigm shift in their roles.

🤖 Automated Testing Availability

Professional Developer Responses [1, 2]

Recent Stack Overflow surveys have asked developers about the availability of automated testing in their organizations. Results show a strong availability of testing automation, but only a marginal 3% increase in availability year-over-year. The data prompts intriguing areas of interest for future investigations:

• What does 'availability' entail across different organizations?

• In organizations with automated testing, where in the testing pyramid has the most automation?

• What are the adoption rates and usage patterns for automated testing tools in organizations with the tools available?

• For organizations without automated testing, is this a planned initiative or simply not a priority?

⚠️ Is Testing Still A Bottleneck in the Dev Pipeline?

GitLab's 2023 survey posed an intriguing question: 'Where does your team or organization encounter the most delays in the development process?' The survey found that 28% of respondents cited 'Testing,' and another 26% cited 'Test Data Management,' as the areas most likely to cause delays [3]. These statistics underscore the critical need for efficient testing strategies and perhaps warrant a deeper dive into best practices to mitigate these bottlenecks in future development cycles.

🧠 AI and Software Testing

In the past year we have witnessed the emergence of various AI-based developer tools. Many developers have started using generic tools such as ChatGPT, Bard, and GitHub Co-Pilot. In addition, there's been a surge of specialized AI tools for testing, including Microsoft IntelliTest, Codeo, and DiffBlue. These tools integrate seamlessly into your IDE and can generate tests for the specific code you highlight (imagine highlight-and-generate-tests instead of highlight-copy-paste).

While these AI tools offer a convenient way to quickly add unit tests to your code, they aren’t a comprehensive solution for improving overall test coverage with quality, maintainable tests. That's why I created my own AI software testing platform SoftwareTesting.ai, a GitHub app that analyzes your test coverage when tests are ran in GitHub Actions. It identifies gaps in your existing test suite and recommends test cases to fill them. If this interests you, SoftwareTesting.ai is currently free for both public and private GitHub repositories for the next month as we gather user feedback. Here is the link if you'd like to give it a try.

👨‍💻 Testing and Developer Retention

An intriguing finding from a recent GitLab survey illuminates the relationship between software testing and both developer retention as well as deployment rates. According to the survey, teams that have implemented test automation are 1.2 times less likely to face challenges in hiring and retaining developers [3]. Additionally, these teams are 1.5 times more likely to deploy to production multiple times per day [3]. In essence, test automation not only streamlines the deployment process but also enhances developer morale by enabling frequent, smaller releases.

🔒️ Security in the Development Cycle

While many organizations loudly proclaim their commitment to security, it often takes a backseat in actual practice with 41% of developers saying it is difficult to prioritize remediating security vulnerabilities [3]. The rise in notable security incidents serves as a stark reminder. From DDoS attacks on tech giants like Amazon, Google, and Cloudflare to unexpected targets like cosmetics manufacturer Estée Lauder, no company is immune. Even billboards in Israel have been hacked, illustrating that the threat landscape is far-reaching and indiscriminate.

Not only is the performance of security practices at these companies far from the standard users expect, developers are generally frustrated with the security processes, procedures, and tools they are using with 43% of developers saying their biggest frustration with security testing is that it happens too late in the development lifecycle and causes delays [3].

📈 How to Improve an Organization's Security Posture While Increasing Developer Satisfaction?

This was a key question I grappled with during my tenure as VP of Software Development at a notable telehealth startup. Conveniently, GitHub launched their Advanced Security package for GitHub Enterprise customers around the same time we began tackling this issue. The outcome was a resounding success, we were able to quickly fix many vulnerabilities and tightly weave security into our development process.

If you are interested in learning more about this topic, you can check out my session at GitHub Universe focusing on empowering developers to better own security.

You can also review how we utilized GitHub Advanced Security to prepare for our third party security audit. I'll also be releasing a more in-depth guide diving into the specifics of launching and maintaining a successful developer-centric security initiative soon, so keep an eye out.

🏖️ Life as a Developer in 2023

With the impact of Covid ushering many developers into remote work, the landscape has evolved to embrace more flexible models. Currently, 42.2% of developers are operating in a hybrid work environment [1]. It's clear that some form of remote work is here to stay, as evidenced by the mere 16.4% of developers working entirely in-person [1].

Developer Working Environment [1]

With the rise of remote and hybrid work models, there's been a notable shift toward more asynchronous forms of communication and team collaboration. Microsoft Teams and Slack lead the way in usage among professional developers [1]. This is unsurprising given their features, which not only combine chat and video conferencing but also offer extensive integrations with developer tools. It raises an intriguing question of how much these developer-centric integrations impact an organization's decision to adopt either Microsoft Teams or Slack specifically for their engineering teams.

Professional Developers Thoughts on Virtual Communication Tools [1]

Another essential component for enabling asynchronous work is project management software. Jira and Trello continue to dominate this space [1]. Atlassian, the company behind Jira, acquired Trello in 2017 and recently added Loom to their portfolio. Given Atlassian's dominant position in the industry, it will be interesting to see how they continue to innovate to enhance working environments for developers.

Professional Developers Thoughts on Project Management Tools [1]

🧩 The Fragmentation of Knowledge in Remote Teams

Remote work has forced teams adapt to having less face-to-face time than before, and as a result, knowledge silos have formed. Unlike in the office, you can't simply walk up to someone's desk for a quick question while working remotely. This issue appears to be worsening. In 2022, 20.88% of developers spent less than 15 minutes per day searching for answers or solutions [2]. Now, in 2023 that number had shrunk to just 9.04%, with more developers now spending between 30 and 120 minutes per day searching for answers compared to last year [1].

Developers Time Spent Searching for Answers [1,2]

🗺️ Pathway to Becoming a Developer in 2023

Even with the current economic conditions we are experiencing in late 2023 and the wave of big tech layoffs we have seen earlier this year, the demand for developers is still strong. It is interesting to see how aspiring developers are learning to code and get into the field of software development.

Professional Developers with Degrees vs Developers Learning to Code through School [1,2,4,5]

Nearly 80% of professional software developers hold a degree, while just over half of aspiring developers are pursing one as their way to get into the field [1]. This divergence could be attributed to the increasing popularity of online courses and 'coding boot camps.' It will be interesting to see the trend over time, and better understand how aspiring developers—who opt for learning routes outside of traditional education—fare in becoming professional developers.

Thanks for diving into this Bug Driven Development post with us! We're mixing it up a bit by switching to two deep-dive articles a month instead of our usual weekly quick takes. I’d love to hear what you think about the State of Software Development in 2023 and how you feel about our new format.

Cheers,

Justin

Follow Justin on Twitter here

Additional Sources

1. 2023 Stack Overflow Developer Survey

2. 2022 Stack Overflow Developer Survey

3. 2023 GitLab State of DevSecOps

4. 2021 Stack Overflow Developer Survey

5. 2020 Stack Overflow Developer Survey

Welcome to the new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Cringe AI takes

• What Mark Zuckerberg thinks about Apple’s Vision Pro

• Reviving an abandoned AI project to achieve $300,000 in gross bookings within 90 days

Let's start off this week by talking about what AI will NOT do for Software Development

A lot of people are talking about what AI will do for software development. The discourse is rife with predictions that range from insightful to downright ludicrous. So we've got a doozy for you today - a round-up of some of the most fantastical, cringe-inducing predictions about AI in software development.

Ready? Let's dive in👇

Twitter tweet

To some bean counter MBA this prediction may make a lot of sense, but to any software developer they know the following:

1. It is pretty established that lines of code written is not a viable metric for measuring developer effectiveness / efficiency

2. There is a lot more to being a software developer than just writing code

When you forget that with most tools you need to upgrade to paid tiers for full functionality👇

Twitter tweet

While it is now easier than ever to build and sell software, you can’t do it for free 🤡

Those were the two cringe takes we found to be the funniest, what’s yours? Let us know by responding to this email or via twitter.

🔗Links in Tech

Some additional reads we liked this week

• What Mark Zuckerberg thinks about Apple’s Vision Pro

• Reddit Apollo App Backend Code Made Public

• TypeScript for Tiny IoT Devices

• Buying an abandoned AI project and growing it to $300,000 in gross bookings in 90 days

• How the Raycast API and extensions work

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to the new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• What makes a senior engineer?

• Boost your revenue by 10-40% with upselling

• A passive income site making $4,000/mo in profit

Let's start off this week by talking about what makes a senior engineer

This topic spawned from a twitter thread between Justin and Raul Junco discussing what makes a senior engineer. It is a very interesting topic and we wanted to expand on what we think makes a senior engineer for this week’s newsletter.

Twitter tweet

In our view the key trait of a senior engineer is an engineer who is “primarily autonomous“. We love this description because it sums up a lot of key factors so let’s go into more detail about the importance of autonomy 👇

👨‍💻 The Importance of Autonomy

As we delve into the definition of a senior engineer, one attribute stands out: autonomy. But why is autonomy such an essential aspect of a senior engineer's role?

In the world of software development, autonomy refers to the capability to handle tasks independently, to troubleshoot problems without requiring constant guidance, and to make informed decisions about technical solutions. This autonomy doesn't translate to isolation, but rather suggests the capability to lead, collaborate, and communicate effectively with a broader team, contributing significantly to the overall project success.

Autonomy is important because it allows for faster and more efficient task completion. Imagine having a team where every member constantly needs detailed instructions, or where each decision has to go through a tedious approval process. This would inevitably slow down the development pace and may cause frustration within the team.

In contrast, an autonomous engineer is like a self-driving car, capable of safely navigating the road without a driver constantly managing the controls.

They can take on a task or a project, understand what needs to be done, and navigate through the complexities to deliver results. This independence is not born out of thin air but stems from years of experience, a deep understanding of the technical domain, and a knack for problem-solving.

Autonomous engineers are pivotal in situations where there's a need to respond swiftly to changes or issues. They can adjust to shifting requirements, adapt to new technologies, and deal with unexpected problems, all while keeping the project on track. This ability is particularly valuable in today's fast-paced tech environment where adaptability is key.

But don't mistake autonomy for a license to avoid collaboration or ignore guidelines. Truly autonomous engineers know when to seek help, how to leverage the expertise of their colleagues, and when it's necessary to align with team or organizational standards. They embody the balance between independence and collaboration, making them invaluable members of any development team.

So, autonomy is not just a desirable trait in a senior engineer - it's a fundamental prerequisite. It’s this ability that empowers them to navigate complex tasks and deliver high-quality results. It is this autonomy that truly sets senior engineers apart.

Building Your Autonomy: Strategies and Tips

So if autonomy is so important to becoming a senior engineer how does a junior engineer become more autonomous or how does a senior engineer become more autonomous? We put together a nifty guide to help with this.

1. Master Your Craft: Begin with a solid understanding of the fundamentals of your technical domain. Whether it's your programming language of choice, understand the advanced concepts, principles, and best practices. Practice regularly, work on different projects, and try to learn something new each day.

2. Seek Out Challenges: Put yourself in situations where you need to find solutions to complex problems. Working on challenging tasks is an excellent way to grow as an engineer. It pushes you to think critically, solve problems, and make decisions - all crucial aspects of being autonomous.

3. Learn From Others: Seek mentorship from more experienced engineers. Their knowledge, experience, and insights can be invaluable. Attend code reviews, participate in pair programming sessions, and don’t shy away from asking questions.

4. Learn to Make Decisions: Part of being autonomous is making informed decisions. Start by making minor decisions about code design, architecture, or technologies to use, and gradually take on more responsibility. Learn from the outcomes, whether they're successful or not.

5. Develop Self-Management Skills: This includes time management, task prioritization, and self-discipline. These skills are critical for managing your workload and meeting deadlines, particularly when you're working autonomously.

6. Stay Curious: The tech industry is always evolving. Keeping up with the latest trends, tools, and technologies is essential. This constant learning not only helps you stay relevant but also contributes significantly to your autonomy.

Building autonomy takes time and patience, but with consistent effort, you can certainly cultivate this crucial skill. Remember, every step you take towards autonomy is a step closer to becoming a senior engineer. Keep learning, keep growing!

🔗Links in Tech

Some additional reads we liked this week

• Boost your revenue by 10-40% with upselling

• Train ChatGPT on your own data

• [TUTORIAL] - Finetune GPT On Your Own Data

• Verb Now is on sale with $4,000 a month in profit

• At Veecon 2023 last week there was talk about the concept of underpriced attention

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to the new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Approval Testing, what is it good for and how to use it

• NeXT Computers

• Giving GPT "Infinite" Knowledge

✅ Kicking Off with Approval Testing

Inspired by Dave Farley’s latest video about approval testing, we decided to explore this concept further and share our perspective on its usefulness.

🧪 So What Is Approval Testing?

Approval testing is a technique employed during code refactoring. It helps developers ensure that code changes, whether for adding new features or modifying the application's structure, do not have unintended consequences. Approval tests record system interactions, store them in a file, and compare these results with previous reference outcomes to identify discrepancies. This method effectively aids in making safe code changes and reducing potential errors.

🗨️ Our Thoughts - The Role of Approval Testing in a Development Cycle

Recently, we've observed a trend where companies undertake extensive re-architecture, altering their deployment models. Developers like David Heinemeier Hansson, for instance, are moving their architectures from the cloud back to on-premises environments.

Twitter tweet

Moreover, companies like Amazon are shifting away from serverless architecture and returning to monolithic structures for improved performance and cost reduction (Amazon managed to decrease costs by 90% through this re-architecture!)

Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.

www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

These re-architectures aim to maintain existing features and functionalities while significantly altering the code construction or deployment model. This is where approval testing proves valuable. If the goal is to substantially restructure the code while preserving functionality, the team can implement approval tests to ensure that all refactored functions align with the current system. Consequently, as the revised code enters production, it won't cause existing systems or dependencies to break due to the changes.

As organizations embark on extensive refactoring projects, approval testing emerges as an indispensable tool to maintain stability and consistency. By establishing a safety net of tests that monitor functionality, development teams can confidently make significant code modifications without fear of disrupting existing systems or dependencies. In a rapidly evolving tech landscape, it's crucial for businesses to adapt and optimize their architectures for performance, cost, and scalability. With approval testing in their arsenal, developers can boldly undertake these large-scale transformations, ensuring a seamless transition while retaining the core features and functionalities that make their applications successful.

For those seeking to delve deeper into the phenomenon of organizations stepping away from cloud platforms and reevaluating their deployment models, check out our analysis of this shift in the industry 👇️

Escaping the Cloud Trap: How Some Companies are Winning by Going Old School

Uncover the secrets behind the cloud exodus trend and see if it's the right move for your infrastructure.

www.bugdrivendevelopment.com/p/escaping-the-cloud-trap-how-some-companies-are-winning-by-going-old-school

🔗Links in Tech

Some additional reads we liked this week

• NeXT Computers

• SineRider, a math puzzle game

• How to get more user signups

• Giving GPT "Infinite" Knowledge

• ChatGPT Is Powered by Human Contractors Getting Paid $15 Per Hour

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to our new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Creative ways to extend the lifespan of your documentation with Real Documentation

• Use AI to remove backgrounds

• Startup founder with zero customers

📄 Let's start off this week by talking about documentation

Developers create documentation to share ideas with team members, serve as a reference for their future selves, meet compliance requirements, and for countless other reasons. Yet, it often feels like documentation is the appendix of software development: it's there, but nobody really knows what it's for. Sure, management emphasizes its importance, and you read about "best practices" online, but do your team members truly read and comprehend the documentation you create? Or do they just skim through it to get the gist?

Enter what we are coining "Real Documentation" – a dynamic alternative to traditional text-based software documentation. By leveraging the many tools available today, you can create mock prototypes in the same amount of time it takes to write a conventional document. In the following sections, we'll explore how Real Documentation can revolutionize the way you communicate your software designs and ideas, making your documentation more engaging and effective.

👨‍💻 Real Documentation for UI/UX Design

In the past, UI/UX designs were created by specialized designers using tools like Adobe Suite. They would gather ideas, craft beautiful screens, and share them with the team and stakeholders for feedback. While UI/UX design remains a form of art, modern tools like Figma have made it easier for anyone to turn their ideas into interactive mockups and click-through demos even before writing a single line of code.

These interactive demos are far more effective for gathering feedback from users, team members, and stakeholders compared to static Adobe designs in PowerPoint or PDFs. They also surpass traditional text-based documents describing features, their appearance, and positioning. Real Documentation is all about showing, not telling, when it comes to presenting your UI/UX designs. By embracing click-through demos, you can significantly enhance communication and collaboration within your team.

Twitter tweet

🕸️ Real Documentation for APIs and Microservices

API specifications serve more purposes than merely outlining request and response formats. They can also be used to generate mock servers, empowering fellow developers to experiment with APIs before their actual implementation. Instead of solely relying on an OpenAPI Specification or a Postman Collection, consider creating a mock server in Postman that includes all API endpoints with sample data resembling real API responses.

This approach is beneficial for both adding or revising an API in an existing service and creating a brand-new microservice. The mock server enables developers to test APIs by consuming them as they would with the completed version, which in turn helps them provide more actionable feedback on improving the API or service design. By adopting Real Documentation in this context, you can enhance collaboration and streamline the API development process.

🐾 Next Steps for Real Documentation

Real Documentation offers a fresh perspective on how we approach software development documentation. By shifting our focus from traditional text-based documents to interactive, hands-on prototypes and mock servers, we can bridge the communication gap between developers, stakeholders, and users. This approach not only streamlines the development process but also facilitates better feedback and understanding among team members.

Embracing tools like Figma for UI/UX design and Postman for API mock servers allows for a more dynamic and immersive documentation experience. As the software development landscape continues to evolve, it's crucial to adopt practices that keep pace with modern demands. Real Documentation is an innovative approach that enables us to create more effective and engaging documentation, ultimately leading to better products and improved collaboration.

It's time to leave those dusty, unread documents behind and embrace the future of documentation. With Real Documentation, we can transform the way we communicate our ideas and ensure that our work doesn't just sit on a virtual shelf but plays an active role in the development process.

As we continue to explore the potential of Real Documentation, stay tuned for more guides and insights in future Bug Driven Development blog posts. We're excited to share the journey with you, as we collectively redefine the role of documentation in software development.

🔗Links in Tech

Some additional reads we liked this week

• Amazon is developing an improved LLM to power Alexa

• Remove Background From Image for Free Using Artificial Intelligence

• Learning COBOL: A Journey for the Modern Programmer

• Svix (YC W21) Is Hiring Rust Back End Engineers

• [RailsConf 2023 Opening Keynote] The Magic of Rails

😂 Meme of the Week

Twitter tweet

🤖 SoftwareTesting.ai Update

SoftwareTesting.ai is launching soon! See a more detailed update on Justin’s personal website here: https://www.justintrugman.com/blogs/software-testing-ai-pivot/

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to the new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Reworking repeated code into arrays

• Inconsistent error handling makes debugging more difficult than needed

• The Kubernetes Desktop Client you've been waiting for

• Mr. Google Incognito

Let's start off this week by talking about some Dev Pet Peeves

As developers, we've all come across code that makes us cringe. The two pet peeves we'll discuss today – repetitive code and inconsistent error handling – can wreak havoc on a codebase. But don't worry! We'll provide you with solutions to overcome these common challenges and make your code cleaner, more efficient, and easier to maintain.

Repetitive Code – Embrace Arrays and Iterations

This past few weeks, we have seen way to much repetitive code and it drives us nuts!

I was looking for a new chair for my home office set up and wanted to take some measurements to see how well it would fit. The issue was my tape measure is in imperial system and the measurements on the website for the chair was in metric system. For doing the conversions I was looking for a simple calculator like tool that I could use to quickly see if the chair will fit (seems straight forward enough).

I came across an open-source project that seemed to offer what I needed, so I started examining the code to see how well it would work for me. My intrinsic developer curiosity caused me dive into the codebase, and I stumbled upon a section that made me cringe: a long series of repetitive if statements, each one handling a different unit conversion.

The code looked something like this:

if (unitFrom === 'meters' && unitTo === 'feet') {
  convertedValue = inputValue * 3.28084;
} else if (unitFrom === 'meters' && unitTo === 'inches') {
  convertedValue = inputValue * 39.3701;
} else if (unitFrom === 'feet' && unitTo === 'meters') {
  convertedValue = inputValue * 0.3048;
} // and so on, for every possible conversion...

This approach is not only cumbersome but also makes the code harder to maintain and prone to errors. A much better approach would be to use a nested object to store the conversion factors for each unit, something like this:

const conversionFactors = {
  meters: {
    feet: 3.28084,
    inches: 39.3701,
  },
  feet: {
    meters: 0.3048,
  },
  // ... and so on, for every possible conversion
};

This gives the conversion factors in a more manageable structure, which you could quickly perform the desired conversion using a single line of code:

const convertedValue = inputValue * conversionFactors[unitFrom][unitTo];

This code is cleaner, more efficient, and much easier to maintain. This simple example just goes to show the importance of using appropriate data structures and prevalent developers not structuring their programs correctly is.

Inconsistent Error Handling – Create a Single Error Function

Inconsistent error handling is another pet peeve that can lead to messy, hard-to-maintain code. Often, developers handle errors in different ways throughout the codebase. For example with Javascript, some might use console.log(), while others use console.error(), and some may not handle errors at all.

To create a more consistent and efficient error handling system, implement a single error function that handles all errors in your codebase. This function should log the error, notify the appropriate team members, and, if necessary, handle the error gracefully.

Here's a simple example of a custom error handling function:

function handleError(error) {
  console.error(error);
  // Send error notification to the team via email or other channels
  // Send log to a log server
  // Perform necessary actions to recover from the error
}

Now, whenever an error occurs, you can use this function to handle it consistently:

try {
  // Your code here
} catch (error) {
  handleError(error);
}

Its a much cleaner and more extendable approach to error handling. One enhancement you can make to this is passing in additional inputs to the handleError function that can trigger different actions. For example, you can pass in a parameter which would signify that support should be emailed about the issue, or that for this type of issue the log should be sent to a log server, etc.

🔗Links in Tech

Some additional reads we liked this week

• The Open Source Ruby on Rails SaaS Framework

• Twitter fueled run on Silicon Valley Bank, new paper finds

• YouTube, the jewel of the internet

• 100 Days of SwiftUI! This is a free collection of videos and tutorials

• The Kubernetes Desktop Client you've been waiting for

😂 Meme of the Week

Twitter tweet

🤖 SoftwareTesting.ai Update

The SoftwareTesting.ai pivot is going well so far!

From a development standpoint we have starting aligning the architecture to be supportive of receiving webhooks from GitHub and we expect the MVP launch to be next weekend!

For the initial launch we are going to:

1. Analyze your Code Coverage

2. Generate Unit Tests to fill the gaps in coverage

3. Add these as suggestions as GitHub Comments in your PR

This will give you quick feedback on how to improve your code coverage and allow you to implement the suggested tests in the comments through the already existing “Apply Suggestions“ workflow built into GitHub.

If you are interested in finding out more about the SoftwareTesting.ai pivot check out our new landing page that has more details 😀 

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to the new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Intro into Reactive Programming

• Additional resources to learn more about Reactive Programming

• AI is going to nuke the bottom third of performers in jobs done on computers in the next 24 months

• Dev reaches 100$ MRR with AI app

• Update about Justin’s Software Testing Project

Let's start off this week by talking about Reactive Programming

In today's fast-paced world, users demand applications that are highly responsive and can effortlessly handle large amounts of data in real-time. Reactive programming is a programming paradigm that aims to fulfill these needs by helping developers build scalable and responsive applications. In this post, we will explore the principles of reactive programming and learn how to apply them to create fast, highly interactive applications.

What is Reactive Programming?

Reactive programming is a programming paradigm that revolves around the propagation of changes in data. It emphasizes the use of asynchronous data streams, allowing you to process and react to events and data changes as they occur. Reactive programming promotes a more declarative approach to handling data, making it easier to reason about and maintain complex application logic.

Key Principles of Reactive Programming

1. Data Streams: Reactive programming is centered around data streams, which represent a sequence of events or values over time. These data streams can be created from various sources like user input, network events, or even internal application state changes.

2. Observables and Observers: In reactive programming, data streams are represented as observables, and consumers of these data streams are known as observers. Observers can subscribe to observables to receive updates whenever new data is emitted.

3. Functional and Declarative: Reactive programming encourages functional and declarative programming styles. By combining and transforming observables, you can create complex application logic without explicitly managing state or control flow.

4. Asynchronous and Non-Blocking: Reactive programming focuses on asynchronous and non-blocking operations, making it easier to handle long-running tasks, such as network requests or database queries, without freezing the application.

Getting Started with Reactive Programming

To start implementing reactive programming in your applications, you can use popular libraries and frameworks like RxJS for JavaScript, ReactiveX for Java, and ReactiveSwift for Swift. These libraries provide a set of tools and abstractions to work with reactive data streams, making it easier to build responsive applications.

Here's a simple example using RxJS:

const { fromEvent } = rxjs;
const { map, debounceTime } = rxjs.operators;

const input = document.querySelector("#search-input");
const searchResults = document.querySelector("#search-results");

const input$ = fromEvent(input, "input").pipe(
  debounceTime(300),
  map(event => event.target.value)
);

input$.subscribe(searchTerm => {
  searchResults.innerHTML = `Searching for: ${searchTerm}`;
});

In this example, we create an observable from the "input" event of an input element, then use the debounceTime and map operators to handle the user input. The observer subscribes to the transformed observable and updates the search results element whenever the input changes.

Benefits of Reactive Programming

1. Simplified Complex Logic: Reactive programming enables you to compose complex application logic more easily by chaining and combining data streams.

2. Improved Performance: Asynchronous and non-blocking operations lead to better performance and resource utilization in your applications.

3. Easier Maintenance: The declarative nature of reactive programming makes your code more readable and easier to maintain.

4. Scalability: Reactive programming provides a solid foundation for building scalable applications that can efficiently handle large amounts of data and high levels of user interaction.

Conclusion

Reactive programming is a powerful paradigm for building scalable, responsive applications. By embracing the principles of reactive programming and utilizing libraries like RxJS, ReactiveX, or ReactiveSwift, you can create applications that are more performant, easier to maintain

📖 Learn more here

Here are some guides we like that can be helpful to dive deeper into Reactive Programming:

• The introduction to Reactive Programming you've been missing by Andre Staltz (https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)

  • Learn all about Reactive Programming and how it works

• 5 Things to Know About Reactive Programming by Clement Escoffier (https://developers.redhat.com/blog/2017/06/30/5-things-to-know-about-reactive-programming)

  • Discover 5 key areas of Reactive Programming

• Notes on Reactive Programming Part I: The Reactive Landscape by Dave Syer (https://spring.io/blog/2016/06/07/notes-on-reactive-programming-part-i-the-reactive-landscape)

  • Solid overview of the area of Reactive Programming

🔗Links in Tech

Some additional reads we liked this week

• Auto-GPT: An Autonomous GPT-4 Experiment

• AI is going to nuke the bottom third of performers in jobs done on computers — even creative ones — in the next 24 months

• Just reached 100$ MRR with my app

• Tyler Mancuso exploited adtech systems to reroute a $9 million payment

• Why Does a Plastic-Wrapped Turkey Sandwich Cost $15 at the Airport?

😂 Meme of the Week

Twitter tweet

Update about SoftwareTesting.ai

We wanted to give you an update on Justin’s latest pivot for SoftwareTesting.ai. SoftwareTesting.ai’s mission has always been to help software engineers improve their code quality and save time through AI-powered testing. To that end, we are excited to announce that we are pivoting towards a new direction that we believe will revolutionize the way teams approach test coverage.

We are currently using our AI test generation technology to develop a Github app that will analyze code coverage, identify gaps in testing coverage, and provide actionable insights for developers to create unit tests and close those gaps. This app will streamline testing workflows and help teams deliver quality code faster. Our goal is to provide developers with the tools and resources they need to improve code coverage and automate the testing process. We believe this new direction will help us better serve our customers and push the boundaries of what's possible in the testing space. We look forward to sharing more updates with you soon.

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

In this special Easter edition of the Bug Driven Development newsletter, we'll delve into the trend of leaving the cloud. Weighing the pros and cons, and help you decide whether it's time to pack your bags and leave the cloud or stick around for a little longer.

If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Leaving the cloud or staying in the sky

• Resources to learn more about making the move back to bare-metal

• Indie Hackers is indie again!

• “You are online 24/7. No exceptions, no excuses.”

⛅️ Let's start off this week by talking about the trend of leaving the cloud

The cloud has been the go-to solution for most companies in recent years, with its scalability, easy deployment, and cost-saving potential. However, some businesses are now choosing to "leave the cloud" and return to more traditional, on-premises infrastructures. This trend has been fueled by the increasing cost of cloud services and the desire for more control over hardware and software. Let’s dive in to the case for leaving the cloud, the case for staying, and some recommendations we have for teams considering making the move.

⛈️ The Case for Leaving the Cloud

There are several reasons why some companies are opting to leave the cloud, and one of the most compelling is cost. As David Heinemeier Hansson, co-founder of 37signals, recently shared in his blog post, their cloud bills had grown to an eye-watering $38,000 per week. They chose to develop MRSK, a new deployment tool that combines the simplicity of Capistrano with modern containerization techniques, to facilitate their move away from the cloud. By doing so, they expect to save a significant amount on their infrastructure costs.

Another reason to consider leaving the cloud is the increased control over hardware and software. Companies can tailor their infrastructure to their specific needs, potentially leading to better performance, security, and flexibility. Plus, as Hansson points out, modern server hardware has made significant strides in recent years, making on-premises solutions more attractive than ever.

🌤️ The Case for Staying in the Cloud

However, leaving the cloud isn't for everyone. There are still plenty of reasons to stick with cloud solutions. One of the most significant benefits is scalability. Cloud services allow businesses to scale up or down easily, depending on their needs, without investing in expensive hardware. This can be particularly valuable for smaller companies or those with fluctuating resource requirements.

Additionally, cloud providers offer a wealth of tools and services that can streamline deployment, monitoring, and management, making life easier for developers and sysadmins alike. In some cases, optimizing cloud usage and choosing the right services can lead to cost savings without needing to move away from the cloud entirely.

🚦Our Recommendations

So, should you leave the cloud or stay put? Here are some recommendations to help you make the right decision for your infrastructure:

• Analyze your current cloud costs 

  • Take a close look at your cloud bills and identify areas where you might be overspending. In some cases, optimizing your cloud usage or finding alternative cloud providers could lead to significant savings without the need to leave the cloud.

• Consider your scalability needs:

  • If your business requires rapid scaling, the cloud might still be the best option for you. However, if your resource requirements are stable or predictable, an on-premises solution could be more cost-effective.

• Assess your team’s expertise

  • Moving away from the cloud requires a certain level of expertise in managing hardware and software. Ensure you have the right people on your team to handle the transition and ongoing management of your infrastructure.

• Test the waters

  • Before committing to leaving the cloud entirely, you could experiment with a hybrid approach. Some of your applications could be moved to on-premises infrastructure, while others remain in the cloud. This allows you to evaluate the benefits and challenges of both approaches and make a more informed decision.

💡Conclusions

The decision to leave the cloud isn't one to be taken lightly, but for some businesses, it can lead to significant cost savings and greater control over their infrastructure. By carefully evaluating your needs, costs, and expertise, you can determine whether it's time to wave goodbye to the cloud or continue to ride the waves in the sky.

📖 Learn more here

Here are some guides we like that can be helpful to dive deeper into the trend of leaving cloud computing:

• We stand to save $7m over five years from our cloud exit by David Heinemeier Hansson (https://world.hey.com/dhh/we-stand-to-save-7m-over-five-years-from-our-cloud-exit-53996caa)

  • Learn the factors that contributed to 37 Signals’ move away from the cloud

• Why are companies leaving the cloud? Exploring the main reasons for cloud repatriation by Mohamed Wadie Nsiri (https://ubuntu.com/blog/cloud-repatriation-reasons)

  • Discover the key reasons companies are using to justify going back to on prem infrastructure

• Are clouds having their on-prem moment? by Ben Popper (https://stackoverflow.blog/2023/02/20/are-companies-shifting-away-from-public-clouds/)

  • An analysis on the trend and seeing if staying in the cloud is best for your infrastructure

🔗Links in Tech

Some additional reads we liked this week

• Megathread of who's who in AI

• BabyAGI and Auto-GPT

• This solo non-technical founder started a $14K/month SaaS

• Indie Hackers is indie again!

• Matt Diggity Shows How to Use ChatGPT to Build SEO Topical Authority

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to this week's edition of our newsletter, where we are going to discuss the impact of AI tools like ChatGPT, GitHub Copilot, and others on the future of StackOverflow. As the software development landscape continues to evolve, we can't help but wonder: is StackOverflow still relevant? Let's dive into this analysis and explore the pros and cons of these AI-driven technologies. If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Analysis on the usage of StackOverflow and if it is still relevant in the AI era

• Why Not document.write()?

• Survey - do you still use StackOverflow?

The Unwavering Popularity of StackOverflow

For over a decade, StackOverflow has been the go-to destination for software developers seeking solutions to their coding challenges. The platform's extensive database of questions and answers, combined with a strong community of developers, has made it an indispensable resource for programmers.

Enter the AI-driven Tools

In recent years, AI-driven tools such as ChatGPT, GitHub Copilot, and others have started to emerge, offering developers a new way to tackle their coding challenges. These tools can understand context, generate code snippets, and even offer insights into best practices, making them incredibly powerful allies in the software development process.

Weighing the Pros and Cons

It's essential to acknowledge the advantages and limitations of both StackOverflow and AI-driven tools. StackOverflow boasts a wealth of collective knowledge, with real-life examples and a supportive community. However, it can be time-consuming to search for the right answers, and the quality of responses can vary.

On the other hand, AI-driven tools offer immediate assistance, tailored to your specific coding needs. They can quickly generate code snippets and recommendations, saving you time and effort. However, these tools may still lack the depth of understanding and context that human experts can provide.

The Decline of StackOverflow?

While it's unlikely that StackOverflow will become obsolete, we can't ignore the potential impact of AI tools on its utility. As AI-driven technologies continue to advance, we may see a decline in StackOverflow's relevance, particularly in areas where AI tools excel, such as code generation, autocomplete, and syntax error identification.

That being said, StackOverflow will likely remain a valuable resource for more complex and nuanced discussions, as well as for developers seeking human-to-human interactions and support.

Concluding Thoughts

As AI-driven tools like ChatGPT and GitHub Copilot continue to gain traction, we can expect them to reshape the way developers approach problem-solving. StackOverflow may see a decline in utility around specific areas, but its wealth of collective knowledge and supportive community will likely keep it relevant to some degree in the foreseeable future.

🔗Links in Tech

Some additional reads we liked this week

• Italian privacy regulator bans ChatGPT

• Payments giant Stripe raises $6.5 billion at a $50 billion valuation

• Alexa, what is my wifi password?

• Draw wireframes, get designs & code

• Why Not document.write()?

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Welcome to 98 new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Uncluttering the Mess: Managing Technical Debt in an Organized way

• Additional resources to learn more about managing tech debt

• Are we in a recession?

• The Billion-Dollar SEO Industry

Let's start off this week by talking about Managing Technical Debt

We know technical debt is a fact of life in software development, but that doesn't mean it has to cripple your codebase. In this week's newsletter, we're discussing strategies for managing technical debt like a boss.

First, let's define what technical debt is. Technical debt is the accumulated cost of sub-optimal code design decisions over time. It's what happens when you take shortcuts to meet a deadline or cut corners to deliver features faster.

But technical debt isn't all bad. The key is to know how to manage it effectively. Here are some strategies for keeping your technical debt in check:

1. Acknowledge the debt: The first step to managing technical debt is acknowledging that it exists. Once you've accepted that it's there, you can start developing a plan to deal with it.

2. Prioritize the debt: Not all technical debt is created equal. Some debt can wait, while others requires immediate attention. Prioritizing the tech debt based on its impact on your codebase and users is crucial.

3. Create a plan: Develop a clear plan for addressing your technical debt. This plan should include short-term and long-term goals, timelines, and the resources required to execute the plan.

4. Track progress: Track your progress in paying down your technical debt. This will help you stay on track and measure the effectiveness of your plan. One easy way to do this is to create a card for each piece of tech debt on your plan in your favorite project management tool (like Jira, Trello, and GitHub Issues) that map to a higher level card or epic. This way you can track how much tech debt is resolved and how much is left to go.

5. Communicate with stakeholders: Keep stakeholders informed about the technical debt and the plan to address it. This will help manage expectations and avoid surprises.

6. Avoid taking on new debt: While this is much easier said then done. Try to avoid taking on new technical debt whenever possible. This means taking the time to design code that's scalable, maintainable, and extendable.

7. Use automation to your advantage: Use automation tools to help you manage technical debt. Automated testing, code analysis, and continuous integration tools can help you identify and address technical debt more efficiently.

In conclusion, technical debt is a reality in software development, but it doesn't have to be a huge burden. By following these strategies, you can manage technical debt effectively, keeping your codebase healthy and your users happy.

📖 Learn more here

Here are some guides we like that can be helpful to dive deeper into managing technical debt:

• Technical Debt Quadrant by Martin Fowler (https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)

  • Reading the Technical Debt Quadrant will help you differentiate between "good" and "bad" technical debt, so you can finally stop feeling guilty about all those code shortcuts you've been taking.

• A Mess is not Technical Debt by Bob Martin (https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt)

  • Discover how to differentiate between a mess and technical debt, so you can finally stop blaming your code for your messy desk.

• Managing Technical Debt by Steve McConnell (https://www.youtube.com/watch?v=lEKvzEyNtbk)

  • Learn how to deal with tech debt without drowning in it, unlike your overflowing backlog of unread emails.

🔗Links in Tech

Some additional reads we liked this week

• Infinite logo maker

• ConvertKit’s 2.7 Million MRR

• Are we in a recession? Because... Your customers THINK they're in one

• The $122Bn SEO Industry: 31 Success Stories (with Revenue Numbers) for 2023

• Why Everything Looks the Same

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to 116 new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Google’s newly announced project Service Weaver

• What are modular monoliths and do they make sense for your architecture?

• Banking in uncertain times

• The new era of design

Let's start off this week by talking about Modular Monoliths and Google's Service Weaver

Before we dive into the depths of Service Weaver, let's first take a moment to understand what modular monoliths are and why they're gaining popularity among engineers.

A modular monolith is a software architecture pattern that combines the simplicity of a monolithic application with the flexibility of microservices. This hybrid creature is achieved by organizing the code into separate, well-defined modules, each focusing on a specific domain or functionality. As a result, you get the development velocity of a monolith, with the scalability and fault-tolerance of microservices when deploying.

Google's Service Weaver: Conjuring Modular Monolith Magic

As an enchanting addition to the modular monolith ecosystem, Google's Service Weaver casts a spell that sets it apart from its counterparts. This open-source framework, designed for creating single modular binaries and deploying them as microservices, brings a unique blend of features to the table:

• Automatic RPC Translation: Service Weaver magically transforms local method calls into cross-machine RPCs during deployment. This sorcery ensures a seamless transition between monolithic development and microservice deployment, without the need for additional networking or serialization code.

• Flexible Deployment: With a flick of its wand, Service Weaver lets you deploy your application in various environments, from your local machine to cloud platforms like Google Cloud. This adaptability empowers you to test, debug, and deploy effortlessly, without altering the application code.

• Runtime Topology Decoupling: Service Weaver's charm lies in separating the development process from runtime considerations, such as microservice splitting, data serialization, and service discovery. This decoupling allows developers to focus exclusively on application logic, accelerating development velocity and performance.

• In-built Libraries: Service Weaver's magical toolbox includes logging, metrics, tracing, routing, and testing libraries, making it an all-in-one solution for creating, managing, and deploying distributed applications.

Should we embrace the Modular Monolith Movement? Why It Matters for Developers

It's worth considering why this trend is gaining momentum and what it means for developers like us.

Modular monoliths offer a compelling alternative to traditional monolithic and microservices architectures. By merging the best of both worlds, they promise a streamlined development experience with flexible deployment capabilities.

The jury is still out on the impact projects like Service Weaver will have on our architectures moving forward, but with the promise of Increased Development Velocity, Scalability & Flexibility, and easy Maintainability its worth us tracking and experimenting with.

📖 Learn more here

Here are some guides we like that can be helpful to dive deeper into Modular Monoliths and Google’s Service Weaver:

• Service Weaver Docs by Google / Service Weaver Maintainers (https://serviceweaver.dev/docs.html)

  • Learn more about the basics of Service Weaver and how it works

• Modular Monoliths by Simon Brown (https://www.youtube.com/watch?v=5OjqD-ow8GE)

  • A talk that provides insights into the concept of modular monoliths.

• Modular Monolith: A Primer by Kamil Grzybek (https://www.kamilgrzybek.com/design/modular-monolith-primer/)

  • Get ready to level up your coding game with Kamil Grzybek's guide to modular monoliths

🔗Links in Tech

Some additional reads we liked this week

• AI plugin for Photoshop

• This guy makes $180K/year writing about products banned by the big tech

• Banking in very uncertain times

• Sam Bankman-Fried Was Paid $2.2B Mostly From Alameda—Ex-CEO Caroline Ellison Only $6M

• AI to generate personal book summaries

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to the 75 new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• Chaos engineering, the art of breaking things on purpose to make them stronger

• Resources to dive deeper into chaos engineering

• Twitter API Plan Costs $2.5M/Year

• GPT-4 in March

• How does a bank collapse in 48 hours?

👹 Let's start off this week by talking about Chaos Engineering

Let's face it, in the world of software development, things break. And they break all the time. But what if instead of fearing those failures, we embrace them? That's where chaos engineering comes in. By proactively introducing controlled failures into your systems, you can identify weaknesses and fix them before they become a problem for your users.

Now, we get it, let's address the elephant in the room - yes, we know chaos engineering sounds a bit scary. But trust us, it's not as intimidating as it sounds. In fact, it can be quite fun! Here are some of the things you can do with chaos engineering:

1. Simulate a sudden increase in traffic to your application to see how it handles the load.

2. Introduce latency to your service calls to see how your application behaves under slow network conditions.

3. Inject errors into your database to see how your application handles the exceptions.

4. Randomly kill instances in your auto-scaling group to test the resiliency of your infrastructure.

5. Corrupt data in your message queues to see how your application reacts to unexpected data.

But as with any experimental practice, there are certain best practices to keep in mind to ensure you get the most out of your Chaos Engineering efforts. Here are some key guidelines to follow when incorporating Chaos Engineering into your system testing process:

1. Start small: Begin with small experiments to identify weaknesses in your system. This will help you learn how to manage risk and build confidence in your approach.

2. Plan your experiments: Identify your goals and objectives and design your experiments accordingly. Make sure to document your plans and communicate them to your team.

3. Involve your team: Chaos engineering is a team sport. Involve everyone from developers to operators to ensure a comprehensive approach.

4. Use real-world scenarios: Replicating real-world scenarios is critical to ensuring the effectiveness of your chaos engineering experiments. Use historical data or industry benchmarks to inform your experiments.

5. Automate where possible: Automate as much of your chaos engineering process as possible, including testing, monitoring, and response. This will help you to scale and repeat experiments with minimal effort.

6. Monitor and measure: Keep track of your experiments and measure the results. This will help you to identify trends and ensure that your system is improving over time.

7. Continuously improve: Chaos engineering is not a one-time exercise. Regularly review and adjust your experiments to ensure that they remain relevant and effective.

📖 Learn more here

Here are some guides we like that can be helpful to dive deeper into Chaos Engineering

• Principles of Chaos Engineering by Kolton Andrus and Casey Rosenthal (https://principlesofchaos.org/)

  • Learn more about the basics of chaos engineering

• Chaos Engineering on a Budget by Heather Nakama (https://www.infoq.com/presentations/chaos-engineering-budget/)

  • Learn how to start experimenting with chaos engineering without breaking the bank.

• The Gremlin Blog by the Gremlin Team (https://www.gremlin.com/blog/)

  • Great resources on how to introduce chaos engineering into your organization

🔗Links in Tech

Some additional reads we liked this week

• Start Building with the New Free Plan for Vultr Cloud Compute

• OpenAI GPT-4 Arriving Mid-March 2023

• How 16 Companies are Dominating the World's Google Search Results

• Spotify’s new app design is a copy of TikTok’s feed

• How does a bank collapse in 48 hours? A timeline of the SVB fall

😂 Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Did you enjoy reading this week's Bug Driven Development?

• Yes

• Meh

• No

Welcome to 187 new Bug Driven Developers this week! If you enjoy this post, forward it to your developer friends so they can join us.

Here’s what we got for you today:

• 5 Ways AI Can Help You Efficiently Document Your Software

• Resources to dive deeper into the art of Software Documentation

• YouTube CEO is stepping down

• Agile Coach Mocks Prioritizing Efficiency over Effectiveness

• The startup rollercoaster

Let's start off this week by talking about Software Documentation

Are you tired of the same old boring software documentation? Good news - you can now use AI to make it more engaging, efficient, and fun. That's right, I'm not just here to answer your coding questions, I'm also here to help you document your code with style and flair. Here are five ways to use AI to level up your software documentation game:

1. Tell me your use case: Instead of sifting through endless API docs, just tell me what you're trying to build and I'll pull out the most important bits of information for you. Plus, I'll even give you a code snippet to get you started.

2. Add some personality: Who says documentation has to be dull? With my help, you can inject some humor and personality into your docs, making them more engaging and enjoyable to read. Your users will thank you.

3. Test plans made easy: Testing your software is essential, but creating test plans can be a real pain. That's where I come in - just give me access to your software requirements and I'll create a test plan tailored to your use cases. It's that easy.

4. API docs on demand: No more struggling to generate documentation for your API endpoints. Just copy your code into ChatGPT and ask me to generate an OpenAPI spec. Voila! Instant API documentation that's clear, concise, and easy to use.

5. Configuration files made simple: Configurations can be tricky to understand, but I can help. Just copy your configuration file into ChatGPT and ask me to create a document about what each configuration does. I'll make sure it's easy to read and understand, so you can get back to coding in no time.

In conclusion, using AI for software documentation is a game-changer. It saves you time, makes your documentation more engaging and fun, and helps ensure your users have the best experience possible. So why not give it a try? Your documentation (and your users) will thank you.

Learn more here

Here are some guides we like that can be helpful to dive deeper into the art of Software Documentation:

• The Ultimate Guide To Software Architecture Documentation by Patrick Roos: [https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/]

  • If you've ever wondered how to structure, visualize, and manage your software architecture documentation, fear not - Patrick Roos has got you covered in this comprehensive guide. Don't worry, you won't need a PhD in architecture to understand it.

• The Eight Rules Of Good Documentation by Adam Scott: [https://www.oreilly.com/content/the-eight-rules-of-good-documentation/]

  • Don't let your documentation be the equivalent of a cryptic ancient scroll. Follow these 8 rules to make your project's documentation inviting, comprehensive, and skimmable.

Links in Tech

Some additional reads we liked this week

• Fast Docker builds in the cloud

• Interesting how much Stripe and Adyen diverge in terms of profitability and opex

• Apple Makes Major Progress on No-Prick Blood Glucose Tracking for Its Watch

• YouTube CEO Susan Wojcicki is stepping down

• Wacky, Unhinged Bing Chatbot Is Still Good For Microsoft’s Business

• Agile Coach Mocks Prioritizing Efficiency over Effectiveness

Meme of the Week

Twitter tweet

Thanks for tuning in to this week’s newsletter! If you have any questions, feel free to let us know on Twitter (Justin's Twitter) (Kevin's Twitter)

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?

Hey, it's Justin & Kevin - Welcome to Bug Driven Development’s first issue!

Are you tired of the same old RESTful APIs? It's time to embrace the dark side of API development with RPC and GraphQL.

Remote Procedure Call (RPC) is like the cool uncle that always shows up with a six-pack and a bag of chips. RPC is a protocol that allows a client to call a method on a remote server over a network. It's fast, lightweight, and easy to work with - like your uncle who never takes life too seriously. But beware, RPC can be a bit limiting in its capabilities, especially when it comes to more complex data structures or situations that require more advanced functionality.

On the other hand, GraphQL is like the bartender that can make you any drink you want - as long as you know what you're asking for. GraphQL is a query language for APIs that allows clients to specify exactly what data they need and how it should be structured. Plus, with the ability to stitch together multiple APIs, you can create a unified data layer that's tailored to your specific use case.

Of course, with great power comes great responsibility - or, in this case, some potential pitfalls to watch out for. With GraphQL, it's important to be mindful of performance and caching, as well as potential security concerns. Additionally, due to the flexibility of the query language, it's important to ensure that the API schema is designed in a way that promotes safe and efficient queries.

So, if you're ready to embrace the dark side of API development, give RPC and GraphQL a try. Just don't forget to choose the right tool for the job - like picking the right drink for the right occasion. Choose wisely, and you'll be rewarded with powerful, flexible APIs that can help take your applications to the next level. (Or, you know, just impress your friends at the next office happy hour. We're not saying that's not important.)

Learn more here

Here are some guides that could be helpful to dive deeper into APIs

1. Best Practices for Designing a Pragmatic RESTful API by Vinay Sahni: [https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api]

   1. Want to create a RESTful API that won't make developers want to pull their hair out? Check out this article by Vinay Sahni.

2. An Introduction to GraphQL by Tania Rascia: [https://www.taniarascia.com/introduction-to-graphql/]

   1. Need to make APIs faster than The Flash? Check out Tania Rascia's tutorial on using GraphQL.

3. gRPC - Best Practices by Manuel: [https://kreya.app/blog/grpc-best-practices/]

   1. Don't let RPC's quirks get you down. Check out Manuel's best practices for mastering gRPC.

Links in Tech

Some additional reads we liked this week

• Software is a hell of a drug - doing more with less (https://twitter.com/gregisenberg/status/1628016701991182336)

• See how well you age by transforming your face using 100% free and privacy-friendly AI. (https://extrapolate.app/)

• How Levels.fyi scaled to millions of users with Google Sheets as a backend (https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html)

Meme of the Week

Your weekly does of developer meme goodness

Twitter tweet

Thanks for tuning in to this week’s newsletter! Let us know your thoughts about it!

Did you enjoy this week’s newsletter?

Thanks,

Justin + Kevin

P.S. What new things about Software Development did you learn this week?