DEV Community: Liz Acosta

The Vonage Dev Discussion: Builder pattern

Liz Acosta — Tue, 07 Apr 2026 16:48:06 +0000

Have you ever heard of the builder pattern? 🧰🏘️

In software development, the builder pattern is a creational design pattern that lets you construct complex objects step by step. It is especially helpful when you have complex classes of objects that can be extended in many different ways.

In this video, our developer advocates Guillaume Faas and Jeremy Foster discuss the builder pattern and how it is implemented in the Vonage .NET SDK.

The builder pattern sparks debate in the dev community. Some swear by it, others see it as over-engineering. We want to know: What's your take?

Do you use the builder pattern?

How do you use it in your own work?

How would you explain it to someone?

Share your experience and knowledge of the builder pattern in the comments below!

⚒️👇

The Vonage Dev Discussion: Open source

Liz Acosta — Wed, 25 Mar 2026 16:59:12 +0000

At Women+ in Open Source Day, I got to try my hand at making a contribution to Apache Spark. While I didn’t manage to clone and build the project within the allotted time, I did get to speak with one of the project’s key contributors, Holden Karau, and was inspired by her encouragement for all sorts of people to get involved.

Contributing to open source can be intimidating! And in the age of AI, contributors from diverse perspectives are even more important.

So for our second ever Dev Discussion, we want to know: What is your advice for getting started contributing to open source projects?

Share your advice in the comments below along with links to some of your favorite open source projects! 🖥️ 🎉👇

The Vonage Dev Discussion: Music

Liz Acosta — Tue, 17 Feb 2026 20:50:55 +0000

Hey developers! We want to hear from you for a series we’re calling the Dev Discussion.

What is the Dev Discussion? We want it to be a space where we can take a break and talk about the human side of software development.

Our first Dev Discussion topic is about music 🎶

Speaking of music and tech, you’ve probably heard this track while waiting on hold ☎️🎵

Did you know it was composed in 1989 by Darrick Deel and Tim Carleton, a self described, “Yanni-loving computer nerd” who was just “messing around with a drum machine and a synthesizer” in his parents' garage in California?

You can make it your hold music too!

Besides cool drum machines and chill synthesizers, we want to know:

What is currently playing in your headphones?

Does what you listen to change according to what you are working on?

Do you ever work in complete silence?

Feel free to drop those playlists in the comments below 🎶 👇

Don’t Make Assumptions About Assertions: Even with AI you still have to write your unit tests

Liz Acosta — Sun, 26 Oct 2025 23:40:26 +0000

This blog post talks about why making assumptions about assertions makes not one “ass,” but two – which is especially true in this new age of AI. You’re not going to like this, but guess what? You still have to write your unit tests. (Sorry!)

But that’s not necessarily a bad thing! If this blog post doesn’t convince you of that, then I at least hope to invite you to reconsider your feelings about unit testing by taking a closer look at the most important component of the AAA test pattern: the assertion.

How to get the most out of this blog post

This blog post is designed to accommodate many different learning styles so you can choose your own adventure:

Jump straight to the code: Use the README to get it up and running locally.
The key to human productivity or a “disconcerting trend”?: A tale of two reports and their findings about AI, developer productivity, and code churn. (And why human generated tests are important.)
A quick review of unit tests: In case you need it.
Writing unit tests doesn’t have to be horrible: How we can use the assert methods included with Python’s unittest framework to make writing tests less awful.
Using more precise assert methods to write better unit tests: A walk-through of some code in which we’ll explore the effects of using different kinds of assert methods so you can experience that “Aha!” moment first-hand.
Resources and references: Links to more information.

AI generated code: The key to human productivity or a “disconcerting trend”?

In June 2022, GitHub Copilot went GA. A year later, in June 2023, a GitHub blog post proclaimed that “AI developer productivity benefits could boost global GDP by over $1.5 trillion,” citing a February 2023 research paper about an experiment in which a group of programmers with “access to GitHub Copilot was able to complete the task [of implementing an HTTP server in JavaScript as quickly as possible] 55.8% faster” than a control group without help from AI.

It is worth noting that of the paper’s four authors, three of them are associated with GitHub or its parent company Microsoft.

In response to this “promise to increase human productivity,” GitClear, a software engineering intelligence platform, asked the question, “How does this profusion of LLM generated code affect quality and maintainability?” To answer that question, GitClear collected 153 million changed lines of code authored between January 2020 and December 2023, and evaluated the data for differences in code quality. At the time, it was the largest known database of highly structured code change data used for this purpose, and included repos owned by Google, Microsoft, Meta, and enterprise C-Corps.

What GitClear found was “disconcerting trends for maintainability.” The authors of the report drew this conclusion from two factors they observed notable changes in following the general availability of GitHub Copilot:

Code churn

“Code churn” refers to the percentage of lines that are reverted or updated less than two weeks after being authored. In other words, this is code that was probably authored in one sprint and then reverted or updated in the next sprint because the changes were either incomplete or erroneous. The report noted that code churn increased around the same time as the release of GitHub Copilot and projected that it would continue to do so.

Added and copy-pasted code

This refers to code that is newly authored instead of code that is “updated,” “deleted,” or “moved.” The report goes on to explain that an increase in adding new code instead of refactoring existing code “resembles an itinerant contributor, prone to violate the DRY-ness of the repos visited.” (DRY is an acronym for the “Don’t Repeat Yourself” tenet of software engineering.) And who might that “itinerant contributor” be? Yup – AI.

(No, AI didn’t write that. I’ve always been a prolific em-dash user so AI probably stole its usage from me.)

So what can we, as developers, take away from this?

While both the GitHub and the GitClear reports don’t try to hide their bias or content marketing intentions, we can still glean some useful insights from them:

You’re probably going to encounter AI generated code – whether you’re the one adding it or you’re reading/reviewing AI generated code that someone else added.
I’m sorry, but you still have to write your unit tests. Now more so than ever.

… but that’s not a bad thing. (Stay with me here.)

A quick review of unit tests

What is unit testing?

Unit testing is the process of evaluating and verifying that the smallest functional units of code do what they are supposed to do individually and independently. So if we have a web application that allows a user to view collections of Pokemon according to ability, color, or type, we might have a Pokemon object with methods that perform tasks such as calling a Pokemon API endpoint, processing whatever response we get back from that endpoint, and then transforming that processed response into something we can display in a browser for the user. Our unit tests would act on each method individually and independently to verify that each method performs as expected.

The idea is that if each “ingredient” of a whole application is correct, then we can assume the end result will turn out the way we want. We can assume that if we have the right kind of tomato sauce, crust, and toppings, our pizza will be edible and delicious.

Unit tests are just one kind of software testing. There are lots of different types of tests that try to answer different types of questions such as, “Do all the different parts of this system actually work together?” and, “What happens if I throw in this totally wild edge case – will my system survive?”

(This is where I trot out my software testing alignment chart because it’s probably one of the most clever things I’ve ever created and people seem to really like it!)

The benefits of unit tests

The benefits of unit tests include:

Preventing bugs
Accelerating development
Saving money

But the most compelling benefit of unit tests is they help us become better engineers. Unit tests force us to ask ourselves, “What actually is the expected behavior of this method?” In the best case scenario, unit tests reveal code smells or redundancy or unnecessary complexity that motivate us to refactor the code under test.

A LinkedIn post in praise of refactoring and why.

Unit tests and AI

“But Liz!” you say, “Writing unit tests is so tedious and boring! Won’t I be more productive if I get AI to write them?”

Maybe.

After all, if these LLMs are trained on millions of lines of code and all of the internet, isn’t using AI to write unit tests kind of exactly like copying and pasting a solution from Stack Overflow? That time-honored tradition of software engineering?

If someone else has already figured it out, why not reuse their solution? Is that not in alignment with the DRY principle?

What could go wrong?

To answer that, here’s an excerpt from the GitHub paper on AI powered productivity mentioned above:

“We included a test suite in the repository, comprising twelve checks for submission correctness. If a submission passes, all twelve tests we counted are successfully completed. Participants could see the tests but were unable to alter them.”

In order to ensure that both the AI enabled and control groups of programmers tasked with spinning up a server did so correctly, the tests were written first. Whether the code was human or AI generated, it was verified with tests provided by the researchers.

And anyway, would you really trust an LLM trained on the tests most developers write?

A LinkedIn post describing why LLMs are bad at writing tests.

Writing unit tests doesn’t have to be horrible

Personally, I would love to one day achieve the disciplined zen of test driven development, but jumping right into the application code is just so much more seductive. It’s like eating dessert first, and while eating dessert first isn’t necessarily “bad” (we’re adults who can make our own decisions), it’s probably not great for us nutritionally in the long run. So how can we write unit tests in a way that is efficient and optimized? Unit tests that are modular and maintainable and leverage all of the tools in our toolkit?

The AAAs of testing

Typically, a test follows this pattern:

Arrange: Set up the test environment. This can include fixtures, mocks, or context managers – whatever is needed to execute the code under test. When it comes to unit tests, the test environments for each test should be isolated from each other.
Act: Execute the code under test. If it’s an end-to-end test, this might mean kicking off a workflow that includes multiple services and dependencies. In a unit test, however, this should be a single method.
Assert: Verify the results. Compare the expected result with the test results – did the code do what you want it to do? This is the most important part of the test and in unit tests, it is (usually) best practice to have one precise assertion per test.

Keeping this pattern in mind can help make it easier to write unit tests.

Don’t make assumptions about assertions

When you make assumptions about assertions, you end up with not one “ass,” but two. Just because you have 100% test coverage and everything is passing, it doesn’t mean your tests are actually meaningful or – and here’s the “galaxy brain” revelation for you – maintainable.

In Python’s untittest specifically, assert methods come included with the TestCase class. These methods check for and report failures. You are probably familiar with the tried and true assertEqual method, in which one argument is compared with another, and if the two do not match, result in a test failure … but did you know that there are so many more specific and precise assertions available to you? All out of the box?

Take a look at these!

Most common assert methods:

Method	Checks that ...
assertEqual(a, b)	a == b
assertNotEqual(a, b)	a != b
assertTrue(x)	bool(x) is True
assertFalse(x)	bool(x) is False
assertIs(a, b)	a is b
assertIsNot(a, b)	a is not b
assertIsNone(x)	x is None
assertIsNotNone(x)	x is not None
assertIn(a, b)	a in b
assertNotIn(a, b)	a not in b
assertIsInstance(a, b)	isinstance(a, b)
assertNotIsInstance(a, b)	not isinstance(a, b)
assertIsSubclass(a, b)	issubclass(a, b)
assertNotIsSubclass(a, b)	not issubclass(a, b)

Assert methods that check the production of exceptions, warnings, and log messages:

Method	Checks that ...
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*
assertRaisesRegex(exc, r, fun, args, *kwds)	fun(args, kwds) raises exc* and the message matches regex r
assertWarns(warn, fun, args, *kwds)	fun(args, kwds) raises warn*
assertWarnsRegex(warn, r, fun, args, *kwds)	fun(args, kwds) raises warn* and the message matches regex r
assertLogs(logger, level)	The with block logs on logger with minimum level
assertNoLogs(logger, level)	The with block does not log on logger with minimum level
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*

Even more specific checks:

Method	Checks that ...
assertAlmostEqual(a, b)	round(a-b, 7) == 0
assertNotAlmostEqual(a, b)	round(a-b, 7) != 0
assertGreater(a, b)	a > b
assertGreaterEqual(a, b)	a >= b
assertLess(a, b)	a < b
assertLessEqual(a, b)	a <= b
assertRegex(s, r)	r.search(s)
assertNotRegex(s, r)	not r.search(s)
assertCountEqual(a, b)	a and b have the same elements in the same number, regardless of their order
assertStartsWith(a, b)	a.startswith(b)
assertNotStartsWith(a, b)	not a.startswith(b)
assertEndsWith(a, b)	a.endswith(b)
assertNotEndsWith(a, b)	not a.endswith(b)
assertHasAttr(a, b)	hastattr(a, b)
assertNotHasAttr(a, b)	not hastattr(a, b)

Type specific assertEqual methods:

Method	Compares ...
assertMultiLineEqual(a, b)	strings
assertSequenceEqual(a, b)	sequences
assertListEqual(a, b)	lists
assertTupleEqual(a, b)	tuples
assertSetEqual(a, b)	sets or frozensets
assertDictEqual(a, b)	dicts

Using a more precise assert method can help refine your unit tests and make the work of writing them more efficient and optimized.

Getting your hands dirty: Using more precise assert methods to write better unit tests

What I appreciate most about developers as an audience is the emphasis on showing rather than telling because personally, I need to see something before I believe it, too. It’s even better when I get to run the code myself and arrive at that “Aha!” moment on my own. Hands-on is the best way to learn.

An artisanal, handcrafted, slow coded Pokemon Flask app

You’ve heard of “no code,” right? Well, get ready for “slow code.”

I wanted to see if I could use Cursor, an AI-powered code editor, to write my unit tests, but I needed some code to test first. I decided to code – by hand – a very simple Pokedex Flask app. Sure, I could have prompted Cursor to do it for me, but that seemed to defeat the purpose of the experiment. Nor does it really simulate a real world use case since most professional developers are probably working with existing pre-AI code, and, more than that, I wanted to write some Python. Isn’t that why I do this? Because it’s enjoyable?

Yeah, it’s “slow code” – and it’s important. Programming is a muscle, and if you don’t exercise it regularly, it atrophies. I understand that the craft of code is often not as important as the profit it produces, but at what cost? I could have prompted an LLM to generate this blog post, but I didn’t, because I like writing. Every blog post I write myself makes me a better writer; every line of code I write makes me a better programmer. It’s that hands-on learning thing.

So I wrote my app by hand, using a forked minimal Flask template to avoid the boilerplate code. I ended up with a web app that uses an API endpoint to view collections of Pokemon according to ability, color, or type. I muddled through the limited JavaScript the app implements and used a Python-wrapped Bootstrap library for the styling. It’s not very complicated so using Cursor to write the unit tests should be a simple task – right?

All the pink Pokemon all in one place.

A look at the AI generated unit tests

My prompt was simple: generate unit tests for pokemon.py using unittest

Let’s take a look at what we ended up with. Feel free to pull down the code here and check it out.

To start things off, let’s see if the tests pass and what kind of coverage they provide.

----------------------------------------------------------------------

Ran 12 tests in 0.008s

OK

Name              Stmts   Miss  Cover

-------------------------------------

pokemon.py           29      0   100%

test_pokemon.py     147      1    99%

-------------------------------------

TOTAL               176      1    99%

Passing tests and 100% coverage. We’re off to a promising start … or are we? Not all coverage is created equally, so it’s worth investigating the tests themselves.

Funky fixtures

def setUp(self):
    """Set up test fixtures before each test method."""
    self.mock_response = Mock()
    self.mock_response.json.return_value = {}

def tearDown(self):
    """Clean up after each test method."""
    pass

We begin benign enough with some test fixtures in which a mock response is created for every test method in the class. Things start to get a little “smelly” when we examine the teardown method, which is just a pass. In this particular case, the mock object would already be inaccessible beyond the test function it is created within, so while the teardown ensures it is truly gone, it’s a little excessive, and renders the whole fixture moot. Test fixtures can be very useful, especially when creating isolated, independent test environments, but in this scenario, it doesn’t seem to be adding to the meaningfulness of the tests.

Furthermore, mock responses are created in each of the test functions, making the fixture even more redundant. (Read more about test fixtures and mocks.)

So already we find ourselves having to refactor AI generated code.

Now let’s take a look at the first test and its assertions.

More maintainable, human friendly tests

Like their source code, tests will need to be updated as a system evolves. The more “finding and replacing” you need to conduct, the more brittle and unreliable your tests are. Using variables instead of “magic values” can reduce the number of instances that require updating. In this example, we’ve replaced the magic test values and expected values with a variable. Our test is now more modular and easier to maintain.

# Act: Execute the code under test
# Test the function

test_input = "type"
test_result = get_attributes(test_input)

# Assert: Check the results

# Add a message for the assert methods
assert_message = f"For test values: {test_input} " \
    f"the function produced: {test_result}."

self.assertEqual(test_result, expected_result)

The TestCase assert methods also take a message argument: assertEqual(arg1, arg2, msg=None) The value provided for msg outputs when a test fails. This can give us more information about a test failure, which makes it easier to fix or debug.

Let’s add a test that will fail:

# Add a test failure to demonstrate ouput
self.assertIsNone("something")

Without a message, this is what our test failure looks like:

AssertionError: 'something' is not None

With a message, and utilizing the variables we created, even our failures become helpful:

# Add a test failure to demonstrate ouput
self.assertIsNone("something", msg=assert_message)

AssertionError: 'something' is not None : For test values: type the function produced: ['fire', 'water', 'grass'].

Too many assertions

There are competing philosophies on the number of assertions that a test should contain. Some people will tell you that a unit test should have only one assertion and others might tell you that more than one is okay. When writing tests, it’s important to remember that the assert methods provided by TestCase “check for and report failures.” Imagine if all of these assertions result in failures you have to then fix or debug. Do these failures actually tell us anything about the code under test?

# Assertions
self.assertIsInstance(result, list)
self.assertEqual(len(result), 3)
self.assertIn("fire", result)
self.assertIn("water", result)
self.assertIn("grass", result)
self.assertEqual(result, ["fire", "water", "grass"])

If we look at the code under test, a list of strings is returned. That’s it, that’s all that happens. While this code is not code you’d want to push to production, it is the code we are testing.

def get_attributes(attribute):
    response = requests.get(BASE_URL + attribute)
    response_json = response.json()

    attributes_list = [item["name"] for item in response_json["results"]]

    return attributes_list

Do we really need to assert on the specific contents of the list? Especially if this particular function doesn’t do anything with those contents? We probably want to reduce the number of assertions in this test. We really only need to test whether or not the code produces a list.

We can do that with assertEqual(test_result, expected_result, msg=test_message or we can eliminate yet another assertion (the assertIsInstance) with assertListEqual which will not only compare the lists, but also verify the list type.

self.assertListEqual(test_result, expected_result, msg=assert_message)

Don’t believe me? Let’s change expected_result to a string and see what happens when we use assertListEqual:

# Change `expected_result` to a string
self.assertListEqual(test_result, "'fire', 'water', 'grass'", msg=assert_message)

AssertionError: Second sequence is not a list: "'fire', 'water', 'grass'"

The test fails. Now we’ve verified not only the test result itself, but the test result type as well.

Can we eliminate another assertion? Let’s see!

Let’s say we want to also make sure we don’t end up with an empty list even though we might not know the exact number of list elements we will end up with. This is where we can use assertGreaterThan and create a variable list_minimum = 0 for the minimum value we can accept – which, in this case, is zero.

self.assertGreater(len(test_result), list_minimum, msg=assert_message)

No comment please

This is just a nit, but the AI generated tests included this comment:

self.assertEqual(result, ["fire", "water", "grass"])  # Order matters for this function

Nothing in the code suggests that, so it’s just a random comment. In response, I added my own useless comment: # No, it doesn't

(I don’t cover the rest of the tests here, but if you check out the code, I’ve commented on the parts of the tests that I would have to refactor if I wanted to make this code production ready.)

Before and after

Comparing the test before and after, our new test is a lot more succinct, meaningful, and maintainable. Now, no matter how the source code evolves, we can rely on this test to tell us if we’ve introduced any breaking changes.

Before:

@patch("pokemon.requests.get")
def test_get_attributes_success(self, mock_get):
    """Test get_attributes function with successful API response."""

    # Mock the response
    mock_response = Mock()
    mock_response.json.return_value = {"results":[
                                                 {"name": "fire"},               
                                                 {"name": "water"},
                                                 {"name": "grass"}]}
    mock_get.return_value = mock_response

    # Test the function
    result = get_attributes("type")

    # Assertions
    self.assertIsInstance(result, list)
    self.assertEqual(len(result), 3)
    self.assertIn("fire", result)
    self.assertIn("water", result)
    self.assertIn("grass", result)
    self.assertEqual(result, ["fire", "water", "grass"])  # Order matters for this function
    mock_get.assert_called_once_with(BASE_URL + "type")

After:

@patch("pokemon.requests.get")
def test_get_attributes_success(self, mock_get):
    """Test get_attributes function with successful API response."""

    # Mock the response
    mock_response = Mock()
    mock_response.json.return_value = {"results":[
                                                 {"name": "fire"},               
                                                 {"name": "water"},
                                                 {"name": "grass"}]}
    mock_get.return_value = mock_response

    # Test the function
    test_input = "type"
    test_result = get_attributes(test_input)

    # Assert
    assert_message = f"For test values: {test_input} " \
        f"the function produced: {test_result}."

    expected_result = ['fire', 'water', 'grass']
    list_minimum = 0

    self.assertGreater(len(test_result), list_minimum, msg=assert_message)
    self.assertListEqual(test_result, expected_result, msg=assert_message)
    mock_get.assert_called_once_with(BASE_URL + 'type')

In conclusion: Unit tests are the human in the loop

Whether your code is meticulously typed out character by character, copied and pasted from Stack Overflow, or generated by an LLM, unit tests are the quickest way to verify it operates as expected. Moreover, when we start with unit tests that are written with as much care and intention as the source code itself, we lay the foundation for efficiency and optimization which makes writing the next set of unit tests much less laborious and tedious. Solid unit tests are an investment in future productivity. While AI can “hallucinate,” it has no imagination or empathy, so it cannot write tests for the humans who will eventually be stuck deciphering test failures.

What do you think? Do you think AI will get better at writing unit tests? Do you feel inspired to try out other assert methods in your testing?

Resources and references

❤️ If you found this blog post helpful, please consider buying me a coffee.

A New Era of Code Quality: Beyond bugs and into legal license compliance and risk management

Liz Acosta — Wed, 25 Jun 2025 18:16:46 +0000

In the interconnected world of software, few applications are conjured into existence entirely from scratch. Developers consistently draw upon a vast ecosystem of open-source libraries, frameworks, and external components, all designed to expedite coding and reuse established solutions. It’s simply efficient: Why should anyone invent a solution when a perfectly good one already exists?

However, while incredibly efficient, reliance on third-party components comes with its own baggage: Licensing. It may seem like a minor detail, but failure to understand or comply with the terms of even one license — among the dozens or hundreds typically found in a modern application — can lead to severe legal disputes, the forced open-sourcing of proprietary code, and substantial financial penalties. This makes license compliance a remarkably complex and unglamorous undertaking.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead:

License and litigation and why it’s important to pay attention
The intersection of dependency management, SBOMs, and software licenses
How license management contributes to code quality
More resources and references

License and litigation and why it’s important to pay attention

Modern software projects often have a deep “dependency tree,” where a direct dependency itself relies on other libraries (transitive dependencies). It’s easy to overlook the licenses of these indirect dependencies, leading to hidden compliance risks. Unfortunately, “I didn’t know” is not an excuse that holds up in court.

Not even the biggest corporations are immune to the consequences of license mismanagement. License violations have cost companies millions of dollars, forced code disclosure or refactoring, injunctions, settlements, and precious time and resources that could have been spent otherwise.

The intersection of dependency management, SBOMs, and software licenses

What is an SBOM?

An SBOM acts as a comprehensive, machine-readable inventory of all components within a software package. Much like an ingredients list on a food product, a Software Bills of Materials (SBOM) details every piece of open-source and proprietary software, libraries, and modules that make up a given application, along with their versions and origins. And just as a food label might list “enriched flour” and then detail its components like niacin and thiamine, an SBOM also breaks down your dependencies’ dependencies, giving you a complete picture of every ingredient. For developers, maintaining an up-to-date SBOM is crucial for visibility into their software supply chain, enabling them to track and respond to security advisories more effectively.

An example of an SBOM in JSON according to the CycloneDX format.

What is dependency license management?

As developers, we are usually pretty aware of the importance of checking our “list of ingredients” (albeit often against our will while detangling dependency conflicts) and even if we don’t always immediately address CVEs, we at least know we should probably cut a card for the task. Another aspect of dependencies that we may know less about is license management.

At its core, a software license is a legal agreement that defines the terms under which you can use, modify, and distribute a piece of software. Think of it like a contract between the creator (licensor) and the user (licensee). Most open-source software comes with specific licenses that dictate how it can be used, modified, and distributed. Failing to comply with these licenses can lead to legal complications, intellectual property disputes, and financial penalties. An SBOM can serve as a foundational tool for license compliance, providing a clear record of the licenses associated with each component. This becomes particularly important in environments where certain license types (e.g., strong copyleft licenses like GPL) may have significant implications for the broader software product.

The intersection of SBOMs, CVEs, and licensing forms the backbone of effective dependency management. In an era where AI hallucinations and the accidental inclusion of malicious or problematic packages are growing concerns, the practice of diligent processes for generating and analyzing SBOMs become indispensable to the production and deployment of quality code.

What are the different kinds of software licenses?

These licenses are the legal frameworks that define how you can use, modify, and distribute software, whether you’re building a new application, contributing to an open-source project, or simply using a program on your computer. Understanding the distinctions between these licenses is crucial for avoiding legal pitfalls, ensuring compliance, and making informed decisions about your software projects. Licenses can be broken down into the following broad categories:

Standard permissive: The most commonly used permissive licenses. They grant broad permissions to use and modify with very minimal obligations (primarily attribution) and have all the essential elements of permissive open source licenses. Examples include MIT and Apache software licenses.
Non-standard permissive: Permissive licenses that lack one or more essential elements of modern permissive open source licenses, or impose complex or confusing requirements. Examples include Artistic 1.0 and the WTFPL software licenses.
Weak copyleft: Weak copyleft licenses require sharing your changes and additions to the licensed software when you give copies to others. Examples include GNU LGPL and the Mozilla Public License.
Strong copyleft: In addition to the requirements of the weak copyleft licenses, strong copyleft licenses require you to share larger programs that you build with the licensed software when you give copies to others. Examples include the GNU GPL license.
Network copyleft: In addition to the requirements of strong copyleft licenses, network copyleft licenses require you to share larger programs that you build with the licensed software not just when you give copies to others, but also when you run the software for others to use over the Internet or another network. Examples include the GNU AGPL (Which is different from the GNU LGPL!) and the Server-Side-Public License.
Maximal copyleft: Maximal copyleft licenses answer the question “When does the license require you to share?” differently than other licenses. Maximal copyleft licenses require you to share software you make with others, and to license that software alike when you do. Examples include the Parity and Reciprocal software licenses.
Uncategorized: Nonstandard licenses that do not fit into the above categories.

With SonarQube Software Composition Analysis, each dependency includes information for all the dependencies it relies on so you can see exactly which licenses are being introduced into your project.

How license management contributes to code quality

At a fundamental level, high-quality code embodies these key traits: it’s reliable, secure, and maintainable. Software licensing may not be the first thing that comes to mind when considering code maintainability, but think of it this way: Much like tech debt, leaving license management for later can result in “legal debt” that almost inevitably comes to collect. Dependency trees are already thorny when it comes to keeping versions in line, just imagine having to remove dependencies due to license violations. Or worse — the possibility of being forced to recall a product (and all the effort that went into it). Decommissioned code is not maintainable code.

Moreover, because you can’t oversee the licensing decisions or compliance procedures governing your dependencies’ code, you need an alternative approach to ensure their potential license problems don’t jeopardize your own software’s legal standing. Nowadays, a rigorous and intelligent code quality discipline absolutely must encompass legal considerations like dependency license management.

SonarQube’s Software Composition Analysis (SCA) goes beyond just listing your project’s dependencies. It also provides a comprehensive overview of associated license risks, complete with holistic scoring and actionable remediation steps. This allows you to prioritize and address license compliance issues according to your organization’s specific needs.

💡 Want to learn more about SonarQube Software Composition Analysis? Check out a tutorial here.

More resources and references

Read more about coding best practices here.
Read more about best practices for dependency risk management in particular here.
For a breakdown of other top security flaws and how to address them, check out Jonathan Vila’s article on the topic.
Want to learn more about SBOMs? This article provides a comprehensive overview.

A New Era of Code Quality: Beyond bugs to supply chain security and dependency health

Liz Acosta — Wed, 25 Jun 2025 17:57:08 +0000

In today’s interconnected software landscape, most applications don’t just spring up from thin air. Developers are constantly pulling in countless open-source libraries, frameworks, and other third-party components to speed things up and reuse existing solutions. And why not? If a specialized solution already exists for a particular problem, why reinvent the wheel? However, while efficient, this reliance opens up a massive new vulnerability: the software supply chain.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead:

Weak links: Anatomy of a supply chain attack and the new threat AI poses
The intersection of dependency management, SBOMs and CVEs
A stick or a snake: A framework for evaluating risk
How security contributes to code quality
More resources and references

Weak links: Anatomy of a supply chain attack

In the context of cybersecurity, a supply chain attack refers to a cyberattack that targets an organization by infiltrating less secure elements in its extended network of partners, suppliers, or components, rather than directly attacking the primary target itself. Simply put, it’s like a hacker getting to you by attacking someone you do business with.

The core idea is to compromise a trusted third party or a component that the target organization relies on. By doing so, the attackers can then gain unauthorized access or introduce malicious code into the target’s systems, products, or services without directly breaching their main defenses.

Think of it like this: If you want to break into a heavily guarded fortress (the main target), instead of attacking the front gates, you find a weakness in the company that supplies their food or builds their walls, and use that weakness to get inside.

These attacks are particularly dangerous because:

They leverage trust: The malicious element comes from a source that the target organization or its customers inherently rely on.
They have a wide blast radius: Compromising one component or supplier can lead to a ripple effect. That means that even if your organization wasn’t the primary target of such an attack, you can still be compromised.
They are often difficult to detect: The malicious activity might be hidden within legitimate software updates, hardware, or services, making it challenging for standard security measures to identify.

Common vectors for supply chain attacks include:

Software updates: Injecting malware into legitimate software updates, often by compromising the software vendor’s systems or exploiting vulnerabilities in the update delivery mechanism.
Open-source components: Introducing malicious code into widely used open-source libraries that developers then incorporate into their applications.
Hardware tampering: Modifying hardware components during manufacturing or shipping.
Compromised build tools or environments: Attacking the tools or infrastructure used to build software.
Third-party service providers: Gaining access through a less secure vendor that has legitimate access to the target’s systems (e.g., an IT service provider).

We’ve seen this play out in countless high-stakes scenarios, where everyone from savvy cybercriminals to highly resourced, persistent threat actors has leveraged these dependency pathways. These weren’t about traditional application hacks. They were about malicious packages quietly slipped into public repositories, compromised build pipelines, or trusted updates carrying hidden payloads. And it’s not always malicious! Sometimes a supply chain vulnerability is just a really, really big unintentional complication.

As these supply chain attacks and vulnerabilities illustrate, maintaining a clean Software Bill of Materials (SBOM) is critical to code security. An SBOM is essentially a detailed “ingredient list” for your software, identifying all its components, including open-source libraries and third-party code. This transparency helps you understand exactly what’s in your software, which is crucial because bad actors know how challenging it can be to assess, verify, and remediate these hidden supply chain vulnerabilities. In modern software, it’s a constant tightrope act of prioritization with weights that shift as you cross the wire.

But don’t worry — it gets more complex!

First came “vibe coding” …

“Vibe coding” is an emerging approach to software development, heavily reliant on artificial intelligence, particularly large language models (LLMs). First mentioned by AI researcher Andrej Karpathy in early 2025, “vibe coding” describes a process where developers primarily use natural language prompts — speaking or typing in plain language — to instruct AI tools to generate, refine, and debug code. The core idea allows users to focus on describing what they want the software to do (the “vibe” or intent), letting the AI handle much of the how (the actual code implementation), often without the developer needing to fully understand the generated code. This method aims to make software creation more accessible and potentially faster, especially for simpler projects or prototypes.

It has been met with both a great deal of skepticism and support. Love it or hate it, “vibe coding” is changing the way we approach the software development lifecycle, and with these new tools come new challenges.

Now there is “slopsquatting”

Coined by Python Software Foundation Developer-in-Residence Seth Larson and popularized by a Mastodon post from Ecosyste.ms creator Andrew Nesbitt, “slopsquatting” — more formally known as “package hallucination” — is a type of cybersquatting. It is the “practice of registering a non-existent software package name that a LLM may hallucinate in its output.” At best, developers may attempt to install an AI-suggested package only to run into an annoying error; at worst, these false packages are exploited.

For example, if an AI suggests using a non-existent package like super_fast_lib and a malicious actor then registers that name on a public repository, a developer blindly installing it could inadvertently introduce malicious code. This is where a robust Software Bill of Materials (SBOM) becomes crucial: An SBOM would ideally reveal the presence of such an unfamiliar or newly added dependency, alerting security teams to a potential slopsquatting attempt and a vulnerability in their supply chain.

Either way, slopsquatting is yet another threat to software supply chain integrity, and along with all the other risks of vibe coding, further emphasize the need for human oversight in AI-generated code.

Whether it’s a package that doesn’t actually exist or a package that has been deliberately exploited, software dependencies can be a point of weakness in any system. Secure code is an important aspect of the reliability and integrity of your production systems, regardless of whether the code comes from a third-party, AI, or in-house development. Implementing best practices at every step of development helps ensure that code is not only readable and maintainable, but secure as well.

The intersection of dependency management, SBOMs and CVEs

As highlighted by some of the most notable supply chain attacks and the emerging threat of “slopsquatting,” the increasing reliance on third-party software components underscores the critical importance of robust dependency management. This discipline isn’t just about integrating external code, it’s about understanding and mitigating the inherent risks associated with it. Central to this understanding are Software Bills of Materials (SBOMs) and Common Vulnerabilities and Exposures (CVEs).

What is an SBOM?

An example of an SBOM in JSON according to the CycloneDX format.

What is a CVE?

Closely related to SBOMs are Common Vulnerabilities and Exposures (CVEs). A CVE is a publicly available identifier for a known cybersecurity vulnerability. When a vulnerability is discovered in a specific software component (often a library or framework), it is assigned a CVE ID. By cross-referencing components listed in an SBOM with known CVEs, organizations can rapidly identify and prioritize patching efforts for vulnerable dependencies. This proactive approach helps to prevent exploitation by malicious actors who might otherwise leverage unpatched weaknesses. The “SunSpot” malware’s ability to operate with elevated permissions and deploy backdoors underscores the severe consequences of unaddressed vulnerabilities, whether they stem from sophisticated supply chain attacks, more common software flaws, or AI hallucinations.

An example of a CVE record.

A stick or a snake: Not every CVE is a threat to your supply chain

According to CVE.org, 40,077 CVEs were published in 2024, which is a significant jump from 2023’s 28,961 published CVEs. Responding to each and every CVE in a supply chain is neither feasible nor practical and with FIRST (the Forum of Incident Response and Security Teams) predicting an increase of CVEs in 2025, you need to draw on other information to determine best next steps when alerted to a CVE for one of your dependencies.

Imagine you are walking down a road where snakes are known to slither and you see a stick in the distance. You might mistake it for something more dangerous than just an errant piece of wood. If you’ve had the misfortune of a snake bite, you might be biased toward assuming the stick is more than just a stick. Conversely, if you’ve never encountered a snake despite reports of their presence, you might walk too close past what you think is a stick and make your last mistake ever.

Not all dependency vulnerabilities and exposures pose the same risk. How a CVE may affect a system is dependent (See what I did there?) on a few different factors:

The Common Vulnerability Scoring System (CVSS)
The Known Exploited Vulnerabilities (KEV) catalog
The Exploit Prediction Scoring System (EPSS)

With SonarQube Software Composition Analysis, each dependency risk is evaluated holistically. As you can see here, while the CVSS score is high, the EPSS score is closer to medium with no known exploits. This information can help you determine if this CVE is worth addressing and how.

Combining all these facets of a CVE helps provide a more holistic approach to vulnerability remediation. In order to understand how CVSS, KEV, and EPSS come together, it’s important to understand them independently.

What is the CVSS?

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. It provides a numerical score (ranging from 0.0 to 10.0) that reflects the characteristics and severity of a vulnerability. Commissioned by the National Infrastructure Advisory Council (NIAC) and now under the custodianship of the Forum of Incident Response and Security Teams (FIRST), the CVSS was introduced in 2005. Its mission is to standardize vulnerability assessments to empower organizations to evaluate and respond to risks efficiently and effectively.

A CVSS score is determined by three metric groups:

Base: These represent the intrinsic characteristics of a vulnerability and are constant over time and across user environments. They consider factors like attack vector, attack complexity, required privileges, user interaction, scope, and impact on confidentiality, integrity, and availability.
Temporal: These reflect the evolving characteristics of a vulnerability over time. They account for factors such as the maturity of the exploit code, the availability of a fix, and the level of confidence in the existence of the vulnerability.
Environmental: These metrics allow for custom adjustments to the score based on the specific context of an organization’s environment. For example, a vulnerability might be more critical in a system handling sensitive government data than in a less critical internal tool.

To summarize, CVEs provide a unique identifier for a publicly known security flaw while the CVSS provides the numerical severity rating that helps organizations assess the risk associated with a CVE within their specific context. CVSS scores serve as a vital tool for making informed decisions about which dependencies to use, which to patch first, and how to allocate limited security resources most effectively.

An example of a CVSS score.

What is a KEV?

While the CVSS provides a crucial framework for assessing the technical severity of a vulnerability, it doesn’t inherently tell you if that vulnerability is actively being used by attackers “in the wild.” This is where the concept of a Known Exploited Vulnerabilities (KEV) catalog becomes useful.

A KEV catalog is a curated list of vulnerabilities that are known to have been actively exploited by threat actors. Unlike a comprehensive database of all discovered vulnerabilities (which can number in the hundreds of thousands), a KEV catalog focuses on the subset of vulnerabilities that pose an immediate and proven threat because they have already been leveraged in real-world attacks.

The most prominent and widely referenced KEV catalog is maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The CISA’s KEV contributes critically to cybersecurity by:

Prioritizing remediation: If a dependency in your software has a CVE that appears on the KEV list, it signifies an urgent need for patching or mitigation, regardless of its CVSS score. (Not surprisingly KEVs often have high CVSS scores.) The fact that a vulnerability has been exploited means it’s not a theoretical risk, but a clear and present danger.
Shifting from reactive to proactive defense: By focusing on vulnerabilities that attackers are already exploiting, organizations can more effectively cut through the noise of countless theoretical vulnerabilities and target efforts where they will have the most impact.
Providing actionable intelligence: The KEV catalog is not just a list; it provides actionable intelligence to defenders. It serves as a clear signal from a trusted authority that these specific vulnerabilities are being weaponized and require immediate attention.

For federal agencies and — increasingly — for private sector organizations, vulnerabilities listed in the CISA KEV catalog are considered extremely high-priority. Without this particular KEV catalog, organizations may be forced to cross reference several different sources in order to not waste precious resources chasing after every single risk in an increasingly insecure cyber landscape.

What is the EPSS model?

In the ongoing battle to secure complex software supply chains, simply knowing about vulnerabilities (CVEs) and their technical severity (CVSS), or even if they’ve been exploited (KEV), isn’t always enough to make the most informed decisions. Security teams need to understand the likelihood that a newly disclosed vulnerability will be exploited in the near future. This is precisely the gap that the Exploit Prediction Scoring System (EPSS) model aims to fill.

The EPSS is an open, data-driven, and predictive scoring system that estimates the probability of a software vulnerability being exploited in the wild within the next 30 days. Developed by FIRST — the same organization behind CVSS — EPSS provides a crucial layer of intelligence that complements existing vulnerability management tools.

Unlike the CVSS, which scores the severity of a vulnerability’s potential impact, EPSS focuses exclusively on the probability that it will be actively exploited. A vulnerability might have a high CVSS score, but if no one is actually exploiting it, its immediate risk profile might be lower than a medium-CVSS vulnerability that has a high EPSS score.

The EPSS estimate is updated regularly based on the following criteria:

The existence of publicly available exploit code.
Discussions of the vulnerability on social media and dark web forums.
The age of the vulnerability.
The prevalence of the affected software.
Its relationship to other exploited vulnerabilities. This dynamic nature means EPSS scores can change rapidly as new information emerges, reflecting the evolving threat landscape.

A diagram comparing the outcomes of CVSS scores vs. EPSS scores.

Combined with CVEs, a CVSS score, and data from the CISA KEV catalog, the EPSS estimate plays a vital role in an environment where the speed and sophistication of attacks — as seen in supply chain compromises — demand smarter and more efficient resource allocation to secure ever-growing and complex software dependencies.

In other words, security threats contain different facets of vulnerability that together determine the risk they pose and the urgency with which they should be addressed. Once you have decided that the stick down the road is indeed a snake, your next moves are based on your proximity to the snake, whether or not the snake is poisonous, whether or not an antidote exists, and whether or not the snake is an aggressive and deadly rattle snake or a common garter snake that will mostly likely just slither away upon your approach. In moments where quick decisions can be a matter of life or death — or a matter of a quick patch or a security notice to customers — these inputs help form a framework of threat evaluation that can help streamline next steps.

How security contributes to code quality

At a fundamental level, high quality code exhibits the following traits: it is maintainable, it is reliable, and it is secure. With software’s increasing power and complexity, relying on third party components is inevitable. And that’s not a bad thing — in fact, avoiding redundancy is a good coding best practice. However, since you don’t get to review the pull requests that are merged into the code of your dependencies, you need some other method of ensuring that their potential lapses in code quality don’t affect the quality of your code. These days, a robust and intelligent code quality discipline needs to include security considerations such as dependency vulnerability management.

A tool like SonarQube Advanced Security and its Software Composition Analysis (SCA) enables you to not only view all the dependencies within your project, but provides you with a list of dependency risks with holistic scoring and actionable fixes so you can prioritize next steps according to the specific needs of your organization.

In collaboration with Tidelift and its roster of open source maintainers, SonarQube SCA goes beyond public databases of vulnerabilities and provides insights straight from the source. This adds a layer of specialized intelligence that can help reduce the noise often associated with dependency scanning. While the Exploit Prediction Scoring System (EPSS) offers a probability of exploitation, building on the critical “Known Exploited Vulnerabilities” (KEV) catalog, SonarQube SCA further enhances this by integrating real-world maintainer insights, providing an even more refined and actionable understanding of risk. (Because we all know how often we actually look at our Dependabot alerts …)

💡 Want to learn more about SonarQube Software Composition Analysis? Check out a tutorial here.

More resources and references

Read more about coding best practices here.
Read more about best practices for dependency risk management in particular here.
For a breakdown of other top security flaws and how to address them, check out Jonathan Vila’s article on the topic.
Want to learn more about SBOMs? This article provides a comprehensive overview.

Passing the Vibe Check: Navigating the changing development landscape

Liz Acosta — Fri, 16 May 2025 16:50:04 +0000

In February 2025, OpenAI researcher Andrej Karpathy coined the term “vibe coding” on social media. In his post, he described his process for developing a small project — without ever writing any code of his own.

The inception of the term “vibe coding.

To build his “amusing throwaway weekend project,” Karpathy didn’t even need to touch a keyboard. He used superwhisper, an AI-powered voice to text transcriptor, to dictate application requirements to Cursor Composer. Cursor Composer, the AI-powered multi-file code editor and application generator, then translated the dictated instructions into a complete web app. Karpathy adjusted the app with the “dumbest” prompts like “decrease the padding on the sidebar by half” and accepted the changes without reviewing the diffs. When Karpathy encountered an issue that Cursor couldn’t fix, the OpenAI co-founder would just “ask for random changes” until the bug went away.

“It’s not really coding,” he admitted, “I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.” (Emphasis mine.)

Look ma — no typing! A diagram of Karpathy’s vibe coding stack.

But the vibes were anything but good for Leonel Acevedo, CEO of EnrichLead. In March 2025, he posted on social media about the SaaS application he’d built with “zero hand written code,” concluding that everyone else could “continue to whine about it [AI] or start building.” This use of AI contrasts with Karpathy’s “throwaway” project as Acevedo was touting a production-ready SaaS application and implying a different level of robustness and real-world applicability.

Just a few days later, Acevedo posted that EnrichLead was under attack with “random things happening” such as maxed-out API keys, bypassed subscriptions, and corrupted databases. Because Acevedo isn’t technical, it took him longer than he anticipated to debug the code. Eventually he discovered that his vibed code exposed important API keys, making his app vulnerable to attack.

The worst kind of live debugging ever.

Accidentally pushing a hardcoded secret can be seen as a rite of passage for developers. This mistake is so common that GitHub has automatic alerting, and remediation for unintentionally publicized keys and tokens; at Sonar, we shifted that check further left by highlighting potential vulnerabilities right in your IDE. With the advent of “vibe coding,” incidents like the one EnrichLead experienced are likely to become more common. While it’s too soon to say if vibe coding will persist, one thing we know for sure is that AI-generated code is here and it’s here to stay.

And it’s just another iteration of the continuously evolving software development lifecycle.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead.

What is vibe coding?: A definition of vibe coding along with the associated tools, benefits, and disadvantages
To vibe or not to vibe?: Surviving AI as a developer
More than just vibes: How AI can help us become better developers
Try it yourself: Tools and resources for surviving vibe coding

What is vibe coding?

Vibe coding — or if you prefer a less cringey name, “AI coding” — is “an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding.” Vibe coding relies exclusively on LLMs to interpret requirements and generate entire applications accordingly.

What tools are used for vibe coding?

The most popular vibe coding tools at the moment are Cursor and Windsurf. Both IDEs use Claude 3.5 Sonnet under the AI hood, but with different features and user experiences.

Cursor and Windsurf use the same LLM under the hood, but each IDE has its own vibes.

What are the benefits of vibe coding?

Lower cost of entry: No coding knowledge, no problem! If you’ve got a good, well thought-out idea and can write a decent prompt, the code itself is no longer an obstacle.
Higher development velocity: When you can let the IDE handle all of the code, prototyping and iteration cycles become quicker and easier.
More room for complex and innovative problem solving: With the burden of writing boilerplate, class setups, basic CRUD operations, and other tedious tasks lifted, developers are free to focus on more high-level logic.
A bridge for knowledge gaps: Even the most experienced developer faces the challenges of learning new technology — AI coding can facilitate quicker onboarding by supplying the fundamentals.

Prompting Cursor to generate a Pokédex Flask app …

… and it worked!

What are the disadvantages of vibe coding?

Lack of consistency and predictability: It is important to remember that the output of LLMs is not deterministic. This can lead to a codebase with varying styles, structures, and approaches, rendering the code harder to understand, maintain, and debug predictably.
An increased vector of bugs, errors, and security vulnerabilities: Because AI doesn’t actually “know” anything, a prompt may generate code with issues that a more experienced developer would know to avoid.
Challenges in long-term maintainability and scalability: Without any context, an LLM may produce code that is inconsistent and with no consideration for future optimization.
Less developer productivity: AI-generated code may not be well documented, increasing developer toil while trying to refactor, debug, or extend code. Moreover, trying to refine a prompt for a more desired outcome could take more time than just writing the code manually.

The problem with vibes: You probably know better than to include all your styling in your HTML template file … but AI doesn’t!

To vibe or not to vibe? Surviving AI as a software developer

The software development lifecycle (SDLC) refers to a structured process for designing and building software. It is a rapidly evolving landscape wherein each iteration the role of the developer changes and adapts to address the latest challenges in software engineering.

In the earliest “code-and-fix” era, the developer was a lone coder, directly addressing issues as they arose with little formal process. The advent of the Waterfall model transformed the developer into a specialist within a linear process, focusing on specific stages like coding or testing after requirements were defined. Iterative and incremental models then required the developer to become more adaptable, working in smaller cycles and integrating feedback more frequently.

The rise of object-oriented methodologies shifted the developer towards architect and component builder, emphasizing modularity and reusability. The Agile revolution demanded the developer become a collaborative team member, engaging in frequent communication, adapting to changing requirements, and participating in all stages of the sprint. Finally, the Lean and DevOps era positions the developer as an integrated part of the entire delivery pipeline, involved in automation, deployment, and operations, with a broader responsibility for efficiency and reliability.

AI coding signals a new horizon for SDLC, and with that new day comes new opportunities for developers — as long as we’re prepared for them.

The only const is = “change”: The evolution of the software development lifecycle.

The evolution of the developer

By understanding the benefits and disadvantages of AI, you will be better equipped to continue to grow as a developer. After all — you are a developer. You’re smart and learning new technologies is what you do best.

Familiarize yourself with AI coding tools for developers. Whether you call it “vibe coding” or “AI coding,” check out the different tools people are using. There’s nothing quite like hands-on experience to learn something new.
Vibe, but verify. Get into a good practice of double-checking the AI’s work. With AI doing most of the heavy lifting, your job is more about diligently overseeing and reviewing the code rather than manually composing it. Employing a code quality tool like SonarQube could have prevented EnrichLead’s secret exposure.
Embrace the opportunity to think more systematically. With AI handling all the nitty-gritty, you can focus more on solving more complex problems with more innovative solutions. You are more free to be an architect without having to be an expert on each component.
Learn how to refine your prompts. LLMs like Claude respond better to clear, concise prompts that explicitly outline what is being requested and what the expected output is. Thinking more strategically about what your requirements are, what kind of design pattern you want to follow, how you are going to test your code, and how you are going to deploy and maintain it will help inform and improve your prompting.

💡 How could you formulate a prompt to avoid exposing secrets? What requirements or parameters would you include?

More than just vibes: How AI can help us become better developers

Waterfall, Agile, ad-hoc, DevOps, vibe coding — no matter what SDLC or tools we are using, as developers, we are concerned with efficiency, optimization, reliability, and maintainability. We want to make software that is useful and we don’t want to get paged in the middle of the night for an incident. AI can be a valuable tool that helps remove some of the more tedious tasks associated with development and free us to think more creatively; the potential disadvantages of AI mean we have the opportunity to be more deliberate and intentional in our work.

While we can’t predict exactly how AI will affect the software development lifecycle, we do know that no matter what direction it takes, code quality and security will always be central to meaningful, robust, and reliable software.

Just ask the guy at EnrichLead.

Try it yourself: Tools and resources for surviving vibe coding

For all you Java developers out there, Sonar developer advocate Jonathan Vila has posts on Java and code quality here.
Interested in learning more about how Sonar can help you vibe better? Check out this tutorial.
Still feeling a little AI anxiety? This article by UX Collective’s Pete Sena might help alleviate that.
Whether we like it or not, AI is (probably) here to stay, so now’s a good time to start developing some good AI coding habits.
No matter what, best practices will always be in style.

Code That Won’t Cost You: Coding best practices for any language to increase code quality and reduce developer toil

Liz Acosta — Tue, 13 May 2025 20:21:02 +0000

Bad code is not only hard to read, it can cause expensive incidents. According to the Uptime Institute’s 2022 Outage Analysis, “nearly 40% of organizations have suffered a major outage caused by human error over the past three years” with over 60% of all failures resulting in at least $100,000 in total losses.

With more and more AI-generated code creeping into software, the potential for bad code increases. While LLMs are just the latest innovation altering the software development lifecycle, regardless of whatever disruption comes next, code will always benefit from consistently applied best practices.

In this article, we’ll talk about tech debt, good versus bad code, best practices to follow, and other ways you can fortify your software. We’ll also discuss practical strategies for implementing these best practices in your development workflow.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead.

When tech debt comes to collect: Understanding the cost of neglecting code quality
The good, the bad, and the ugly code: What “good code” is and why it is important
Suggested best practices for code quality in any language: The primary focus of this article, this section suggests best practices for avoiding bad code
From theory to practice: Best practices for implementing coding standards effectively
Key takeaways: Building a foundation for sustainable software development
Try it yourself: Tools and resources for enforcing code quality

When tech debt comes to collect: Understanding the cost of neglecting code quality

“Oh, we’ll add that to the backlog and when we have a chance, we’ll get around to it.”

Say these words two more times and you’ll invoke a curse known as “technical debt.” For those of you new enough in your engineering careers to be blissfully unaware of this curse, technical debt (often shortened to “tech debt”) refers to the extra work required in the future to correct the outcomes of faster or more expedient solutions, including architectural designs and development shortcuts, taken in the present. Like financial debt, tech debt incurs interest the longer it is put off. And like financial debt, tech debt can be expensive.

In January 2023, tech debt came to collect when more than 1,300 flights in the United States had to be cancelled and 10,000 more delayed. Why? Because files accidentally deleted while trying to update a database caused the Notice to Air Missions system (NOTAM) — which alerts pilots to potential hazards along their routes — to fail. It wasn’t the first time something like this had happened; they had been kicking the tech debt can down the road for years.

In essence, tech debt is the result of unaddressed technical decisions, including poorly written code, that have remained unchanged and propagated throughout a software system, leading to future complications. When these brittle systems finally collapse, it costs more to fix them than it would have cost to avoid the debt altogether. Moreover, on average, developers waste 23% of their development time on tech debt, and the cognitive drain can lead to dissatisfaction, burnout, and even more debt.

The solution seems simple: Don’t push bad code.

However, the daily pressures of deadlines, the complexities of existing systems, and the need for quick fixes often make this a significant challenge. Consistently writing clear, maintainable code requires discipline, awareness, and the implementation of sound development practices.

The good, the bad, and the ugly code: What “good code” is and why it is important

What is considered “bad code”?

“Bad code” is a lot of things: Hardcoded secrets, overly complex functions, missing unit tests, unnecessary repetition, unclear documentation, etc. Go look at some of your earliest code — it’s probably not as good as the code you write now. At a high level, while some bad code takes longer than it should to understand, other forms of bad code might be simple to grasp but still exhibit issues like inefficiency, lack of maintainability, or poor design. Code that is harder to understand is more susceptible to bugs and vulnerabilities because its complexity makes it difficult for developers to correctly interpret its logic, leading to errors during modification, debugging, or when integrating with other parts of the system.

Similar to poorly written prose, if you find yourself having to stop and re-read a block of code more than a few times, it’s probably code that should be refactored. Difficulty in code comprehension isn’t just a minor inconvenience; bad code significantly complicates debugging — especially in the chaos of a 3 AM critical outage incident. That’s when things get really ugly.

So what is considered “good code”?

While one aspect of bad code can be its difficulty to read, defining it solely by this characteristic is an oversimplification. Good code, therefore, involves more than just being “easy to read”; it also encompasses factors like maintainability, efficiency, clarity of intent, and adherence to best practices. So what specific attributes contribute to this readability? Just as standards for good writing vary across genres, the characteristics of good code can differ based on programming languages, system architectures, and frameworks.

However, at a fundamental level, high quality code exhibits several key traits: it is maintainable, reliable, and secure. Now that we have a sense of what makes code easy to understand, change, operate, and debug, what are some best coding practices we can keep in mind to help guide our software development efforts?

Suggested best practices for code quality in any language

Never hardcode secrets

Hardcoding sensitive information or arbitrary values directly into your code is a significant source of technical debt and security risks. In October 2022, Toyota revealed that a hardcoded secret had been exposed in a public repo for nearly five years. The issue was remedied, but it would be naive to think that no breach of data had already occurred.

Example of a hardcoded secret:

    REPORTING_API_TOKEN = "A_HARDCODED_TOKEN_1234"

    def report_quality_gate_status(gate_status, check_type):    
        headers = {"Authorization": f"Bearer {REPORTING_API_TOKEN}"}
        data = {"status": gate_status, "check_type": check_type}
        try:
            requests.post("http://localhost:8081/api/status",
                          headers=headers,
                          json=data)
            print("Status reported successfully.")
        except requests.exceptions.RequestException as e:
            print(f"Error reporting status: {e}")

In the code above, a request is made to the http://localhost:8081/api/status endpoint. The request contains headers with authorization — a very familiar API pattern. Unfortunately, the token has been hardcoded, leaving this code vulnerable to a security breach.

Improved version without a hardcoded secret:

    def report_quality_gate_status(gate_status, check_type):
        """Reports the status to an external service."""
        # API token for reporting retrieved from environment.
        api_token = os.environ.get("REPORTING_API_TOKEN")  

        if not api_token:
            print("""Warning: REPORTING_API_TOKEN environment        
                  variable not set (reporting skipped).""")
            return
        headers = {"Authorization": f"Bearer {api_token}"}
        data = {"status": gate_status, "check_type": check_type}
        try:
            response = requests.post("http://localhost:8081/api/status",
                                    headers=headers, json=data)
            response.raise_for_status()  # Ensure successful request.
            print(f"""
                 Status '{gate_status}' for '{check_type}'
                 reported successfully.
                 """)
        except requests.exceptions.RequestException as e:
            print(f"Error reporting status: {e}")

In the improved version, the value for REPORTING_API_TOKEN is retrieved from the operating system environment and never exposed in the code.

💡 Click here to learn more about handling secrets.

Reduce redundancy by embracing the DRY principle

One of the core purposes of programming is to automate repetitive tasks, but that’s not the only reason to reduce redundancy. The more often a task is replicated throughout a system, the greater the vector of vulnerabilities. Redundancy is also harder to maintain.

Example of redundancy:

    class QualityGateCheck:
        def __init__(self, error_threshold, warning_threshold):
            self.error_threshold = error_threshold
            self.warning_threshold = warning_threshold
            self.status = "Pending" 
            self.check_type = "Combined Threshold Check" 

        def run_check(self, code_errors):
            self.status = "Pending"
            if code_errors >= self.error_threshold:
                self.status = "Failed: Exceeds error threshold"
                result = self.status
                return result
            elif code_errors > self.warning_threshold:
                self.status = "Passed with errors"
                output = self.status
                return output
            else:
                self.status = "Passed"
                final_status = self.status
                return final_status
            return final_status

        def get_status(self):
            current_status = self.status 
            return current_status

        def describe_check(self): 
            description = f"""
                          Checking for errors above 
                          {self.error_threshold}
                          and warnings above
                          {self.warning_threshold}.
                          """
            return description

The code above creates a class called QualityGateCheck initialized with thresholds for errors and warnings, a status, and what kind of check it is. The default status is Pending and the default check type is Combined Threshold Check. The class also contains three different functions: one to run the check, one to get the status of the check and one to describe the check.

The redundancy occurs in a few different places:

In run_check, status is again set to Pending — something that is handled already in the instantiation of the class.
In the same function, two unnecessary intermediate variables are created and returned: output and final_status.
As the function is currently written, the last return final_status will never be reached.
Similar unnecessary intermediate variables occur in the functions get_status and describe_check.

Improved version with reduced redundancy:

    class QualityGateCheck:
        def __init__(self, error_threshold, warning_threshold):
            self.error_threshold = error_threshold
            self.warning_threshold = warning_threshold  
            self.status = "Pending"
            self.check_type = "Code Error Threshold Check"

        def get_status(self):
            # Returns status without intermediate variable.
            return self.status

        def describe_check(self):
            # Returns description without intermediate variable.
            return f"""
                   Checking for errors above {self.error_threshold}
                   and warnings above {self.warning_threshold}.
                   """

        def process_code_errors(self, code_errors):
            # Unnecessary status setting and
            # intermediate variables removed.
            if code_errors >= self.error_threshold:
                return "Check failed: Exceeds error threshold"
            elif code_errors > self.warning_threshold:
                return "Check passed with errors"
            else:
                return "Check passed"
            # Unreachable return removed.

💡 How does this improved version further reduce redundancy in the conditional logic?

You can extend this concept to deeply nested functions, application configurations, integrated systems, and any other opportunity to DRY — Don’t Repeat Yourself. Strive to identify and eliminate duplication wherever possible.

Define, divide, and decouple responsibilities for maintainability

Speaking of deeply nested functions, the Single Responsibility Principle (SRP) advocates for reducing complexity where possible by narrowing down classes and modules to a single task. We can expand on this principle to include how we define, divide, and decouple services and applications and architecture, ultimately mitigating technical debt.

In April 2022, Atlassian experienced a 14 day outage while trying to delete data related to a deprecated legacy standalone application. In the incident, the API used to perform deletions of accepted IDs related to two entirely different entities, resulting in the removal of instances of the inactive app and active cloud sites using the application. Customers lost access to their Atlassian products (very likely including their backlogs of tech debt).

Decoupling the data deletion process for the legacy application from the active cloud sites could have prevented this significant disruption.

Example of a function with multiple responsibilities:

    def main_quality_check(errors):
        error_threshold = 10
        warning_threshold =  5
        gate = QualityGateCheck(error_threshold, warning_threshold)
        final_status = None

        if not errors:
            final_status = "No code errors provided"
        elif not isinstance(errors, int):
            final_status = "Invalid code errors"
        else:
            if errors >= gate.error_threshold:
                final_status = "Check failed: Exceeds error threshold"
            elif errors > gate.warning_threshold:
                final_status = "Check passed with errors"
            else:
                final_status = "Check passed"
            gate.status = final_status

            api_token = "A_HARDCODED_TOKEN_1234"
            if not api_token:
                print("""Warning: REPORTING_API_TOKEN
                     environment variable not 
                     set (reporting skipped).""")
            else:
                headers = {"Authorization": f"Bearer {api_token}"}
                data = {"status": gate.get_status(),
                       "check_type": gate.check_type,
                       "check_description": gate.describe_check()}
                try:
                    response = requests.post("http://localhost:8081/api/status",
                                            headers=headers, json=data)
                    print(f"""
                         Status '{gate.get_status()}' for '{gate.check_type}'
                         reported successfully.
                         """
                         )
                except requests.exceptions.RequestException as e:
                    print(f"Error reporting status: {e}")
        return final_status

There is a lot going on in the code above. Not only is the code validating whether or not errors is an integer, it is also determining the status of the quality gate check as well as posting the resulting gate check status to an endpoint. In other words, there are many different tasks happening in this function — it is overcomplicated, which makes it not only harder to read, but harder to test.

Improved version with separated responsibilities:

    # Handles just the operations pertaining to evaluating the code errors
    # against thresholds.
    class QualityGateCheck:
        def __init__(self, error_threshold, warning_threshold):
            self.error_threshold = error_threshold
            self.warning_threshold = warning_threshold
            self.status = "Pending"
            self.check_type = "Code Error Threshold Check"

        def get_status(self):
            return self.status

        def describe_check(self):
            return f"""
                   Checking for errors above {self.error_threshold} and warnings
                   above {self.warning_threshold}.
                   """

        def process_code_errors(self, code_errors):
            if code_errors >= self.error_threshold:
                return "Check failed: Exceeds error threshold"
            elif code_errors > self.warning_threshold:
                return "Check passed with errors"
            else:
                return "Check passed"

    # Handles just the operations pertaining to validating the value
    # of code errors and can be used elsewhere in the code.
    def validate_code_errors(code_errors):
        if not code_errors:
            return "No code errors provided"
        if not isinstance(code_errors, int):
            return "Invalid code errors: Expected an integer."
        return None

    # Handles just the operations pertaining to reporting the gate check status
    # and can be used elsewhere in the code.
    def report_quality_gate_status(gate_status, check_type, check_description):
        api_token = os.environ.get("REPORTING_API_TOKEN")
        if not api_token:
            print("""Warning: REPORTING_API_TOKEN environment variable not set
                 (reporting skipped).""")
            return
        headers = {"Authorization": f"Bearer {api_token}"}
        data = {"status": gate.get_status(),
                "check_type": gate.check_type,
                "check_description": gate.describe_check()}
        try:
            response = requests.post("http://localhost:8081/api/status",
                                    headers=headers, json=data)
            response.raise_for_status()
            print(f"""
                 Status '{gate_status}' for '{check_type}' reported successfully.
                 """)
        except requests.exceptions.RequestException as e:
            print(f"Error reporting status: {e}")

    # Ties everything together.
    def main_quality_check(errors):
        error_threshold = 10
        warning_threshold = 5
        gate = QualityGateCheck(error_threshold, warning_threshold)

        validation_result = validate_code_errors(errors)
        if validation_result:
            return validation_result

        final_status = gate.process_code_errors(errors)
        gate.status = final_status

        report_quality_gate_status(gate.get_status(),
                                   gate.check_type,
                                   gate.check_description())
        return gate.get_status()

In the improved version, the tasks of validating the value for errors, processing the errors, and then reporting the errors status have been broken into separate functions that are called in main_quality_check.

By dividing responsibilities, we define each task and decouple them from each other, resulting in code that is easier to read, easier to test, easier to maintain, and easier to extend.

Write effective code comments and documentation

Meaningful comments enhance code readability, but excessive or poorly written ones hinder it. The issue isn’t the length of necessary documentation, especially for public APIs and SDKs which often require multi-line explanations. Rather, a red flag for potential refactoring is when a small block of core logic needs significantly more comment lines to explain what it does than the code itself. In such instances, refactoring using best practices to create clearer, more self-explanatory code is preferable to relying on verbose comments to decipher complexity. Well-structured and clearly named code often minimizes the need for extensive explanatory comments on its basic operation.

Example of verbose comments:

    # The main function to orchestrate the quality check process.
    def main_quality_check(errors):
        error_threshold = 10
        warning_threshold = 5
        # Create an instance of the QualityGateCheck class with the configured
        # thresholds.
        gate = QualityGateCheck(error_threshold, warning_threshold)

        # Validate the input 'errors' using the validate_code_errors function.
        validation_result = validate_code_errors(errors)
        # If the validation returns an error message (not None),
        # return that message and stop further processing.
        if validation_result:
            return validation_result

        # If the input is valid, process the 'errors' using the
        # process_code_errors function to get the final status.
        final_status = process_code_errors(errors, 
                                           gate.error_threshold, 
                                           gate.warning_threshold)
        # Update the status of the QualityGateCheck instance
        # with the determined final status.
        gate.status = final_status

        # Report the final status using the report_quality_gate_status function, 
        # passing the gate's status and check type.
        report_quality_gate_status(gate.get_status(), 
                                   gate.check_type,
                                   gate.describe_check())
        # Finally, return the determined final status of the quality check.
        return gate.get_status()

Even at a glance, this code probably gives you a headache. The comments aren’t adding anything helpful.

Improved version with more useful comments:

    def main_quality_check(errors):
        """Orchestrates the quality check process."""

        error_threshold = 10
        warning_threshold = 5
       # Create a QualityGateCheck with the above values. 
       gate = QualityGateCheck(error_threshold_config, warning_threshold_config)

        validation_result = validate_code_errors(errors)
        if validation_result:
            return validation_result

        final_status = process_code_errors(errors,
                                           gate.error_threshold,
                                           gate.warning_threshold)
        gate.status = final_status # Update the gate’s status.

        # Post the status of the gate check and the type. 
        report_quality_gate_status(gate.get_status(), 
                                   gate.check_type,
                                   gate.describe_check())
        return gate.get_status()

This version makes use of docstrings and comments to help understand the code without detracting from the code.

💡 IDEs and other tools can utilize these docstrings for improved navigation, debugging, and API documentation generation.

Use comments judiciously to explain the why behind the code, not just the what. Meaningful names for variables and functions often reduce the need for extensive commenting. Additionally, leverage docstrings to document the purpose, arguments, and return values of functions and classes.

Maintain consistency and build a lasting code legacy

Regardless of the specific best practices you choose to implement, consistency is paramount. The easiest way to keep code consistent is to enforce a unified style throughout. There are different styles for different programming languages, and even within those coding guidelines there are variations. For instance, indenting with tabs versus spaces. Choose whatever style best suits your use case.

Maintaining a consistent code style streamlines the adoption of best practices across a project. This stylistic uniformity extends its benefits to several crucial areas:

Consistent unit test coverage: When code style is consistent, it becomes easier to establish and maintain uniform standards for unit testing. This includes consistent naming conventions for test cases, a consistent structure for test setup and teardown, and a predictable approach to mocking dependencies. This uniformity makes it simpler to identify areas lacking adequate test coverage and ensures that tests are written and executed in a standardized way, leading to more reliable and maintainable tests.
Consistent refactoring: A consistent code style facilitates safer and more efficient refactoring. When the codebase adheres to a predictable structure and set of conventions, developers can more easily understand the impact of changes and apply refactoring patterns consistently. For example, consistently named variables and methods, along with a uniform code layout, make it easier to identify and extract common logic, rename elements, or restructure code without introducing unintended side effects.
Consistent documentation: Consistency in code style naturally promotes consistency in documentation. When code follows a predictable structure and naming scheme, it becomes easier to establish conventions for inline comments, docstrings, and higher-level documentation. This includes a consistent tone, structure, and level of detail. Uniformity in documentation makes it easier for developers to find the information they need, understand the codebase, and contribute effectively.

Furthermore, a consistently styled codebase, coupled with the consistent application of best practices in testing, refactoring, and documentation, significantly eases the onboarding process for new team members. The predictable patterns and structures within the code and its related artifacts enable faster comprehension and integration into the development workflow.”

In essence, consistent code reflects a commitment to care, attention to detail, and future maintainability. Most software development is a collaborative endeavor, and someone else will likely need to read or modify your code in the future. By prioritizing consistency and writing high quality code, you contribute to a positive and sustainable code legacy. The choices you make in naming variables, refactoring functions, adding comments, and addressing technical debt shape this legacy.

What kind of legacy you leave is up to you.

From theory to practice: Best practices for implementing coding standards effectively

Now that you understand best practices for writing good code, how do you actually implement them?

Remember that best practices are guidelines that enable developers to do their best work collaboratively and efficiently; they are not meant to control anyone. They should inspire and empower you, not limit you.

Learn from others: Actively read code from reputable open-source projects to help you learn from other styles, perspectives, and use cases.
Leverage automation and shift left: Integrate tools for static code analysis, linters, and code reviews into your development workflow as early as possible (shifting left). These tools can automatically identify potential issues and enforce coding standards, minimizing the impact of bad code and freeing you up to think about more complex problems.
Cultivate curiosity and embrace exceptions: Understand the rationale behind coding style enforcements. Occasionally, there might be valid reasons to deviate from a standard, but these exceptions should be conscious and well-documented. The justification for a certain coding style enforcement may seem obvious to you, but can you explain why it’s so obvious? Occasionally refactoring our brains is just as essential as refactoring our code. Every now and then you might have to break your own rules.

Key takeaways: Building a foundation for sustainable software development

Avoiding technical debt is not just a matter of writing “good” code — it is a continuous commitment to clarity, maintainability, and collaboration. By embracing the best practices outlined in this article you can build more robust, scalable, and sustainable software systems.

Remember that the effort invested in writing good code today pays significant dividends in reduced maintenance costs, fewer outages, and a more productive and satisfied development team tomorrow.

Try it yourself: Tools and resources for enforcing code quality

Understanding these core best practices for writing good code helps lay the foundation for software development with minimal tech debt. As software applications and the technology that supports them become more and more powerful — and therefore more complex — enforcing best practices becomes even more critical.

When it comes to enforcing code quality at scale, tools like SonarQube integrate seamlessly with existing development pipelines.

Shifting code quality all the way left, SonarQube’s IDE plugin annotates your code as you write it with reasoning and remediation suggestions that ensure issues don’t even get committed. It’s free and you can get started with it right away.
Pull request analysis helps automate the more basic aspects of code reviews so you can focus on larger issues and catch security vulnerabilities before they’re merged to prod. Check out this repo for hands-on experience using SonarQube.
Quality gates and profiles mean that you set the standards you want to hold yourself to, adjusting and adapting as necessary.

💡 The code for the examples in this post can be found here.

The DevRel Digest February 2025: DevRel You Should Know for 2025

Liz Acosta — Fri, 28 Feb 2025 19:45:06 +0000

In November and December of 2023, I didn’t know what to write about for the DevRel Digest. When I find myself uncertain about what to do next, I turn to community for inspiration. Community is not only one of the core responsibilities of Developer Relations, it is also a value we practice amongst each other. In turning to my peers for inspiration, it became obvious what to write about: The community itself.

So I wrote about nine “DevRel you should know” for 2024 in two parts. With 2025 already underway and lots of major developments in the field and in tech at large, this next iteration of “DevRel you should know” feels more important than ever. In order to understand why I’ve decided on this particular evolution, I’ve provided the following context.

The Three of Cups is about a sense of community and can indicate that it's time to get more involved by helping.

A quick look back before a look at the future

AI anxiety

While AI and its most notable players have been in development for a while, it wasn’t until the December 2022 launch of ChatGPT that the technology became meaningfully accessible. By January 2023, the OpenAI-based chatbot had become one of the fastest-growing consumer software applications in history. At the same time, Developer Relations experienced significant downsizing and layoffs, prompting many to wonder if the practice of DevRel was in its final long-anticipated and much-written-about death throes.

While the breadth and ambiguity of DevRel elude explicit success metrics and definitive business value, DevRel’s lack of uniformity and standardization might also be the key to its adaptability and resilience. Combined with a diversity of practitioners from typically unconventional paths to tech and its roots in community, Developer Relations might be the best equipped to survive tech’s ever-shifting landscape.

With the anxiety of AI, our role as advocates for developers might become more significant than ever.

Content, clarity, and company-specific needs

Content remains one of the most effective methods of reaching developers. With mainstream search engines becoming more and more polluted with ads and low-quality, inaccurate AI-generated content, the art of technical writing is critical to a product’s success. The point of content for developers should be to make the developer’s life easier – whether that’s presenting a novel solution to the problem they are working on or providing clear documentation and quickstart tutorials to get them up and running with as little friction as possible. Bad content dilutes brands; good content builds trust. Being able to discern quality in content will always be part of a successful DevRel program.

High quality content requires clarity not only in its presentation, but in its objectives as well. These goals are where DevRel can collaborate with company organizations that may seem at odds with the empathy and authenticity of a developer audience. With the layoffs of 2023 and the lethargy of the job market in 2024, DevRel had to reconcile with “aligning with the enemy” (AKA marketing and sales) in order to evolve. But this doesn’t have to be a compromise. Understanding a specific persona’s marketing funnel can help Developer Advocates gain insight into what kind of efforts to focus on for brand awareness; insight into what actually closes a deal can help a Developer Relations program refine its messaging. In both cases, there is an opportunity to see what success looks like and how to measure it.

Perhaps one of the silver linings of the “death of DevRel” is its renaissance, in which both companies and DevRel practitioners are asking themselves, “Does Developer Relations make sense for this company at this time? What does the company need and how can a DevRel program meet that need?” DevRel has been making a comeback, this time with a lot more discernment. The State of DevRel Report for 2024 reflects this, with respondents reporting more hiring than in the previous year; however, there was also an increase in expectations for head counts to decrease as company reorganizations became more prevalent than in previous surveys.

In other words, DevRel was still volatile in 2024 as companies figured out how best to reach developers.

With this in mind, how should we think about Developer Relations in 2025? To answer this question, I sought out the wisdom and experience of two prominent members of the community who have gone above and beyond to help raise us all up. They kindly donated their time to me for this post, offering perspectives and insights that will resonate with many working in tech right now.

DevRel you should know: Wesley Faulkner and Erin Mikail Staples

Wesley Faulkner worked in hardware and marketing before finding his “home” in DevRel.

Wesley Faulkner is one of the most visible and active members of the DevRel community. A self-described “technology nerd,” Wesley started his career as a hardware technician for Dell, receiving annual promotions and steadily leveling up from tech support for desktops to tech support for government and education, finally moving over to servers and storage before leaving the company. It was easy to be successful because he was good at what he did, but there was a yearning for something else. “A lot of the movements that I made were usually out of frustration,” he tells me. Those movements would end up including social media management, marketing, community, and moderation at a variety of companies.

From the outside, such a career path may seem a little unconventional, but for Wesley, it led him right to where he needed to be. “It was a friend of mine who knew of my background – knew my technical background, my marketing background – that said, ‘Hey, we're doing this thing called DevRel, would you be interested?’ I interviewed and I got the job,” Wesley says, summarizing it as “an evolution of everything I had done beforehand.” But it wasn’t until his attendance to DevRelCon in 2019 that Wesley realized he had found his calling. “I was like, ‘I'm home,’” he says.

“Luckily that was generally the start of the Golden Age of DevRel where salaries went up, demand went up, and I felt like I had more agency, more control.”

Echoing a sentiment many of us are feeling right now, he adds, “Things don’t feel that way now.”

Erin Mikail Staples initially wanted to work in politics and journalism, but after gaining some technical experience, found herself in DevRel.

Erin Mikail Staples shares a similar career journey. Erin started with aspirations to work in politics. “My first internships were all in nonprofit and policy and court reporting and not techy things,” she tells me, and like Wesley, she experienced restlessness. “I naturally got really annoyed with the news industry.”

She decided to pursue something more creative. She started working at an agency with an interest in advertising. While she was there, she found herself working in the Shopify ecosystem and her natural curiosity led her to peel back the layers to the code underneath. “I was the person in my friend group that did the MySpace, LiveJournal, and Tumblr templates,” she says – an experience I think a lot of us of a certain generation can relate to.

Voicing another sentiment that resonates deeply with me, she adds, “Bring sparkle gifs back to the internet please.”

Erin next worked a little in progressive tech and then went to grad school to study the impacts of machine learning and algorithms. It was there that she attended a talk from a speaker about the Cambridge Analytica scandal and experienced a deep sense of disillusionment. Her adviser convinced her to not drop out of the program, offering her this reframe: “If you can't take down the system then how do you empower the individual?”

From there, Erin’s curiosity and sense of community led her to a COVID-inspired “weird viral moment” in which she was named a “virtual mall CEO.” That’s how she ended up as a head of an open source community and upleveling her technical chops. It was only natural for her next step to be developer relations at Orbit.

“Chaos,” is how she initially describes her career to me. Chaos is exactly the kind of qualification you need to succeed in a role that varies so greatly from company to company.

Neurodivergence and the best and worst of DevRel

22% of DevRel practitioners identify as neurodivergent, mirroring the 10-20% of the global population considered to be of the same identity. This suggests that DevRel is particularly suited for neurodivergent people and that DevRel is one of the more inclusive roles in tech. Which makes sense given the breadth of what DevRel includes.

From the State of DevRel Report for 2024

Both Wesley and Erin identify as neurodivergent; Wesley has dyslexia and ADHD and Erin has OCD and ADHD. As someone diagnosed with ADHD myself, I recognized the many experiences we have in common.

“I was very impulsive,” says Erin of her experience in school, “I would get up and walk around in the class. But I had learned that teachers wouldn't get me in trouble if I got good grades … so I would speedrun through my work and then wander the halls.”

There can be many professional challenges to being neurodivergent. Wesley says, “They don't fully understand how I knew the dominoes were going to fall that way because I set them up that way,” adding that his unconventional approach is often questioned. “They say, ‘Well, why are you putting that there or why are you doing that or why are you doing this?’ They may not understand, but to me it's clear.”

“And that's the restrictions that I fall under time and time again.”

When I ask Wesley if he feels that his neurodivergence has helped or hindered his work in Developer Relations, he simply says, “Yes.”

Similarly, Wesley names “the ambiguity” as both the best and worst parts of DevRel. “This is a two-sided coin,” he explains. When it comes to DevRel, “there is a lot that's not known and there's a lot that's not settled. I love being able to explore those areas where there is a potential to make change, to set a course and to make impact without being criticized about how I did something but rather that I did it … I like making order out of chaos.”

Erin says the worst parts of DevRel are when “people perceive you as less of an engineer … I hate feeling like I have to prove my worth to have a seat at the table.” She adds, “There's this whole notion of going deep versus going wide in education. And I think in DevRel, you have to go very wide.”

“And that doesn't mean we can't keep pace with someone going deep, but I think in DevRel you have to be a number one super user of your product” because ultimately, as a VP of engineering told Erin, “I don't think any of these developers at this company could give a live product demo tomorrow.” But Erin could.

Which is where she finds context switching and pattern matching – two typical traits of neurodivergence – useful.

Wesley credits his way of thinking for his success in DevRel, saying, “In order for me to make things make sense in my mind, I really fall back on first principles thinking – understanding the basics and then building up from there … I just follow where the data takes me and what makes sense from the feedback that I'm getting. Which means I constantly rejigger or re-tweak based on what I'm hearing, what I'm getting.”

This sort of “systems thinking” is what helps Wesley ask the right questions. “If someone's telling me, ‘Hey, let's do a blog series,’ I say, ‘Well, are there going to be ads? How are we promoting it?’ All the pieces,” he says, adding, “I'm able to try to get everything in – sequenced and in pieces so that it makes sense. So that I know that when I step out with my left foot, there is something for me to step on. And when I step out there with my right foot, there's also something for me to step on.”

This kind of thinking is useful in other ways. Erin says she feels like she is in “a much more problem solving role [in DevRel] where I'm influencing products and I'm influencing how we communicate and I'm influencing how we talk to people – which is a very cool thing … It's very creative. I get to learn a ton of new things – which is so much fun.”

What to focus on for DevRel in 2025

I asked Wesley and Erin for their advice on what DevRel should focus on in 2025.

This is what Wesley has to say:

“I think to each their own. We have different focuses. This is the thing that I would say that I lean into. I focus on problems and then try to focus on solutions.”

“DevRel has not talked about the definition [of DevRel] and how it's being owned by other people who aren't necessarily DevRel practitioners. So that's why I joined the steering committee of the DevRelFoundation to help with fixing that problem.”

“I hate the way companies operate and how they treat people. I'm writing a book, creating a brand new work structure that doesn't even exist yet to fix this. I'd say that if people want to follow what I'm focusing on, it’s to think bold and go ahead and take on the big things that you think will withstand the test of time. Then leave your artifacts to show that there's another way.”

“Even if you don't think that it's going to be successful, let people draw upon your work, draw upon your energy. If it's not [the right solution] now, then make sure that the people in the future have what they need to to have the evidence that other people believe that this is the right thing to do.”

In other words, trust your intuition, test your hypothesis, and document everything just in case it happens to be the foundation that someone else can use to complete a vision for a better way.

Erin offers some practical advice for “a better way”:

“Get good at products and understand business models … Having done my research on independent business models I can tell you that every time I've been laid off, I have predicted it. This is because you learn about what starts happening. And so you understand how your company makes business and what percentage of your company gets from different inputs and outputs.”

“Understand the business model and then also understand the product. One of my professors did educational design for Apple. He taught a class on UX for education and accessibility and he made us use screen readers. We would go into class with our laptops and he’d be like, ‘Great, turn your screen off and use a screen reader with headphones.’” We used different adaptive technologies to understand that 1) Not everything can be universal so 2) How do you maximize that and what are the product decisions that go into fueling these types of things?”

She adds, “And don't be scared of talking to sales!”

In summary, understanding business models and user experience can go a long way in not only serving developers, but in serving yourself and your value at a company – and sales can be your greatest ally in understanding the business model.

Combatting uncertainty with community

I found myself searching for a job (again!) at the end of 2024 and into the beginning of 2025. The world of tech is much different now and it feels like there is a lot more at stake. When I wrote about “the return of DevRel,” I felt hopeful and optimistic about this work. Now I am not as confident and I need community more than ever. I know I am not the only one.

To this point, Wesley shares a little inspiration. He says his love of technology was inspired by the vision he saw in Star Trek, saying, “Like a lot of sci-fi addicts, what I loved about Star Trek is not just the future [it presents], but this kind of evolution of humanity into this good space … And I wanted to be part of that evolution, both with technology and this kind of racial and gender dynamic in which there was harmony.”

He sees that evolution and harmony in DevRel – a group of people from diverse backgrounds and experiences who love technology and want to share that love with others. Reflecting on his experience at DevRelCon in London in 2023, Wesley says, “It felt like it didn’t matter what team we're representing, it didn't matter what company we worked for, it still felt as if we were all connected. People change jobs all the time, but we all felt like we still could come home to each other.”

Wesley also admits to feeling disillusioned. He says, “If you do the right thing, if you're a very moral, ethical person, that doesn't mean that you'll win in the end. That's not something I would like to be true, but it doesn't bear out to be true.” What has prevented him from losing all faith is community.

Not surprisingly, both Wesley and Erin are members of many different communities. Erin finds her sense of belonging from places like the NY comedy scene, online fandoms, the subreddit for her neighborhood that she moderates, the dog park she regularly visits with her pup, Q, and even former teammates from her time as a swimmer in college that she’s maintained contact with. For Wesley, his communities include his friends and family, his neighbors, the various DevRel-related online networks on Discord, LinkedIn, and Slack, the listeners of his podcasts Radical Respect and Community Pulse, and even the temporary communities he experiences when giving talks and connecting with audiences.

Wesley talks about the “reinforcement” of community he feels whenever he learns someone has found his work or his voice valuable. “That's kind of my love language. And as long as I feel I can still [provide value], it makes me feel good.” In other words, knowing that he’s made some positive contribution to the world – big or small – is what continues to motivate Wesley.

At DevRelCon, he gave out challenge coins that on one side read, “Integrity, resilience, accountability, perseverance, community” and “Community of leaders and community of learners” on the other.

Wesley says, “These are the principles that I try to live by when I talk about DevRel.”

One of the challenge coins Wesley gave out at DevRelCon.

You can learn more about Wesley Faulkner on his website.

You can learn more about Erin Mikail Staples on her website, as well as on LinkedIn, Bluesky, and Instagram. She currently works as a Senior Developer Experience Engineer for Galileo, a platform for enterprise gen-AI evaluation and observability.

Many thanks to Wesley and Erin for their generous contributions to this post. If you enjoyed this post, please consider buying me a coffee.

Events and resources and other notable things

Check out the new DeveloperRelations.com website and leave your feedback here.
Love this LinkedIn post on testing.
Check out this upcoming Write the Docs meetup in San Francisco on March 19th.
Need help understanding agentic RAG, one of the newest developments in the AI space? Look no further than this blog post I wrote for Vellum AI, where I try to break it down into accessible language.

Harder, Better, Faster, Stronger Tests With Fixtures

Liz Acosta — Tue, 31 Dec 2024 23:39:47 +0000

Okay so I really just wanted to reference Daft Punk. With their December 2024 limited re-release of Discovery and screening of Interstella 5555, the French electronic duo have been on my mind. Of course it has made me nostalgic and a little bit sad, yearning for days that seemed simpler.

It is not easy to be unemployed and depressed during the holidays, so guess what? Here’s a tutorial for you to round out what was probably the worst year of my life! (Including the year I was diagnosed with cancer!)

But real talk: Test fixtures can improve your tests by reducing redundancy, isolating scenarios, and increasing performance.

How to use this tutorial

This tutorial is designed to accommodate many different learning styles so you can choose your own adventure:

Jump straight to the code: The code for this tutorial can be found here. Use the README to get it up and running locally.
But first, who cares about testing?: I’ll try to convince you why writing tests can be fun and list some best practices to keep in mind.
What are test fixtures?: An introduction to test fixtures in unittest and how they can help you adhere to unit testing best practices.
A little bit of context: If you’re the kind of person who likes to ask a lot of questions or who finds comfort in expectation-setting, I got you, my sweet little anxious overachiever! This section aims to help set you up for success.
Test fixtures in action: A walk-through of the tutorial code in which we’ll explore the effects of using different kinds of test fixtures so you can experience that “Aha!” moment first-hand.

But first, who cares about testing? Can’t AI do it?

First of all, I care about testing.

Second of all, yes … but unless you are a sadist who enjoys incident pages at three in the morning trying to debug code a robot wrote, you should probably at least check the robot’s work. (And – you know – no shame if that is your thing.)

You can read my previous posts in this series to learn more about why testing is important, but in summary:

Besides the qualitative benefits of software testing such as bug prevention, reduction in development costs, and improved performance, the most compelling benefit of writing tests is it makes us better engineers. Writing tests forces us to ask ourselves, “What exactly is the expected behavior of this method or application?” When software becomes “difficult to test,” it is usually a good indicator of code smells and an opportunity to refactor a method or reconsider the entire design of a system.
A less obvious but still important benefit to writing tests – unit tests especially – is their double duty as quick documentation. Best practices for unit tests call for long, descriptive function names. These function names not only make verbose test output more readable and quick to assess, they also provide documentation for the function under test.
Writing tests can be fun. Yeah, you read that correctly. A well-constructed test suite can be just as satisfying a problem to solve as the application code itself. And that feeling when all your tests pass? Or when your tests assist in a smooth refactor or feature implementation? It feels good. Tests can be a quick dopamine win in a profession that can be fraught with midnight debugging sessions and bouts of imposter syndrome.

Unit testing best practices

Now that I’ve successfully convinced you of the benefits of writing tests and you are now sufficiently stoked, here are some unit test best practices to keep in mind.

A good unit test should be:

One specific assertion at a time
Independent, isolated, and controlled
Relevant and meaningful
Repeatable and deterministic
Automatic
Descriptive

The tarot card for Judgement seems appropriate for software testing, so here is senior pug Gary Photoshopped poorly as an angel -- naturally.

What are test fixtures?

“In the context of software, a test fixture (also called "test context") is used to set up the system state and input data needed for test execution.” The purpose of a test fixture is to establish the environment in which the test(s) will be run. Test fixtures can help tests adhere to our unit testing best practices by controlling for variables like databases and data sets, system state, operating system, specific files, and mocks.

Specifically, in Python’s unittest framework, test fixtures are functions or methods that are executed before or after a test or group of tests to establish a testing environment.

Class and method-level test fixtures

Class and method-level fixtures are provided by a TestCase instance and are part of the group of methods concerned with running tests.

Class-level test fixtures are methods that are executed either before and/or after all of the test methods in a TestCase instance. They look like this:


@classmethod
def setUpClass(cls):
    print("Class-level setup test fixture has been executed!")

@classmethod
def tearDownClass(cls):
    print("Class-level tear down test fixture has been executed!")

An example implementation might look like this:


import unittest

class ExampleTestCaseClassTestFixtures(unittest.TestCase):

    @classmethod
    def setUpClass(cls):
        print("Class-level setup test fixture has been executed!")

    @classmethod
    def tearDownClass(cls):
        print("Class-level teardown test fixture has been executed!")

    def test_example_equal(self):
        self.assertEqual(1 + 1, 2)

    def test_example_not_equal(self):
        self.assertNotEqual(1 + 1, 3)

If you were to run the above tests, the output you would get might look something like this:

Class-level setup test fixture has been executed!

test_example_equal (tests.test_example.ExampleTestCaseClassTestFixtures.test_example_equal) ... ok

test_example_not_equal (tests.test_example.ExampleTestCaseClassTestFixtures.test_example_not_equal) ... ok

Class-level teardown test fixture has been executed!

----------------------------------------------------------------------

Ran 2 tests in 0.000s

OK

💡 This example is provided in the repo and as long as you are on the fixtures-tutorial branch you can run it from the root directory with: python -m unittest tests.examples.test_test_case_fixtures_example.ExampleTestCaseClassTestFixtures -v

Method-level test fixtures are methods that are executed either before and/or after each test method in a TestCase instance. They look like this:

    def setUp(self):
        print("Method-level setup test fixture has been executed!")

    def tearDown(self):
        print("Method-level teardown test fixture has been executed!")

An example implementation might look like this:

class ExampleTestCaseMethodTestFixtures(unittest.TestCase):
    def setUp(self):
        print("Method-level setup test fixture has been executed!")

    def tearDown(self):
        print("Method-level teardown test fixture has been executed!")

    def test_example_equal(self):
        self.assertEqual(1 + 1, 2)

    def test_example_not_equal(self):
        self.assertNotEqual(1 + 1, 3)

If you were to run the above tests, the output you would get might look something like this:

test_example_equal (tests.test_example.ExampleTestCaseMethodTestFixtures.test_example_equal) ... Method-level setup test fixture has been executed!

Method-level teardown test fixture has been executed!

ok

test_example_not_equal (tests.test_example.ExampleTestCaseMethodTestFixtures.test_example_not_equal) ... Method-level setup test fixture has been executed!

Method-level teardown test fixture has been executed!

ok

----------------------------------------------------------------------

Ran 2 tests in 0.000s

OK

Notice how in this output the setup and teardown messages are repeated twice – once for each of the two test methods in the test case.

Module-level test fixtures

Module-level test fixtures are functions that are executed before and/or after all the tests in a module are run. These fixtures are typically used for setting up and tearing down resources that are shared across multiple tests within a module. They look like this:

def setUpModule():
    print("Module-level setup test fixture has been executed!")

def tearDownModule():
    print("Module-level teardown test fixture has been executed!")

An example implementation might look like this:

import unittest

def setUpModule():
    print("Module-level setup test fixture has been executed!")

def tearDownModule():
    print("Module-level teardown test fixture has been executed!")

class ExampleTestCaseSecond(unittest.TestCase):

    def test_example_equal(self):
        self.assertEqual(1 + 1, 2)

    def test_example_not_equal(self):
        self.assertNotEqual(1 + 1, 3)

class ExampleTestCaseFirst(unittest.TestCase):

    def test_example_equal(self):
        self.assertEqual(1 + 1, 2)

    def test_example_not_equal(self):
        self.assertNotEqual(1 + 1, 3)

If you were to run the above tests, the output you would get might look something like this:

Module-level setup test fixture has been executed!

test_example_equal (tests.examples.test_module_fixtures_example.ExampleTestCaseFirst.test_example_equal) ... ok

test_example_not_equal (tests.examples.test_module_fixtures_example.ExampleTestCaseFirst.test_example_not_equal) ... ok

test_example_equal (tests.examples.test_module_fixtures_example.ExampleTestCaseSecond.test_example_equal) ... ok

test_example_not_equal (tests.examples.test_module_fixtures_example.ExampleTestCaseSecond.test_example_not_equal) ... ok

Module-level teardown test fixture has been executed!

----------------------------------------------------------------------

Ran 4 tests in 0.000s

OK

I’m sure you’ve already noticed how this output differs from the prior two examples because you’re smart like that!

Now that you’ve got a basic understanding of test fixtures, read on to see them in action.

To read more about test fixtures in unittest, refer to the documentation here.

A little bit of context

You can find the code for this tutorial in this repo on the fixtures-tutorial branch.

Build-a-Pug is a Flask app that makes a call to an OpenAI endpoint to generate an image of a pug based on a prompt constructed from user provided input. For this iteration of Build-a-Pug, I’ve added a SQLite database to store the pugs that are built which can be retrieved via the See Your Grumble page (Because that is what a group of pugs is called – a “grumble”!).

SQLite is an embedded SQL database engine. Unlike most other SQL databases, SQLite does not have a separate server process, and it reads and writes directly to ordinary disk files. For the sake of this tutorial, you do not need to concern yourself too much with the inner workings of SQLite. All you need to know is that initializing the database requires an extra explicit step and that the database manifests as a single .sqlite file.

Caveats and troubleshooting

Because OpenAI provides access to generated images for a limited duration, depending on when you view your grumble, some images may return an invalid signature authentication error which will appear as broken images. This is because the images are not being saved anywhere and implementing that functionality felt out of scope for this particular tutorial.

To fix this, you can delete the database and initialize a new one. This will, however, mean all your pugs will be permanently lost.

Please don’t deploy this app to production anywhere

This app was initially created as a toy demo app. As I’ve iterated on it, it’s become clear that it needs to be refactored. Obviously it isn’t intended for production, nor is it a good example of how to properly implement a database, however it does successfully demonstrate how and why test fixtures are useful – especially when you start adding complexity (like databases). Use this app as a learning resource and who knows? Maybe I’ll do a tutorial on refactoring!

How to use the test code

The most successful learning happens when you achieve that “Aha!” experience. I liken it to a magic trick: It’s the moment of wonder and delight when your brain is not only pleasantly surprised, but intrigued. It invites playful curiosity. To try to recreate that experience, I have commented out sections of the test code for you to later uncomment and run so you can see for yourself how different test fixtures impact the test results.

Test fixtures in action

Build-a-Pug is a Flask app that makes a call to an OpenAI endpoint to generate an image of a pug based on a prompt constructed from user provided input. For this iteration of Build-a-Pug, I’ve added a SQLite database to store the pugs that are built which can be retrieved via the See Your Grumble page (Because that is what a group of pugs is called – a “grumble”!).

Prerequisites

pipenv: pip install pipenv --user
OpenAI API key and organization
Python 3+

Setup

Clone the repo: git clone https://github.com/liz-acosta/testing-strategies-for-python.git
Change directory to the project
Check out the fixtures-tutorial branch: git checkout fixtures-tutorial
Install dependencies from Pipfile.lock: pipenv install
Add environment variables by renaming .env_template to .env ...
... and replacing placeholder secrets with real secrets
Initialize the SQLite database: pipenv run init-db
Optional: Delete the database: pipenv run delete-db

Run the app locally

While you don’t need to run the app for the tutorial, it could be helpful to understand the tests.

There are some caveats to this app, see the Caveats and troubleshooting section to learn more.

To run the app locally: pipenv run start-app
Navigate to http://localhost:5000/ in your browser

You should get something that looks like this:

From here, you can build your own pug:

Learn more about pugs:

Or check out your grumble:

Run the tests

Run the tests with method-level test fixtures

The tests we are interested in are located in tests/unit/test_pug.py – and in particular, we want to take a look at the tests that pertain to the database operations.

Locate the test case called TestPugDBWithMethodLevelFixtures and take a look at what the code is doing:


# A method-level test fixture that
# creates and inserts data into a sqlite database before each test in this class
def setUp(self):
    """Create a test database before each test method in this class"""

    self.connection = sqlite3.connect(TEST_DATABASE_FILEPATH)
    self.connection.row_factory = sqlite3.Row

    test_pug_lily = Pug("Lily", "6", "San Francisco", "4:00 PM")
    test_pug_lily.description = "Lily is the best pug"
    test_pug_lily.image = "lily_pug.jpg"

    test_pug_fiona = Pug("Fiona", "2", "San Francisco", "4:00 PM")
    test_pug_fiona.description = "Fiona is the best pug"    
    test_pug_fiona.image = "sweet_fiona.jpg"
    test_pugs = [test_pug_lily, test_pug_fiona]

    with open("build_a_pug/schema.sql", "r") as f:
        self.connection.executescript(f.read())

    query = "INSERT INTO pug (name, age, home, puppy_dinner, description, image) VALUES (?, ?, ?, ?, ?, ?)"

    for pug in test_pugs:
        self.connection.cursor().execute(query, (pug.name, pug.age, 
        pug.home, pug.puppy_dinner, pug.description, pug.image,),)

        self.connection.commit()

    print(Fore.GREEN + f"Test database: {TEST_DATABASE_FILEPATH} connection created and test data inserted")

# A method-level test fixture that
# closes and deletes the previously created sqlite database after each test in this class
def tearDown(self):
    """Close and delete the test database after  each test method in this class"""

    self.connection.close()
    os.remove(TEST_DATABASE_FILEPATH)

    print(Fore.RED + f"Test database: {TEST_DATABASE_FILEPATH} connection closed and deleted")

This code uses method-level test fixtures to:

Create a SQLite database connection, create a table in the database, create a couple of instances of the class Pug, and insert them into the database
Close the database connection and delete the database

💡 There is a lot of SQLite/database boilerplate here you do not need to worry about – just focus on the setUp and tearDown methods and how they impact the tests.

For your convenience, I have color-coded the printed output of the test fixture methods.

Run the tests with: pipenv run pug-unit-tests

If everything went as planned, all the tests should pass and you should see the setup and teardown printed output for each test method run.

Run the tests with class-level test fixtures

Now let’s see what happens when we use class level fixtures.

Comment out the whole TestPugDBWithMethodLevelFixtures class
Uncomment the class TestPugDBWithClassLevelFixtures.
Run the tests: pipenv run pug-unit-tests

Did you get this test failure?: AssertionError: 3 != 2

Since the database was created and torn down before and after all the test methods were executed, the pug we added in the test_create_pug test is still in the database and therefore affects the results of the test_get_grumble test.

You probably also noticed that the green and red printed output appeared only once.

Run the tests with module-level test fixtures

Bear with me because this one gets a little tricky.

Comment out the whole TestPugDBWithClassLevelFixtures class
Uncomment the class TestPugDBWithModuleLevelFixtures
Toward the top of the file, uncomment the functions setUpModule and tearDownModule
Run the tests: pipenv run pug-unit-tests

This time we get the same assertion error.

Similarly, the green and red printed output appear only once, but instead of wrapping a particular test case class, they bookend the entire module.

In conclusion

I hope that this tutorial demonstrated how test fixtures can help further refine your tests by enforcing best practices like isolating test cases, controlling variables, and improving performance.

In this particular example, a test database allows us to leave our real database unharmed. While we could set up this test database at the top of our test module, such a potentially draining resource may not be necessary for all of our tests and it could affect test results in unintended ways. We also have the option of setting up our test database at the class level, but as we witnessed, this means the test methods within that test case are reliant on each other and no longer independent.

As our tests are currently written, method-level fixtures seem to serve us best. However, this can change as our test needs evolve, forcing us to truly internalize what the code under test is really intended to do.

Testing, like life, is full of challenges, but it’s also filled with opportunities for growth, clarity, and even a little fun. By embracing tools like test fixtures, we can reduce chaos and gain confidence in the code we write – something that feels especially meaningful during times when we might just need a little dopamine hit to stave off the imposter syndrome. Whether you’re debugging at midnight or just trying to make it through the day, remember that every small step forward counts.

Have you been using test fixtures? How have they helped or hindered your tests?

If you enjoyed this tutorial, please consider buying me a coffee.

More resources on test fixtures

The DevRel Digest November 2024: If You Content It, They Will Come

Liz Acosta — Mon, 02 Dec 2024 21:34:39 +0000

Content for a dream DevRel content program

According to the 2024 State of DevRel report, “content marketing remains the most effective tactic for outreach to new developers.” From marketing to education, content development remains the top responsibility of DevRel practitioners from IC to C-level. In other words, you can’t have DevRel without content.

Image via The State of DevRel Report 2024

So what would my dream DevRel content program look like?

At a high level, when it comes to Developer Relations, content is any information provided by a company or brand that is intended for developers. So this includes blog posts, tutorials, documentation, webinars, and conference talks. Content accompanies a developer at every step of their journey from product awareness and evaluation, education and implementation, and product champion.

Whether it’s a blog post, a white paper, or a talk for a meetup, content for developers should follow the Triple A’s:

Authenticity: Developer audiences are famously allergic to bullshit – which is why they are my favorite group of people to create content for.
Accuracy: Outdated docs and broken tutorials are not only huge turn-offs for developers, they make the work of developers harder than it needs to be.
“Aha!”: There is no experience more powerful than the moment a developer fully internalizes the value of something. The more hands-on the “Aha!” moment is, the better it is, generating a powerful neural connection between a solution or a concept and the triumphant dopamine hit of success – a connection that is especially important for developers. Content should always offer an opportunity for this.

One of the best ways to help determine if a piece of content is following the Triple A’s is to actually take the time to do your Ideal Customer Profile (ICP) homework. The more thorough and researched your ICPs are, the more precise your content can be, ensuring that content is not being produced in vain. Check out this developer ICP framework from Tessa Kriesel to help you get the most out of the exercise.

My dream DevRel content program can be divided into three primary categories that sync up with the developer on their hero’s journey:

Awareness and evaluation
Education, onboarding, implementation
Champion content

The call to adventure: Content for awareness and evaluation

The hero’s journey of the developer and the role of developer relations.

This is the content that invites the developer to learn more by piquing their curiosity. This category of content should focus less on the product (henceforth referred to as the “solution”) and more on addressing specific use cases, problem spaces, and technologies – especially emergent ones. The point is to reach developers by empathizing with the particular obstacles they are facing and offering them assistance overcoming them.

Content in this category should be more general and SEO-forward, answering the questions commonly asked by developers. Content in this category could include the following:

Written content
- SEO-forward blog posts that answer general questions related to your solution. For instance, if your solution is an open source vector database, a blog post topic could be the differences between nearest neighbor search (NNS), approximate nearest neighbor search (ANNS), and semantic search.
- Tutorials and recipes that focus on learning about a particular tech rather than the solution itself. For instance, “How to build a movie recommendation app without the complexities of vector databases.”
- Introductory documentation that is not gated and emphasizes how easy it is to get started with the solution.
Video content
- SEO-forward “edutainment” that provides useful information in bite-sized videos that are fun to watch. The smart DevRel content producer will repurpose the aforementioned example blog post about search methods for vector databases into an edutainment script, breaking down each method into a 1-minute video.
- SEO-forward webinars that focus on solution related but still more general topics. For instance, a webinar that walks through the creation of a vector database – and just so happens to use the solution to do so!
Conference/in-person content
- Talks – especially shorter talk slots like lightning talks. And while your solution should not be in the title of the talk, you should definitely offer swag to those who attend!
Important metrics and outcomes of awareness and evaluation content
- Views and engagement with an emphasis on engagement (especially saving and/or sharing) and follow through on calls to action. (What did they click next and is it where you wanted them to go?)
- Lead generation segmented into first time users and established users (but don’t gate on work emails).
- Trial sign-ups … and for the love of all that’s good in the world, please provide some sort of self-service free or limited trial and if that’s not possible, please really consider if your solution is ready for a DevRel content program.

Descent into the unknown: Content for education, onboarding, and implementation

Whether a solution is adopted by a company via developer recommendation or handed down by a CTO, education, onboarding, and implementation is where the hero’s journey into the unknown can become fraught. The content provided for developers at this stage should be supportive, accessible, applicable, and as frictionless as possible. While the decision to use the solution has already been made, the marketing isn’t over yet. This is an opportunity to win over lifelong solution champions.

Content in this category should be very specific, organized, and easily searchable, allowing developers to skip, review, or bookmark as needed. It should be streamlined, lightweight, and copy-pasteable. Content in this category could include the following:

Written content
- White papers that emphasize customer success stories, quantifiable outcomes, and implementation solutions that are as detailed as company intellectual property policies will allow.
- Documentation for advanced use cases, concepts, features, and troubleshooting.
- Onboarding guides and tutorials focusing on typical integration cases and specific tech components that provide architecture diagrams and sample code wherever possible – anything that makes it easier for developers to add the solution to their existing tech.
Video content
- Webinars that explain and demonstrate more advanced concepts and features and provide examples of where these concepts and features can be implemented.
- Longer, more detailed education on-demand videos that cover solution topics in-depth. The developers who gravitate toward this kind of content are good candidates for future champions.
Conference/in-person content
- Workshops are an especially good format for more advanced use cases and features because attendees can troubleshoot directly with solution advocates.
- Co-located and/or unofficial meetups and office hours provide a venue for users of your solution to get facetime with you and each other. This can also be an extremely valuable opportunity to get honest solution feedback as well as identify potential champions.
Important metrics and outcomes of awareness and evaluation content
- Views and engagement with even more emphasis on what is being shared and by whom.
- Documentary discovery flow to evaluate whether or not you have your information organized in a way that is intuitive and frictionless.
- Changes in frequently asked questions and issues can help determine if you need to address something better in your content or if your content is alleviating points of friction or if you need to reconsider something in the solution all together.
- Leads – with an emphasis on identifying who has shown up more than once.
- Community activity that indicates investment in the solution such as users responding to other users.

Returning with the boon: Content created by champions

The best possible outcome of a DevRel content program is content created by users. By this time, the developer has heeded the call to adventure, descended into the unknown, and returned as a champion with a boon to share with other developers. A good DevRel content program inspires, enables, and empowers users to create their own content and share it – which is the most powerful testament to the power of your solution that you could ever ask for.

A champions content program is a topic more suitable for another blog post, but I mention it here to close the loop for now. The point is that a successful DevRel content program becomes self-perpetuating and all content up to this point should help generate momentum in that direction.

From awareness to advocacy: The power of a dream DevRel content program

In The Moon tarot card featuring senior pug Gary as the dog, the wolf, and the crayfish. This card is less about content and more about my own fears in my current job search 😅, but I guess it could also illustrate the part of the developer's hero's journey when they feel most uncertain (and how this is a great place for content to come to the rescue).

A dream DevRel content program doesn’t just inform – it transforms. By aligning content with the developer’s journey, adhering to the Triple A’s of authenticity, accuracy, and "Aha!" moments, and maintaining an unwavering focus on the needs of your ICPs, you create more than just engagement. You foster trust, empowerment, and advocacy. Every piece of content should serve as a bridge connecting developers to solutions, demystifying complexity, and igniting inspiration. When done right, a DevRel content program transcends marketing – it becomes a catalyst for community, collaboration, and shared success, turning developers into champions who carry your story forward.

(And you should hire me to run it! )

Events and resources and other notable things

The Developer Marketing Alliance Developer Relations Summit is tomorrow, December 3rd, 2024. With speakers such as Wesley Faulkner and Katie Wasilenko Miller among its speakers, I’m looking forward to the insights, inspiration, and community. Register here.
I’m excited because the DevRel Foundations working groups are getting underway and yes, I am volunteering to manage the group on metrics, reporting, and best practices cause you know I love some process and data!
From the CNCF to career transitions, here’s an open source list of tech professionals who are down to grab a virtual coffee with you and chat – I should add my name to that list!
What they never tell you about leaving an abusive relationship is that it’s expensive. If you can, please consider donating to help my friend Emily start a brand new life.

If this resonates with you, then you might like working with me

Liz Acosta — Sun, 01 Dec 2024 03:17:44 +0000

Me and Gary dressed up as Wednesday and Pugsley Addams for Halloween -- get it?!

Let's try this again

Back in October 2023, I wrote this article on LinkedIn hoping that an unconventional approach to job searching would get me an offer.

And it worked! Sort of!

While my gig with Snowflake didn't end up working out, it did help me identify my professional strengths and needs. So here's an iteration on the original post:

I can't keep pretending

It is a bummer spending yet another holiday season unemployed. I wish it wasn’t so hard. I’ve tried medication, coaching, and years of therapy, but my most recent role at Snowflake finally forced me to confront some truths about myself: The parts of myself who struggle to conform are also the parts who make me good at what I do well.

My ability to see the bigger picture, adapt to new plans, efficiently internalize new information, empathize with developers, and produce high quality content is a side effect of a confluence of neurodivergence and lifelong mental health conditions. My innovative approach to problem-solving is a result of seeing things differently, and because I see things differently, I have different needs.

I have spent my life trying to be the person I think other people want me to be; as a result, I’ve ended up in some very misaligned situations. What happens if I stop trying to pretend?

So here I am, no longer trying to pretend because real talk: your girl needs a job!

You receive: One unconventional but cool teammate, I receive: One job

From surviving to thriving

I work best when I have the following:

Fully remote or hybrid up to two days a week with a strong preference for offices in San Francisco. Offices are a minefield for my focus and executive function. Because I hold myself to such high standards, I feel distressed when I feel my productivity slow down. When I am allowed to be a weird little goblin in private, I get so much work done!
An emphasis on work-life balance and boundaries. I often do my best work when I am not at work. My brain never turns off, so even when I am relaxing I am passively problem-solving. I need to take breaks so I can nurture my hobbies and replenish my internal resources. Moreover, as a deeply creative endeavor, successful DevRel requires rest! I think Marisa Smith, PhD says it best here:
Opportunities to write code, to write words, and to lead projects. These are my favorite things to do!
Trust, autonomy, and appreciation. I take a lot of pride in my work and though my methods may occasionally seem unconventional, anything that I put my name on has to meet my high standards. When I am fully resourced and I feel confident and focused, I am extremely self-motivated -- I mean, just look at how I've managed to keep up a consistent flow of my own content all on my own! I trust my teammates to be the best at what they were hired for and I always acknowledge the efforts of others.

All I want for XMas is a job 🎵

Here's hoping for a holiday season miracle! If you've got any leads or if this post resonated with you in anyway, you can contact me by leaving a comment here, via LinkedIn, or using the contact form on my website.

Method	Checks that ...
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*
assertRaisesRegex(exc, r, fun, args, *kwds)	fun(args, kwds) raises exc* and the message matches regex r
assertWarns(warn, fun, args, *kwds)	fun(args, kwds) raises warn*
assertWarnsRegex(warn, r, fun, args, *kwds)	fun(args, kwds) raises warn* and the message matches regex r
assertLogs(logger, level)	The with block logs on logger with minimum level
assertNoLogs(logger, level)	The with block does not log on logger with minimum level
assertRaises(exc, fun, args, *kwds)	fun(args, kwds) raises exc*