Once an engineer attains some semblance of seniority, the job requirements quickly evolve past simply authoring code. Reviewing designs, managing stakeholders, collecting requirementsâthese are the things that take most senior engineersâ time. They are also, effectively, examples of being a âmeat proxyâ.
Consider the last time you were tasked with building something, and realized halfway through that thereâs an edge case where the requirements were unclear. Pretty common, no? So you find the product owner, ask a few questions, and return to the work with a clearer sense of the problem. In the abstract: you simply took context from one individual and applied it to a different operation. Meat proxy. What makes this example notable, however, is the human judgment and communication required for it to be done effectively.
The term âmeat proxyâ is funny, which is certainly one of the reasons it caught on so quickly. But itâs also evocative of a real phenomenon. People do actually just copy and paste AI output trying (unsuccessfully in most cases) to pass it off as their own. This is one type of proxying behavior, I suppose. But consider the fact that there are different kinds of proxies, and you can be any kind of meat proxy you wanna be, baby:
This is the type of proxy that Gruhn is getting at. This type of proxy simply takes its input and forwards it along. Nothing too interesting here, and yesâdonât be this kind of meat proxy.
Some proxies take their input and modify it in some way before passing it along to the destination. This is what Gruhn advocates for:
Donât just relay the output. Read it, understand it, validate it, and then write a response in your own words (a decent certificate that youâve done the prior steps). Making that effort is value you can add.
Knowing when and how to do this, however, is crucial. Reframing every output an AI makes just to prove that youâve done the cognitive work is wasted effort. Knowing which outputs to transform (e.g., research) and which to pass along verbatim (e.g., code) is a skill in itself. Transforming that information in a legible way for the recipient takes communication skills, and has always been what separates the best engineers from the only-okay.
Now this is an interesting example. Traditionally proxies have had the responsibility of routing (e.g., service discovery in distributed systems, load balancing, etc.). AI is an excellent thinking partner, but can often act like a firehose of information. When a dumb proxy simply regurgitates all of this prose, itâs both obvious and harmful. When a smart âroutingâ proxy dissects this output and routes the correct information to its destination (e.g., incorporating new constraints, elevating new questions), the value of the AI thinking partner can be more fully realized.
Knowing âwhenâ and âhowâ to shape AI output and how to correctly route that output are the key skills one needs to be an effective proxy. Remember that your audience isnât (or shouldnât be) just another AIâitâs a human. Code changes, technical designs, product briefs, emails, blog postsâthese are artifacts that are meant to be read by a human. They can inform future AI as context, but they are first and foremost means of communicating with people. You should be shaping the output for the audience.
The answer isnât to avoid being a proxy altogether; itâs to be an intelligent one whose judgment shapes the output to be more useful to the human on the receiving end.
]]>I know that 3D printing isnât a new technology - itâs been around for decades, and consumer-grade 3D printers have been available on the market for several years at this point. Iâm actually late to the game here.
But I canât help but be amazed at this piece of technology. Itâs a frickinâ real-life replicator!
Of course, after printing my first few doodads and dongles from Bambuâs extensive MakerWorld catalog, my mind immediately pivoted to another modern consumer technology that I am certainly not a late adopter of: AI.
Thereâs no reason I couldnât create my own designs. If I can imagine it, why shouldnât I be able to print it? Except that I have zero CAD experience. But itâs 2026! Any CAD software is just one representation of bytes on a computer - bytes that a properly instructed AI agent can tweak and tune at my discretion.
After a few short hours of playing around, Iâve got a rough workflow: I chat with Pi, which programmatically uses OpenSCAD or Blender to create actual three-dimensional designs, then exports them to Bambu Studio as 3MF files. From there, I can send them to my replicator and hold the results in my hands within hours.
Again, mind-blowing.
The fact that it was so trivial for me to compose these various tools and turn nearly anything I can dream up into reality is nothing short of miraculous. Itâs simply incredible how accessible all of this stuff really is. The dream-to-reality pipeline is getting shorter by the day. To quote the Zuck: The Future Is for Everyone.
]]>Programs must be written for people to read, and only incidentally for machines to execute
Structure and Interpretation of Computer Programs (1984)
Reviewing code is a core responsibility of software engineers â but we do not teach it. We spend much of our academic years learning to write code, our formative years sharpening that skill, and our latter years debating tabs vs spaces. Yet very little effort is put into teaching how to read code. We assume that if you can write code, surely you can read it! But âreadingâ and âwritingâ, while related, are two totally different skills (just ask my five year old - heâs learning to do both!)
With the continued advances in agentic development, authoring code is no longer the bottleneck. What used to take hours or even days can be accomplished in mere minutes with the help of LLMs. This has unleashed a torrent of creativity, new features, and much more code that needs to be carefully inspected. Reading code is a critical skill that must be deliberately sharpened.
So how do you learn? Let me tell you how I did.
While Iâve been responsible for doing code reviews my entire career, it not something that I focused on until I had been a senior engineer for some time. I spent my early years bouncing around a few different industries and earning my stripes. After that I spent a year as the lead (see: only) engineer of a small local startup. Given that I worked alone I received zero feedback and since I was the only one writing any code I had zero feedback to give. Code reviews were nonexistent. Once that startup failed I found myself thrust into the exact opposite situation: working in a massive organization with seemingly-insurmountable complexity and more engineers with opinions than you could shake a stick at!
In order to compensate, I started asking questions. My aptitude was in code, and since thatâs where I was most comfortable, thatâs where I directed my efforts:
These questions, while basic and sometimes even pedantic, helped me orient myself in this chaotic new environment. Through asking these simple questions I was able to form relationships with my new peers, immerse myself in the language and tools that we used, and (perhaps most importantly) establish the confidence to keep asking questions as those questions started to become more informed.
Note that every example above was a question, not a statement. Its okay not to have the answers. Its expected! There truly is no such thing as a dumb question. Any question that you ask will result in one of two things happening (maybe even both!): the author reconsiders their code from a new perspective, or you learn something new that you can take with you.
Just because its easier to focus on the technology (its what weâre experts in after all), that doesnât diminish the value in doing so. I started my code review journey focusing on those things - but theyâre still far and away the majority of review comments I leave. Itâs fun to quibble with and push for cleaner, more well-designed code! Itâs important too!
After a few months into my new position I had developed a much stronger understanding of the business and the players involved. With this growth in context came bigger questions:
These are the sorts of questions that arise when you consider a changeset as just one component of delivering customer value. A PR represents, in the micro, a gradual step - but a step towards what? Having a concrete understanding of the teamâs goals and ever-evolving philosophy should inform how we consider individual code changes.
This is the part where writing code and reading code really diverge as skills. The misconception that âsoftware engineeringâ equals âwriting codeâ is understandable â after all, itâs the most tangible thing we do. But think about the last time you built something consequential. You researched the problem, talked to the people who knew more, formulated a plan, then wrote the code, then had several people review it. The actual writing was already just a small part. It is the complex cerebral work required to write the correct code and get it into the hands of customers that is the proper role of engineering â and reviewing code is where that broader context pays dividends.
Fast-foward to a couple of years later. Iâm working as the tech lead on a different team, and the context I brought to my reviews had grown further still:
Same habit, bigger aperture. I was still âjust asking questionsâ â but the questions now drew on context that spanned teams, timelines, and architecture. You get here the same way you got to the previous stage: by expanding your awareness. Meet new people for coffee chats to discuss their work. Review incoming requests from outside contributors. The more you understand about why things are being built, the more useful your reviews become.
Observing my own personal journey reveals two key themes:
It takes humility and bravery to ask questions and engage in conversations. Start asking them anyway.
]]>Test coverage has long been a controversial topic. Management often equates coverage percentage to code quality, pushing for teams to meet some arbitrary threshold that will magically ensure that weâre writing high-quality code. While I agree with the criticisms, I still insist that 100% coverage must be our baseline for any production system.
While the clichĂŠd retorts against coverage metrics are not without merit, they are only directionally correct. Insisting on 100% coverage for its own sake is a foolâs errand. Total coverage is still a worthy goal as a means of developing quality software. While coverage doesnât indicate quality the deliberate pursuit of coverage enables quality in unique and powerful ways.
By striving to test each and every function, branch, and statement we write we force ourselves to engage with our codeâs rough edges in the most intimate ways as early as possible. The tests we write are often the first time our code is engaged with - but it will not be the last! Testing puts the evolutionary pressure of âtestabilityâ on our design. By listening closely to what that pressure tells us we can immediately spot issues with the long-term maintainability of our code before anyone else even sees it.
If we approach testing our code with this mindset, 100% code coverage is simply an artifact of a job well done.
Most professional engineers that Iâve had the pleasure to work with generally do attempt to thoroughly test the code that they write. They identify the âhappy pathâ but also ensure that a few obvious edge cases are covered as well. If they can achieve 100% coverage in this way, all the better - but so long as theyâre not dipping below any automated baselines (eg. failing continuous integration builds) then this is an optional cherry on top of their work.
Those programmers who do set their sights higher often buckle at the first sign of adversity. Canât come up with a clear API invocation that covers that one branch in that private method you wrote? âEh, its probably not critical to test that branch. We do need to have it though just in case X, Y, or Z reasonâ. This self-delusion is a trap - any production code that warrants being written definitionally deserves to be tested. If we anticipate this pattern, however, we can identify it for what it really is: a signal about the quality of our source code.
There are often scenarios where contriving a test scenario that mimics exactly what some edge case is programmed for is simply too difficult or even impossible. It is these exact scenarios that inform us that our design needs refactoring.
Private methods are by definition implementation details and as such should not be tested explicitly. That implementation detail, however, reflects a real use case of our system. While it is usually trivial to establish a test whose setup puts the system in a state that mirrors this âreal-world scenarioâ. However any engineer who has written tests for any substantial amount of time in their career can tell you that this is not always the case.
Imagine that youâre building a feature that sends notifications to users, but only if they havenât been notified recently (to avoid spam). This might look something like this:
class NotificationService
def notify_user(user_id, message)
user = User.find(user_id)
if should_send_notification?(user)
send_email(user.email, message)
send_sms(user.phone, message) if user.premium?
log_notification(user_id, message)
end
end
private
def should_send_notification?(user)
return false if user.notifications_paused?
last_notification = Notification.where(user_id: user.id)
.order(created_at: :desc)
.first
return true if last_notification.nil?
time_since_last = Time.now - last_notification.created_at
time_since_last > throttle_period(user)
end
def throttle_period(user)
user.premium? ? 1.hour : 24.hours
end
end
This isnât a particularly complicated class. It is generally cohesive, as all of this logic lives together. However when we attempt to fully test it, we run into problems quick. For example, how do you test the branch where last_notification.nil? is false and time-based logic kicks in?
The private method clearly does too much: database access, time calculations, business rules. Attempting to test this, while not impossible, introduces quite a lot of friction: you need to create database records, manipulate timestamps, and stub Time.now - to name just a few things.
Below is just one example of how we might respond to that difficulty. We can turn the difficult-to-validate should_send_notification? method into a dedicate class that more clearly models our notification domain:
class NotificationService
def initialize(notification_policy:)
@notification_policy = notification_policy
end
def notify_user(user_id, message)
user = User.find(user_id)
if @notification_policy.allowed?(user)
deliver_notification(user, message)
end
end
private
def deliver_notification(user, message)
send_email(user.email, message)
send_sms(user.phone, message) if user.premium?
log_notification(user.id, message)
end
end
class NotificationPolicy
def allowed?(user)
return false if user.notifications_paused?
last_sent_at = user.last_notification_sent_at
return true if last_sent_at.nil?
time_since_last = Time.now - last_sent_at
time_since_last > throttle_period(user)
end
private
def throttle_period(user)
user.premium? ? 1.hour : 24.hours
end
end
This approach has several immediate benefits, such as:
NotificationPolicy can be tested in isolation with simple user objects/doublesBut perhaps more important than these immediate improvements is the reduced costs of maintenance over time. Imagine that six months later, you need to add âquiet hoursâ (no notifications 10pm-8am). In the original implementation, youâd be digging into that tangled private method. In our refactored version you add one method to NotificationPolicy and one additional condition in allowed?. The separation makes the change obvious and safe.
By leaving difficult-to-test code untested, we abandon signal that is crucial to ensuring our code is maximally resistant to entropy. Untested paths are where these design smells hide and you cannot improve that which you cannot smell.
Scaling these marginal improvements in maintainable design across every feature we implement pays dividends that counteract any perceived development costs. Each new feature becomes easier and easier to implement as our systems become more and more flexible.
Anyone who has worked with me for any stretch of time knows that I am a passionate advocate for Test-Driven Development. By flipping the traditional script on its head, weâre able to force the signals weâre concerned with to appear far earlier in the software development lifecycle than ever before!
Think about it: even in the world where youâre writing tests after production code youâre thinking of edge cases and considering their costs and mitigations in the moment. By codifying these considerations in your specifications before even writing the code you put yourself in a position to write the correct APIs and design the right system before a single line of code has even been authored! This is the real power of TDD.
Done correctly, TDD also implies one hundred percent test coverage.
While I strongly believe that TDD is the best way to approach writing our code, itâs not a hard requirement for using code coverage to force better design decisions. Whatâs important is that we ensure total coverage and use each point of friction we find as a means of identifying improvements to be made.
Itâs important to note that simply surfacing opportunities for improvement is not itself a silver bullet. Improved testability does not equate better design; it is simply one dimension of good code. Testable code isnât necessarily well designed code, but well designed code is inherently testable. While aiming for testability puts pressure on the softwareâs design, that pressure is not dictatorial. You are still the one making the design decisions and those decisions are where things become problematic.
Never before has it been more tempting to achieve a higher coverage number through brute force. LLMs and the agents that they power offer the ability to easily define a metric of success (coverage) and the context needed to achieve it. Viewing coverage as a target removes any value from derived from the process.
Without very detailed prompting, an LLM will always simply attempt to write the easiest possible test that moves the coverage metric in the right direction - whether it be abusing mocks and stubs or forcing private method calls. Agent-driven coverage efforts will optimize for the wrong metric to the exclusion of all else.
âNo pain, no gainâ is an ancient adage for a reason. Offloading the pain of achieving coverage to an LLM that cannot feel the pain and recognize it for what it is abandons any signal and removes the human spark that is needed to take that signal and turn it into a more maintainable design.
It can be easy to fall into the trap of seeing gaps in coverage as a problem to be solved. Viewing coverage gaps in this way can easily lead to missing what those gaps really are - missed signals. By aiming for complete coverage as part of day-to-day engineering work, we shift that crucial signal leftward and amortize the cost of design across the entire SDLC at the time of highest leverage - initial development. If we approach coverage gaps retroactively with this same mentality, we may lose some flexibility, but we can still find useful signal to point ourselves in the direction of a successful refactor.
So the next time someone argues against 100% coverage, ask them this: are you arguing against a metric, or are you arguing against listening to your code?
]]>This metaphor applies to a lot of things, but especially to software engineering. And the most concrete example of this in agile software development is the retrospective.
Iâve long been an advocate for retros as the most important agile ritualâmore so than standups or backlog groomings. Hereâs why: standups keep you informed about todayâs work. Backlog grooming ensures youâre building the right features. But itâs the retrospective that offers the team a collective avenue for ensuring youâre moving in the right direction as a team.
Retros are where members get a safe space to voice their opinions and share ideas, get feedback on those ideas, and actually put them into action through recurring kaizens (continuous improvements). Theyâre where you talk about the things that donât fit neatly into a standup: the communication breakdown that cost you three days, the deployment process thatâs slowly killing morale, the junior developer who needs more pairing time but doesnât want to speak up in front of everyone.
So often in my career, Iâve seen teams devalue retrospectives. They only do them at the end of a project, or at the end of a fiscal quarter. I get itâretros can feel like âjust another meeting,â especially when theyâre run poorly or devolve into unproductive venting sessions. Teams think theyâre saving time by doing them less frequently.
But in my opinion, thatâs way too late. By the time youâre doing a quarterly retro, youâve already built three months of technical debt, burned out half your team, and shipped features nobody wanted.
To go back to the driving metaphor: you wouldnât set your vehicle in a direction and then come back to check once you think you shouldâve reached your destination, only to find out that you missed your exit three hours ago. That would be absurd.
Yet thatâs exactly what teams do when they skip regular retros. They work heads-down for months, assuming theyâre on the right path, only to discover theyâve been building in the wrong direction, using processes that frustrate everyone, and missing opportunities to improve along the way.
Iâve watched this play out firsthand. One team I worked with went six weeks without a retro because they were âtoo busy with the release.â By the time we finally sat down together, tensions were high, the deployment pipeline was a mess, and three people were quietly interviewing elsewhere. If weâd been checking in every two weeks, we could have caught and fixed those issues when they were small.
Hereâs where Iâve been experimenting lately, and I think it solves a lot of the problems with traditional retros.
Instead of blocking 90 minutes on everyoneâs calendar every two weeks, Iâve been running what I call asynchronous retrospectives. Using a tool like Figma (or Miro, or even a shared doc), we spin up a traditional retro board and leave it open constantly throughout the sprint. Team members can jump in ad hoc whenever they want and provide feedbackâjust like they would during the opening 10 minutes of a traditional synchronous retrospective.
This approach has several advantages:
It amortizes the cost of the retro over the entire iteration. Instead of context-switching everyone into a meeting at once, people can contribute when itâs convenientâright after they encounter something worth noting. The feedback is fresher, more specific, and doesnât require anyone to remember what frustrated them two weeks ago.
It enables more candid, anonymous feedback. Even in psychologically safe environments, some people are more comfortable writing than speaking up in a room. The async format gives everyone equal voice, regardless of whether theyâre introverted, remote, or just need time to articulate their thoughts.
It allows for faster reaction. We donât have to wait for the next scheduled retro to propose changes. We can do kaizens constantly through this approach. When someone drops a piece of feedback into the board, discussions can happen in Slack to refine what a kaizen looks like in response. Small improvements can ship within days, not weeks.
Itâs easier to coordinate. No more âsorry, I have a conflictâ or âcan we move it 30 minutes earlier?â The board is always there. You contribute when you can.
Iâve found this to be much more effective than a traditional, all-hands synchronous retrospective. That said, we do still have a brief sync every two weeksâmaybe 30 minutesâto review the async board together, discuss themes, and commit to specific action items. But the heavy lifting happens throughout the sprint, not in one exhausting session.
Whether you go synchronous, asynchronous, or hybrid, the key is this: you need to be doing retrospectives constantly. This is what it means to have both hands on the wheel in software development.
The goal isnât to have a perfect process. The goal is to constantly adjust your trajectory. A small course correction today prevents a major detour tomorrow.
Whenâs your next retrospective scheduled? If the answer is âI donât knowâ or ânot for a while,â thatâs your first problem to solve.
And if youâre doing traditional retros but finding them draining or ineffective, consider trying an async approach. Spin up a board, share it with your team, and see what happens when you give people the freedom to contribute on their own time.
Because if youâre not constantly checking whether youâre pointed in the right direction, building the right things in the right way, youâre not really drivingâyouâre just hoping you end up somewhere good.
Keep both hands on the wheel.
]]>Letâs just say that my skills have improved a tad in that time. However, my free time has significantly plummeted in that time as well (three kids will have that effect).
So while itâs long overdue, Iâve finally been able to relaunch my personal blog with a fresh coat of paint. All the cringey old blog posts are still here, and should hopefully be buried in the paginator over the coming months. In the meantime, letâs recap all thatâs changed since I last posted!
When last I wrote, I was working as a Data & Insights tech lead for the Intelligent Solutions Group at John Deere. Since then, Iâve done a few other things:
So mostly making kids and popping around big tech. Itâs been a fun few years, and while Iâve learned a ton I havenât been the best at taking the time to reflect and write about the things Iâve learned. This post is my way of trying to be better about that.
My focus for the past few years has been effectively leading engineering efforts at large-scale companies. As such, Iâll definitely be writing about leadership and philosophy and all other sorts of soft skills-esque facets of engineering.
Iâve also had my love of engineering reinvigorated with my introduction to the Ruby programming language. Iâll also write quite a bit about raw engineering such as design patterns, languages (Ruby and Rust are my current focuses, but JavaScript will always be my first love and act as my primary language), and systems design.
And of course, AI. Itâs so hot right now, and Iâd be lying if I said that I designed and built this new website all on my own. Our discipline is changing rapidly, and itâs important to stay on top of these developments.
I probably shouldnât even try to predict this. However I do get the urge with some frequency, and the eyesore that was my old website is no longer a blocker. Hopefully I can bring myself to write something at least once a week, but Iâm not going to force it. If I have something to say, Iâll say it. If I donât I wonât clutter this site with garbage.
So if youâre reading this, welcome! Iâm excited to get back to maintaining my own personal site. Hopefully this enthusiasm manifests! I have a few ideas for this site - both content and features - that should be coming in the next few months. The holidays are right around the corner đ and this is always a fun time to dig into personal projects.
Until next time đ
]]>Luckily as software development practices and the dependency ecosystems we use have matured, weâve seen the advent of several automation tools that allow us to simplify this burdensome process into something far more manageable.
Iâve already highlighted some of the pain points in keeping dependencies up-to-date, but I havenât really explained why you should even care to do so in the first place. When I suggest the need to keep dependencies up-to-date, Iâm regularly met with the same refrain:
It works with the current version, so I wonât even bother. Iâll update when I need a new version.
This is an understable - albeit misguided - position for several reasons:
Practically speaking, by the time you find yourself needing functionality exposed in newer versions of any given dependency, you risk finding yourself several breaking versions behind. This all too common situation artificially increases the burden of incorporating newer versions by requiring several unrelated changes to the existing codebase - just to get access to a single version (which itself may not actually require any changes at all).
Another - more nebulous - concern is that of security. Any given version may be functionally adequate for the given state of your application, but security vulnerabilities are discovered and patched every day. By neglecting to keep your dependency tree up to date you put your application, and therefore your users, at risk. This is perhaps the most critical reason to keep your dependencies up to date.
Hopefully by now youâre convinced that keeping your dependencies up to date is an important task. However, we also know that it is by no means a trivial one. Keeping dependencies up-to-date could be a full-time job itself depending on the scope of your ownership. That said there are several tools we can leverage to make this process easier.
Perhaps the most important concept to build upon is that of Semantic Versioning (or SemVer). Semantic Versioning is a practice that aims to imbue any given version of a code module with an explicit meaning that correlates to the code itself. When releasing new versions of modules that you maintain, its important to adhere to this standard so as to better communicate with those who consume your work.
In practice, Semantic Versioning manifests itself as three different release categories, each indicated by the various pieces of a version tag (you may be familiar with the syntax: v1.2.3). Letâs look at those in more depth:
Example:
v.1.2.3
A Major version release is often the least common. This is because a major version change indicates that something, well, major has changed with the underlying code that necessitates consumers modify their consumption thereof. This is often referred to as a âBreakingâ change, because without actual changes to the accomodate them, these changes will cause the consuming application to not work (be broken).
In the example above, 1 is the major version.
A Minor version release indicates that the module has changed in such a way that any consumer should be able to update without having to make any changes to their existing codebase. These minor versions, however, likely contain new features that one may wish to make use of in our applications.
In the example above, 2 is the minor version.
A Patch version release is the most common. Patches indicate changes to the module code that should be invisible to those consuming it. These sorts of changes include (but are not limited to): bugfixes, security vulnerability patches, and performance optimizations.
In the example above, 3 is the patch version.
Itâs worth acknowledging that the version definitions above are flexible. It may be impossible to address a given security vulnerability without introducing a breaking change to a codebase, and therefore a major version change may be required for what might intuitively be considered a patch. Having some awareness of how your code is used by others is a critical facet of maintaining shared modules.
Understanding what semantic versions mean is one thing, but having to make this decision every time you wish to release a version of your application can be a nightmare - especially if youâre not the only developer on the project. In that scenario, how do you know what category is correct for releasing your code changes if that release will also include changes from others? This can lead to many wasted hours of effort simply communicating between developers who may not even inhabit the same time zone!
One excellent way to ensure that this communication can be done quickly and without coordinating disparate human beings is to use Semantic Commits. Semantic Commits aim to make Git commits convey meaning similar to the way that Semantic Versioning conveys meaning of releases. With semantic commits, each commit message is prefixed with a common keyword that indicates to other developers what that change includes. Examples of semantic commit prefixes include (but are not limited to):
feat for commits that introduce new featuresfix for commits that fix bugs or security vulnerabilitiesperf commits introduce performance improvementsSemantic commit prefixes are entirely subjective. The goal is simply to foster better asynchronous communication between developers. Establishing a shared language with your collaborators is crucial. That said, youâll often find teams gravitate towards using the prefixes established by the Angular Project due to the network effect established by the various automation tools that build on them.
One such tool is Semantic Release. Semantic Release will automatically publish new releases of your code, and is typically executed on every merge to the master branch. Semantic Release builds on Semantic Commits by using a codified set of prefixes to determine what semantic level of release to publish automatically.
Publishing a new release on every merge to the master branch allows new versions to be concise in what they chance and reduces the amount of unpublished inventory. More frequent releases, however, also wind up creating far more releases than one may be used to. While this provides consumers far more control over what code changes to incorporate into their applications, it also increases the frequency with which that decision must be made. Wouldnât it be great if we could automate that as well?
As SemVer has rapidly taken over the world of open-source software development (thanks in no small part to the many practices outlined above), even more tools have been created that build on the assumption of SemVer to simplify consumption as well as maintenance of open source software. Iâll outline two popular tools below: WhiteSourceâs Renovate and GitHubâs Dependabot.
Long the reigning champ of automated dependency management, Renovate (recently purchased by WhiteSource Software) is an application that runs on its own dedicated compute resources and scans source code repositories (think Github, GitLab, Bitbucket, etc.) that specify their dependencies in code (package.json, pom.xml, etc.) and then leverages public module repositories (npm, maven, etc.) to know when a dependency needs updated.
If youâre using GitHub to host your application code, Renovate will open a Pull Request to your application whenever a new version of a dependency is released. This completely removes the burden of having to track dependencies from developers. Simply monitor you own codebase - youâre already doing that, right? - for pull requests from Renovateâs bot, and merge away! With some simple configuration, you can even configure GitHub + Renovate to automatically merge these pull requests without you having to even verify them yourselves.
Be sure to only automerge minor or patch releases! Major versions require other changes that require an understanding of your application that simply cannot be automated.
Perhaps less well known, Dependabot is an up-and-coming tool for automating updates to dependencies. After being acquired by GitHub, Dependabot has become far more prevalent within the GitHub ecosystem as a tool of first resort when approaching security. If youâre using public GitHub, youâll likely have noticed the new âSecurityâ tab on some of your code repositories; this is powered by Dependabot!
The fact that Dependabotâs adoption into the GitHub suite of tools is maturing rapidly, its quickly becoming a qualified alternative to tools such as Renovate. With its security integrations being baked into the GitHub interface, and enterprise support coming soon, itâs definitely worth giving it a shot if youâre just getting started with automated dependency management or are still using Renovate.
As with any automation, the lack of manual oversight presents its own concerns. While systems and tools like SemVer aim to enforce a strict definition of dependencies that indicate consumption requirements, its entirely possible that erroneous release versions can occur - eg. it is entirely possible that a minor release version can include breaking changes. By automatically consuming this minor version without modifying our consumption, we risk breaking our application quickly and without warning.
The best way to mitigate this possibility is the same way we mitigate any other potentially destructive change to our applications: with a robust automated testing ecosystem. By automatically ensuring the integrity of our applications on every single change, weâre able to confortably allow automation to assume more and more responsibilities so that we may focus on driving value for our business.
]]>Its my profile picture because I often find myself saying the same thing in technical/design/product conversations. Many times as developers, designers, POs, and leaders weâre faced with decisions that are presented as binary, but arenât actually mutually exclusive - with a little creativity, we can often have both.
]]>If you develop primarily in the AWS ecosystem, youâre likely already aware of Lambda functions and how tools such as API Gateway allow us to instrument fully-functional microservices while maintaining absurdly low operational costs (or absurdly high, if your service is popular!) What you might be less familiar with, but are perhaps curious about (you did open this blog post, after all), is AWSâs Fargate solution.
This post attempts to describe with some detail the two aforementioned architectural solutions with a focus on what distinguishes the two from one another, and ultimately help drive your decision to the right tool for the job at hand.
As mentioned previously, AWS Lambda functions have (right or wrong) become almost synonymous with âserverlessâ in the minds of most developers. But if we consult the excellent (albeit curiously branded) serverless.com, we see a definition of âserverlessâ where the term âlambdaâ is conspicuously absent:
Just like wireless internet has wires somewhere, serverless architectures still have servers somewhere. What âserverlessâ really means is that, as a developer you donât have to think about those servers. You just focus on code.
After all, Serverless as a philosophy isnât limited to AWS (think Microsoftâs Azure Functions as a Lambda equivalent), and so why should any single tool be representative of the philosophy?
That said, this common misconception isnât entirely without merit. Serverless functions provide an easy-to-understand implementation of a serverless microservice that many of the worldâs most profitable companies leverage in production today.
Just as not all tissues are âKleenexâ, so too are not all serverless functions âlambdasâ - the key to understanding each is to focus on the platonic form, rather than the brand. Lambdas are simply âfunctionsâ that execute in an environment where you as a developer donât have to concern yourself with the underlying server. Thatâs it.
Because Lambdas are boiled down to the lowest functional unit of an application (a function), much of the traditional concerns an application developer needs to take into account are managed for you: runtime, OS, memory, etc. are largely defined by AWS and youâre free to implement your function on top of it.
This simplistic abstraction is what really sets Lambda apart from other, more holistic approaches such asâŚ
Like Lambdas, Fargate (either via ECS or Kubernetes) allow us as developers to remove from scope concerns related to the physical âserverâ itself: things such as system memory, CPU usage, etc. Again, these things are still in use, but they are entirely managed by Jeff Bezosâ team of highly skilled systems specialists. We get to focus on our code!
A keen eye, however, will notice some glaring differences between the two lists of non-concerns layed out in the above few paragraphs:
Whereas Lambdas remove concerns related to OS and runtime as well as âbaremetalâ concerns like CPU and memory, Fargate only handles the latter. In this way, Fargate is still technically serverless (and allows us to harvest the fiscal benefits of not running a server constantly), but still enables us to define the minutea of our codeâs runtime environment through the use of Containers.
Letâs say, for example, that youâre building an application using Node.js. If you want to run this application via a series of Lambdas, youâre locked in to the two Node runtimes that AWS provides for Lambdas: Node@8 and Node@10. Want to run Node@12? Not an option. Need to run something as old as Node@6? Not an option (anymore). Fargate allows you to specify exactly what your runtime environment looks like by using whatever Docker container you provide, and therein lies the key difference.
So we know the key differences between these two tools, but Iâd like to focus for a moment on one of their key similarities.
As mentioned before, both are technically serverless in that they satisfy the definition quoted earlier. Both run on-demand, and as such will shut down after a predetermined amount of idle use, saving you (and/or your company) precious capital.
Whenever a serverless âapplicationâ or âfunctionâ shuts down, however, it is not longer as immediately accessible as it was when it was alive and running. This is what saves you money, but with the caveat that it makes triggers to your serverless application during the âdownâ state measurably slower, as the responses to those triggers are blocked by the time it takes to start up the environment in which the process runs. This is a common problem in serverless architectures, and there are several ways to address this problem.
The key to managing cold-starts is to understand usage patterns of the service youâre trying to build. If its going to be high-usage, then youâll likely not have to worry much about cold-starts because there will likely be long periods of âwarmâ servers servicing your requests - that said, if youâre relying on frequent traffic to keep your serverless servers warm, youâre likely toeing the line where it might make sense to pay for a constantly running compute instance (server, as opposed to serverless) for your architecture. This is an important decision that only you can make, and is outside the scope of this post.
Assuming youâve made an informed decision to go serverless, youâre likely still unsure whether or not to go the âserverless functionalâ (lambda) route, or the âserverless containerâ (Fargate) route. Youâll likely want to pick Fargate if:
A general rule of thumb is that you need Fargate if your application needs to be run as a container (or relies heavily on processes outside of your codebase).
Given that last statement, if the scope of your application is isolated to running the business logic youâve defined in your codebase, youâre likely just fine with Lambdas. Youâll likely want to pick Lambdas if:
To be fair, this post really only captures the basics of Lambdas vs Fargate, and the considerations Iâve personally taken into account when architecting solutions using either one. If youâd like to learn more about Fargate, I canât recommend enough the following video by Abby Fuller from AWS.
]]>Letâs say for example you want to test that a given functional unit utilizes the output of another, tangential functional unit:
import {getData} from '../utils/get-data';
import {mapData} from '../utils/map-data';
export function myFunction(input) {
const data = getData(input);
const output = mapData(data);
return output;
}
In this example, myFunction utilizes getData to derive a data value using the formerâs input. When we write unit tests for myFunction, we could take one of two approaches:
getData as well as mapData, and manually reproduce them in our tests to validate output.If it werenât already clear, the answer here is definitely to use stubs. getData and mapData should already be tested in isolation, and duplicating that test logic is largely unnecessary. There are, of course, exceptions to this statement; however more often than not if something is imported/included/required in your code, stub it in your tests!
Letâs see an example of how we might test myFunction:
import sinon from 'sinon';
import {expect} from 'chai';
import * as GetDataUtil from '../src/utils/get-data';
import * as MapDataUtil from '../src/utils/map-data';
import {myFunction} from '../src/my-function';
describe('myFunction', () => {
it('should convert input into output', () => {
const input = Symbol('my input');
const data = Symbol('data');
const expectedOutput = Symbol('the output I expect');
const getData = sinon.stub(GetDataUtil, 'getData');
const mapData = sinon.stub(MapDataUtil, 'mapData');
getData.returns(data);
mapData.returns(expectedOutput);
const output = myFunction(input);
expect(output).to.equal(expectedOutput);
});
});
This is a pretty basic test utilizing stubs. Weâre importing both getData and mapData and using sinon.js to stub them. Now when we invoke myFunction from the context of our test, neither getData or mapData will actually be invoked; instead, the new stub functions weâve created will be called, and they will return what weâve declared that they will return.
A keen eye will notice that this test is woefully incomplete. If we were test driving myFunction we could easily pass the tests without even using getData! In fact, we could pass the test by effectively aliasing mapData:
import {mapData} from '../utils/map-data';
export function myFunction() {
return mapData();
}
This will lead to a passing unit test, but likely wonât accomplish what we want myFunction to do when run in the broader context of our application. Because we built this theoretical system we know that mapData will only actually return expectedOutput when its provided with dataand that data is only available from passing input into getData. But how can we configure our stubs (and subsequently, our tests) to reflect this reality?
One very common approach is to analyze the stubs after invoking the unit under test and verifying that they were invoked correctly:
import sinon from 'sinon';
import sinonChai from 'sinon-chai';
import chai, {expect} from 'chai';
import * as GetDataUtil from '../src/utils/get-data';
import * as MapDataUtil from '../src/utils/map-data';
import {myFunction} from '../src/my-function';
chai.use(sinonChai);
describe('myFunction', () => {
it('should convert input into output', () => {
const input = Symbol('my input');
const data = Symbol('data');
const expectedOutput = Symbol('the output I expect');
const getData = sinon.stub(GetDataUtil, 'getData');
const mapData = sinon.stub(MapDataUtil, 'mapData');
getData.returns(data);
mapData.returns(expectedOutput);
const output = myFunction(input);
expect(output).to.equal(expectedOutput);
expect(getData).to.be.calledWithExactly(input);
expect(mapData).to.be.calledWithExactly(data);
});
});
Youâll see that weâve included the sinon-chai package and configured chai to use it. This module exposes some new assertions in chai that we can use for this sort of explicit stub testing. Its certainly not the only way to do so, however.
This test is a lot better, but again, exposes a potential for abuse in our production code:
import {getData} from '../utils/get-data';
import {mapData} from '../utils/map-data';
export function myFunction(input) {
getData(input);
const data = getData();
mapData(data);
return mapData();
}
This code would pass our test. output (in the context of our test) is the return value of mapData, mapData is invoked with the output of getData, and getData is invoked with input. All of our expectations are met, but thereâs nothing forcing them to be âgluedâ together.
Youâll notice that weâre only able to skirt around our business requirements and still pass the tests by making arbitrary invocations of our getData and mapData utilities. Luckily, sinon stubs come with a property we can observe that can force into the right direction:
describe('myFunction', () => {
it('should convert input into output', () => {
const input = Symbol('my input');
const data = Symbol('data');
const expectedOutput = Symbol('the output I expect');
const getData = sinon.stub(GetDataUtil, 'getData');
const mapData = sinon.stub(MapDataUtil, 'mapData');
getData.returns(data);
mapData.returns(expectedOutput);
const output = myFunction(input);
expect(output).to.equal(expectedOutput);
expect(getData.callCount).to.equal(1);
expect(getData).to.be.calledWithExactly(input);
expect(mapData.callCount).to.equal(1);
expect(mapData).to.be.calledWithExactly(data);
});
});
Now our test fail again, because those arbitrary invocations of our utilities will cause our callCount checks to fail.
export function myFunction(input) {
const data = getData(input);
const output = mapData(data);
return output;
}
All of this is a roundabout way of forcing the correct interaction with stubbed dependencies. This was a lot of work to validate something that (I would consider) to be tangential to the actual business concerns that myFunction was originall built to address. Letâs see if thereâs a simpler approach that doesnât conflate testing our units with testing what exactly goes on inside of them.
Sinon offers a lot of ways to interact with stubs. Whether its by observing the number of times theyâve been called to enforcing a specific return value, if its something you want to know about or do with a function, sinon stubs probably have your back.
While weâre on the subject of forcing a return value from a stub, wouldnât it be great if we could make that return value conditional? What if getData only returned data when it was provided with input? What if mapData only returned output when it was provided with data? Introducing: .withArgs.
const expectedInput = 'some input';
const expectedOutput = 'expected output';
const myStub = sinon.stub();
myStub.withArgs(expectedInput).returns(expectedOutput);
myStub(); // returns undefined
myStub(expectedInput); // returns 'expected output'
Using .withArgs, we can configure our dependencies seperately from our actual unit test parameters. In this way, our unit tests reads as if its actually testing the business logic under test, and not enforcing some very specific implementation upon the developer writing code to satisfy our tests:
import sinon from 'sinon';
import {expect} from 'chai';
import * as GetDataUtil from '../src/utils/get-data';
import * as MapDataUtil from '../src/utils/map-data';
import {myFunction} from '../src/my-function';
describe('myFunction', () => {
it('should convert input into output', () => {
const input = Symbol('my input');
const data = Symbol('data');
const expectedOutput = Symbol('the output I expect');
const getData = sinon.stub(GetDataUtil, 'getData');
const mapData = sinon.stub(MapDataUtil, 'mapData');
getData.withArgs(input).returns(data);
mapData.withArgs(data).returns(expectedOutput);
const output = myFunction(input);
expect(output).to.equal(expectedOutput);
});
});
Youâll likely notice that there is now nothing enforcing that we donât use getData and mapData over and over again. No callCount validation here. As long as myFunction returns expectedOutput, this test will pass.
This is where things get a little subjective. I would argue the case that we shouldnât care. Our dependencies (getData and mapData) are configured to act as they would in production. input and output are both enforced explicitly. How one gets from point A (input) to point B (output) is enforced implicitly by the configuration of our stubs. Any superfluous usage of our dependencies should be cleaned up by refactoring (a process that should be separate from TDD).
Again, Iâm of the opinion that this is how tests should be written. This by no means is to suggest that this is the only way tests can be written, nor that its the right approach for everyone.
Tests are a good way to express expectations of production code. Theyâre especially useful if youâre pair-programming in an environment where one person writes tests and the other writes code to âbeatâ those tests. How we express those expectations to both current and future developers is incredibly important, and isnât a decision that should be taken lightly.
Choose wisely.
]]>