There are some time-saving techniques that are applicable to engineers no matter what size company they’re at. =Anna Fenske, a software engineer II at SaaS monitoring and analytics company Datadog, said her favorite technique for saving time is extensive pre-project documentation.
At the team level, though, the size of the company does impact the challenges engineers face and the methods they can employ to save time.
Datadog is a publicly traded company founded in 2010 with more than 3,000 employees. As such, it makes sense that Fenske said her team’s focus when it comes to efficiency is on identifying and reducing tech debt.
Continue reading to learn more about how Fenske saves time in her day-to-day work along with the specific challenges engineering teams at ltech companies face in streamlining their workflows.
Anna Fenske’s approach to saving time on software development at Datadog can be summed up as “don’t move too quickly.” Fenske told Built In New York that rather than jumping right into her terminal, she takes time before starting a project to document the problem and possible solutions in-depth. Fenske’s team also follows a version of this philosophy and conducts weekly retrospectives to identify and reduce tech debt.
What’s your favorite time-saving hack when it comes to developing software? How do you implement this strategy in your work?
Before beginning a project, I make sure I’ve documented four things. First, is the problem, including specific pain points or user journeys that we’re solving and the requirements of its solution. Second, is a near-exhaustive list of possible solutions. Third, is the solution I have chosen, including why it has been chosen and why other solutions are less desirable. And fourth, are the short, medium, and long term visions for the solution. If I’m collaborating with another team, this document will also include the responsibilities of each team; both teams will agree on all components of the project document before any development begins.
Without a clear project roadmap, we risk losing engineering time to having to revalidate the goal of the project. In the absence of a clear problem statement and expectations enforced by a written roadmap, the value and purpose of the project may be put into question, and that slows or even stalls progress. Without a written agreement, teams risk overstepping boundaries or failing to hold themselves accountable to responsibilities, which may result in unclear ownership of a project. I like the old saying, “Measure twice, cut once.”
We’ve implemented weekly operational retrospectives and frequent reevaluations to continuously identify opportunities to reduce tech debt.”
What tools or strategies has your team, as a whole, implemented in an effort to streamline the software development process?
As a team, we’ve implemented weekly operational retrospectives and frequent reevaluations of past architectural decisions to continuously identify opportunities to reduce tech debt. This is often the primary culprit for poor developer experience, which in turn leads to decreased productivity and iteration speed.
As a growing team, it’s easy to forgo retrospectives that focus on past decisions in favor of looking forward to feature development. However, what often gets in the way of our ability to quickly deliver new features are the consequences of tech debt, such as monolithic APIs and frameworks that do not scale to the current size and complexity of a service, that have become the foundation of our product but may no longer meet the needs of our current context.
Additionally, communicating actions taken to reduce tech debt through blog posts, documentation and demos for other teams in our organization has allowed us to multiply our impact on teams that may also be affected by the same technical debt.
How have implementing these strategies or tools — either individually or as a team — changed the way you work? What benefits have you seen?
Documented roadmaps, alignment agreements and continuous review of past architectural decisions to manage tech debt, all help streamline our development efforts. This brings the extra benefit of maintaining a good relationship with our customers and stakeholders. It also allows our team to set an example of what an effective engineering culture looks like for other teams in our organization.
