Forem: Taxdoo Engineering

Engineering Metrics: Take your team to the next level

mariacasancho — Tue, 02 May 2023 12:26:42 +0000

You can’t improve what you don’t measure.

These words of wisdom are often attributed to the famous management guru and thinker, Peter Drucker, and, especially in the context of modern software engineering, have never been more relevant. Measuring things is something we have been doing for thousands of years, it is a concept that we are very familiar with. Metrics mean that success and failure can be measured in a quantitative way. Data gathered and analysed within a metrics-driven environment enables engineering teams to regularly pulse-check important projects and make informed decisions, rather than relying solely on verbal discussions or waiting until a piece of work is complete. At Taxdoo we like to take time to identify what we can improve, take steps to enhance our products and empower our teams according to the data that we collect.

I’d like to invite you to share a glimpse of the Taxdoo Engineering culture and with an introduction to Engineering Metrics, including the top five metrics which I recommend.

What are Engineering Metrics and why are they useful?

Engineering metrics are a quantitative or countable measure of software characteristics. When we talk about software characteristics we include different aspects that influence software development.

As you develop software there are many factors at play. We need to measure those factors to have a better understanding of the effort, size and cost estimation. Engineering metrics can also help us with other aspects: we can refine our productivity, influence our team culture and identify improvements in the quality of our software.

As Engineer Managers, we want to identify areas of improvement, manage the workloads of our team, increase return on investment and reduce overtime and costs. They are necessary to understand how our team, department and company perform and they can provide valuable insights for the future.

Engineering Metrics vs. Engineering KPIs

We often hear Engineering Metrics and Engineering KPIs and sometimes they are confused. Even though both are metrics your organisation needs to measure and perform to make progress with the company strategic plan. The difference between them is that KPIs measure progress on specific business goals and metrics are quantitative measurements used to track performance of processes at an operational level (thanks to Datapine for the extensive explanation). Both provide what needs to be measured to achieve your long-term objectives.

Metrics should provide value

As organisations, we need to make sure that we are making the right decisions based on the correct data. We need to be aware of the way we prioritise and measure this data as it can also be counterproductive: extracting insights from data is time intensive, so make sure that the data sources used are reliable and relevant for your team or department.

There are also other metrics that could influence the mood of the team. Measuring how many lines of code a person produces not only causes unnecessary stress to developers but also will show that their managers do not understand code quality. A developer producing more lines of code does not necessarily mean that a programmer is more productive. At Taxdoo, as one of our values is trust, we are against micromanaging our team members and we follow principles like KISS (Keep It Simple, Stupid) or YAGNI (You aren't gonna need it) to promote a healthy, solution-orientated engineering culture. Therefore metrics like “lines of code” or “how many commits a developer does” aren’t metrics that we are interested in.

Types of Engineering Metrics

There are several types of categories that we can classify our engineering metrics depending on which areas they focus. Although some of those metrics could fall into different categories, I’ve divided them into these three categories:

Team metrics

This category focuses on the metrics that help the team, improve developer happiness, contribute to a good environment, evaluate processes implemented by the team and identify pain points that the developers experience day to day.

Here are some examples:

Context switching: context switching indicates how often team members have to move from one issue to another because of blockers. If there's a lot of context switching, it signifies that the team is inefficient.

Code Review Response: Many developers are idle because they are waiting for a code review, to unblock developers or dependencies to other tickets. A code review that takes too much time or effort to get response could become obsolete and it will be harder to merge back to the main branch.

Meetings: How many minutes developers spend in meetings every week. Reviewing this is a quick way to optimise developers’ time and remove unnecessary meetings.

Product metrics

This type of metric will focus on the product itself: size, quality of the features, reliability, design. These metrics focus on providing the best value for the user.

Examples:

Monthly active users: This is one of many engagement metrics,which focus on how and how often users interact with your product. Those who engage with your product are considered active users and increasing the number of them is important for your company's growth.

Number of sign ups: With this acquisition metric we can measure when somebody first starts using our service. With the number of sign ups we can also have an idea of how many users our system should be able to deal with.

Bug response time: This is a metric that will help to provide a better service to the end user. It will measure how long it takes to react and resolve a bug. If a user has problems and finds a bug we want to solve it as soon as possible.

Project metrics

This category is for measuring if we are using the resources to their fullest potential. They track the performance of the engineering projects.

High risk files: This metric indicates the files that have a high rework percentage. The risk is bigger when you have to make more changes. Therefore, files with a high rework percentage also have more risk that could lead to low quality.

System cost: this is part of the monetization metrics, we need to know how much our system costs so we can calculate how much net revenue we can get from our users.

Number of hotfixes: With the number of hotfixes we can see how many unplanned urgent changes need to happen, which will indicate what may have been overlooked when we merged that code.

How to implement them?

There is no right way to implement Engineering Metrics. As the needs of each organisation and engineering team differs, it is important to select KPIs and metrics which consider these unique requirements. A good start is for each organisation to evaluate which metrics are relevant for them and work with the APIs or data available from the tools that they are using.

However, there are some tips I would like to mention regarding the implementation of Engineering metrics.

Engineering metrics should be:

Easy to produce: Those metrics should be automatic, the work to generate them should be minimum.
Easy to integrate as part of day to day work: It doesn’t matter if the metrics are easy to create if using them in the day to day work is cumbersome. People will stop using them.
Easy to visualise and all in one place: If you have several metrics, it is very important to have one dashboard to display all of them. Reading them should take a couple of minutes.

My top 5 Engineering Metrics

Downtime:

Downtime will indicate that our systems are not available, this can be because our provider has some problems or because we introduce something that requires a system shutdown.

It will mean something different depending on the project:

The user can't access the system
Real-time processing stalls for at least 10 minutes
Number of 500 Errors

Developer Disturbance:

Developer Disturbance will point out ad hoc or not planned tasks or requests that reach developers. The same as Downtime, this will depend on the project and team. We need to identify what is a developer disturbance. It can be the number of meetings and it can be measured as meeting time as previously mentioned, it can be the amount of requests from other departments or the recurrent tasks that haven’t been planned and they need to be taken immediately.

Bugs created vs Bugs resolved:

We can track how many bugs usually appear and how we react to them.

Failed Deployments:

Failed deployment: the name says it all. It can be measured as the time delay for live code to be released into production or decreased lead time for changes, etc. And it will show if this team might need help with their CI/CD.

Project Vulnerability Status & Grade of Projects

With this metric one can integrate a security scan to check the vulnerability of the dependencies. We also check with this metric our compliance framework and scan licensing.

In conclusion

As mentioned earlier, all metrics will vary based on the needs of your business and structure of your engineering team. What's important is to take at least two quarters to a year for the metrics to allow new processes and goals to embed, with regular monthly pulse checks along the way. By regularly evaluating metrics over a specific period of time, you can make adjustments to ensure these metrics suit your team and are contributing value by bringing you closer to achieving business goals.

Do you also have recommendations or success stories on engineering metrics?

Recommended Reading:
Four best practices for leveraging data responsibly, Hillary Nussbaum, LeadDev.com
KPIs vs Metrics: Understanding The Differences with Tips and Examples, Bernardita Calzon, Datapine.com

Feature Flags

mariacasancho — Mon, 17 Oct 2022 11:55:37 +0000

These toggles are more useful than we give them credit for

At Taxdoo, having a safe mechanism to test our products before they reach our clients is of the utmost importance. To achieve this, we started utilising something that we call feature flags. Today, I would like to take you on a journey to explore what exactly feature flags are, and what are the benefits they could bring to your projects.

What Are Feature Flags (a.k.a Feature Toggles)?
To make it as simple as can be, feature flags are a technique that provides features, or part of code, behind a toggle or flag that is easily controlled outside of the code itself. These toggles, or variables as we also refer to them, are used in conditional statements to toggle what is inside based on the value of that feature toggle.

In even simpler terms, Feature flags come in handy most when you want to test changes in your code but it’s often not possible or practical to deploy them to all of your users at once. Instead, you can use these useful toggles to enable or disable the new code on a per-user basis.

Advantages of Using Feature Flags
There are many benefits to implementing these useful toggles as part of your daily practice, however, the biggest one must be that they are a great way to test all these new features you’ve been working on for so long. For example, you can use feature flags to control whether users get access to new features, and when they do. This allows you to avoid having problems in the rest of your application if there is an issue in one area only.

Feature flags don't block the deployment of your codebase or prevent any changes from being made while they're running live on production servers. You can always add or remove them as needed after launch without affecting other parts of your application's functionality or performance, so it's easy for teams at all levels to work on critical parts of our applications and still be able to deploy them with confidence!

Feature flags are just one tool in your arsenal, but they're a very useful one. You can use them to test new features and roll out changes gradually to prevent problems from affecting the rest of your application. They also make it easy for different teams at all levels to work together on critical parts of our applications without affecting their functionality or performance.

Business toggles
A business toggle is what we describe as an enhancement that we want to add only for specific users. This could be anything from pricing changes (e.g., allowing more than one price tier), to a marketing campaign (e.g., showing only during certain times of day).

The point is that we need to know as much as possible about our users to create a personalised experience. As a result, we can tailor content and design elements based on user preferences, which makes them more likely to stick around longer. Or at least until they get bored with the site. Well, let’s hope we don’t get to that point. Another way to call this technique would be a Canary Release.

As there’s much more to cover on different types of feature toggles, one of my favourite developers, Martin Fowler, has actually made a very in-depth review for those who want to know more. If you’re one of them, feel free to read his article here.

Feature flags aren't just about making things easier
Feature flags are a great way to make your code easier to change and improve. But, they can also introduce complexity to your project. For instance, if you have multiple features, you must understand what they're doing, who has access to them, and where their data comes from.

The problem with feature flags is that they aren't just about making things easier; they're also about making sure everyone knows what's going on in the codebase. So, if there's a wide excess of information circling around different developers and none of them assign clear ownership of these bits, this is when we reach the state of “feature creep”.

Little tip: Feature creep is when the scope of a project expands beyond its original goals. This can happen in any software project, but it's especially common in large projects with many stakeholders who have different ideas about what should be included or excluded. In other words, we don't like feature creeps!

GitLab Feature Flags service for Front-end
You can use feature flags in many ways but today, I would like to talk about an MVP (aka Minimal Value Product) solution, which makes it easy to handle Feature toggles across different projects in Front end by using Gitlab.

GitLab has a Feature Flag service which comes in handy in many situations. To create one and manage them, you just need to go to Deployments -> Feature Flags. You will see this view where we can enable and disable the Feature Flags and we can also see the environments where we can see these feature flags.

Once the Feature Flags are created in GitLab we need to use the Unleash service to retrieve the information. The Unleash allows us to know how many Feature Flags we have configured in the project and the information about them. For the Front End to use Unleash service they need to be connected via the Unleash Proxy or we could build a small Backend that uses the Unleash SDK for our Front End projects to use.

As in this case we want to use Feature Flags in several Front End projects, we choose the solution of building a small node.js project that retrieves the list of feature flags of a specific project. So we just need to install the client, initialise it with the info from GitLab and ta-daaaah! We have our project Feature Flags!

Later in your Front End application you just need to access it with featureFlags['myFeatureFlag'].enabled to toggle a button that you don’t want to show, or a page, for example. I would recommend calling this service when you load your application and storing it somewhere globally, so you don’t end up in a situation where you need to call the backend many times.

Some closing words
As you already saw, Feature flags are a great way to help teams find the right features and priorities for their products. Worth mentioning is that this is the approach that we use at Taxdoo,however, there are many different ways to handle this technique and I would love to hear your opinion, if you’d like to share. Do you use Feature flags? If yes, how do you implement them?

Stick around for some more interesting Dev-related content as we turn our blog more and more into the guide to the world of Taxdoo.

See you soon!

6 Ways to Look After your Mental Health as a Developer

EmilyCook321 — Fri, 08 Oct 2021 08:20:39 +0000

Working in tech is awesome, especially as a software developer.
The opportunity to build amazing products, being paid to learn and working with very smart colleagues are just some of the reasons why this profession is so rewarding.

However, software engineering isn’t always a walk in the park. Tight deadlines, adjusting to remote work, fixing major outages and generally, the velocity of the tech industry are some factors that can cause you stress as a developer. Therefore, it’s important to look after yourself and create simple, daily rituals that support a healthy working routine.

Ahead of World Mental Health Day on October the 10th, we asked our software engineers on how they take care of their mental wellbeing.

Here’s what they said:

1. Fresh air 🍃
Our interim VP of Engineering swears by fresh air and regular doses of sunshine; living in Hamburg means that biking to work or going for a lunchtime stroll around the Alster is easy to integrate into your daily routine.

2. Meditation 🧘‍♀️ 🧘‍♂️
Some of us have trouble not thinking about things, so meditation can help you put things into perspective and arrive in the current moment rather than being swept away by thought.

3.The Pomodoro Technique 🍅
This technique focuses on working in 25 minute sessions throughout the day.
This can be helpful for focussing efficiently and it encourages you to take regular breaks so that you avoid sitting for hours and hours without moving, drinking water or looking away from your computer screen.

4. Connect with colleagues 🙋‍♀️ 🙋‍♂️
At Taxdoo, we encourage everyone to set up or attend ‘Donuts’ (informal online meetings), regardless of department.
Catching up with a colleague over a random Donut or setting up a Developer Donut is a great way to get to know your colleagues and helps you to feel connected and part of a team.

5. Take a break 🌳🚶🚶‍♀️🌳
Coding is awesome and the feeling of completing a task is great, however rest is also important. Why not use your lunch break to talk a walk around the block? You might be surprised at how refreshed you feel.

6. Find a job you love 💙
We all spend a lot of time at work, so it is important to feel comfortable and motivated by your tasks, colleagues and environment.

If you’re wondering what it’s like to work at Taxdoo, we can confirm that we’re hiring! For more details, check our jobs page or follow us on Twitter for more updates.

How do you look after your mental health as a developer?

Clean CSS: How to Spring Clean your Project

mariacasancho — Thu, 12 Aug 2021 13:26:22 +0000

Illustration by Ashley Allen, Taxdoo Junior Graphic Designer

We’ve all been there; a new project drops onto your team’s plate and it’s a scramble to hit the deadline. What usually gets hit hardest? CSS styling. Short deadlines, sub-standard architecture or lacking guidelines means that often CSS becomes the problem child in terms of delivering clean code.

At Taxdoo, we use a range of styling methods for our frontend projects, however a prime example of CSS styling can be seen in our website. Like many company’s websites, Taxdoo.com is the digital shop door for the thousands of customers who visit our site daily.
An inhouse-built site made with React, we are constantly looking for ways to optimise the performance, aesthetics and functionality of our key marketing tool.

What is clean code?
Epitomised by software expert Robert Cecil Martin’s (otherwise known as Uncle Bob) book, Clean Code: A Handbook of Agile Software Craftmanship, clean code refers to agile principles of software development that aim to create code that is simple to understand or change. Dead code refers to code that is not used when an application is run.

What is clean code for CSS?

In CSS, short for Cascading Style Sheets, is the way that property values are applied to the content as a hierarchy. Child elements can either inherit or override properties values from the parent elements. If this hierarchy is not properly adhered to or the team uses bad practices, it can seriously affect a website’s performance. That's why it is important to optimize and try to keep the CSS clean.

Over time, while we add more features or just small modifications to HTML elements, the CSS can grow quickly and it becomes a challenge to maintain, especially if you don't stick to the YAGNI principle ("You aren't gonna need it", only code the functionality that it is needed) in mind.

Eventually, you need to delete unused CSS or optimize it.

CSS frameworks can take a project load to 140KB of CSS or more, which is a lot and can take a long time to render. This size is also possible when you have a lot of templates and pages, and if you aren’t using all of it, having tools to reduce size and delete dead code is totally worth it.

Why is it good to remove dead code?
Dead CSS will affect the rendering time of your website. Using Lighthouse provides a good overview of potential savings you could make in load-time by removing dead CSS, as well as scoring your website on other categories such as SEO, Performance, Accessibility and Best Practices.

How do we detect dead code?

One of the tools that we like to use is Coverage from Google Chrome. To open this feature from Chrome, you need to open the Developer tools and click coverage in the 3 dots at the bottom left.

There we will see a list of JS/CSS files with bars in red and blue color. The red color means the amount of code unused and the blue color is used. It also shows the percentage of unused Bytes. Whenever you click one of those elements from the list, it will open that file and you can check which part is not being used because it will show a red bar next to it.

This is only visible for the page you are in, when you visit more pages or do more actions in the page this will get updated. Seeing a lot of red doesn’t really mean you should delete it. It could be used in another part of the website, so do not take this chance to delete them because you could end up with big styling problems. To know if a CSS selector is not being used you need to check every single page or state of your site and execute all javascript.

This tool is useful to get an idea if a piece of CSS is being used, for example, if we have a specific component, we visit that component and see how much unused CSS we have.

Other ways to detect dead CSS
To analyse your code and find unused CSS, you can use several automated tools;

PurifyCSS and PurgeCSS are the most frequently used ones and they can be integrated in the build process, while UnusedCSS is a website that checks and gives you a report of your CSS usage.

To avoid having unused CSS, make sure that you scope your components and maintain a good structure. It is difficult to have unused CSS with smaller components since if the component is removed, so is the component’s CSS. However, if you end up with a bigger project or your components grow a lot, it’s worth regularly checking your CSS and trying to clean it.

What do you use to detect or remove dead code?

At Taxdoo, we emphasise knowledge sharing and hope that you found this article was useful. Stay in touch by following us on Twitter. Alternatively, you can check out our open vacancies here.

7 Tips our Developers recommend to Newbie Devs

EmilyCook321 — Thu, 15 Jul 2021 08:14:50 +0000

Today is World Youth Skills Day so we want to celebrate young people’s access to training and career opportunities by providing some inspiration for anyone interested in working in tech.

We asked our developers, product managers and even our CEO about the resources that sparked their interest in tech and helped to hone their skills; here are their recommendations.

Practise this ⏰
If you have 30 minutes a day, try completing a few exercises on FreeCodeCamp. This is a great way to learn to code in bitesize amounts of time.

Try this 💡
A good starting point are the Hello World courses on Codecademy, which helps with learning tooling set-up and understanding how things work in that language. You can also test your knowledge by modifying the code and adding other statements.

Get stuck into this 💻
A slightly more advanced course for learning frontend development is ToDoMVC, which also has a lot of other examples for each tech stack.

Build this 👾
Learning by doing is the best method which this C# Unity Game 3D course from gamedev.tv definitely will help you to do so.

Read this 📚
Clean Code is the classic book written by Uncle Bob, otherwise known as Robert Cecil Martin, who epitomizes the concept of clean code. From a product perspective, check out Lean Product Playbook.

Watch this 📺
Silicon Valley (HBO); our co-founder, Matthias Allmendinger, recommends this series as it sparked the entrepreneurial spirit that brought Taxdoo to life.

Eat this 🍱
Sushi. Ok, just kidding. Although our developers do love a good Bento box, feel free to pick your favourite brain food for learning to code. Happy hacking doesn’t happen on an empty stomach!

We hope this list was helpful! It is, of course, by no means complete- what else would you recommend for budding developers?

We’re growing at Taxdoo! Follow us on Twitter or LinkedIn for the latest news and job posts from us.

Please note: none of these posts are paid endorsements and are solely recommendations from individual colleagues at Taxdoo.

"Hello World!" Introducing Taxdoo Engineering

EmilyCook321 — Thu, 27 May 2021 15:35:47 +0000

Hello and good day from all of us at Taxdoo Engineering!

As it's our first outing here, we thought we'd take the opportunity to introduce ourselves and introduce you to the world of Taxdoo Engineering.

Our headquarters in Hamburg is home to over 100 employees across 24 nationalities and all of our in-house engineers.
Dedicated to building products that deliver an outstanding customer experience in tax compliance automation, our Engineering team's work revolves around making compliance as easy as ABC.

So what exactly do we do at Taxdoo?

In 2015, a lightbulb idea sparked Taxdoo into being.
Three entrepreneurial PhD students, named Matthias, Roger and Christian, combined forces and came up with an idea that would simplify the complex VAT compliance process.
The solution was a software product designed to automate compliance in combination with the knowledge of tax aficionados for selling goods online (read more on the history of Taxdoo and our recent five year anniversary here).

Combining VAT compliance with automation software meant that Taxdoo could bridge the gap between the breakneck speed of e-commerce and the structured world of tax compliance to provide a solution that simplified VAT compliance for online-trade within Europe.

Since then, Taxdoo has rapidly become a market leader, offering a holistic solution for automated tax compliance for online retailers and their tax advisors.

#VATisLove?!
At Taxdoo, we really do believe that #VATisLove; as engineers, we pride ourselves on our unique combination of tech expertise and deep knowledge of tax compliance. We use this to develop Taxdoo products that delight our customers by offering a service that simplifies an essential yet typically time-consuming task for traders.
And yes, your inkling is correct, it is a spin-off of that Haddaway song.

What's in the Taxdoo toolkit?

Our tech stack comprises React, Node, Java, Go, GraphQL, AWS, Docker, Typescript; paired with a broad ecosystem of engineering talent and a regular cadence of code reviews and training opportunities, we ensure that all engineers feel challenged and supported to build the best possible products and services for our customers.

Who are the people behind the product?
Hamburg is home to our team of in-house engineers; spanning 9 nationalities, our team comprises colleagues from around the world.
Introducing some familiar faces from Taxdoo below, we hope you stop by and say 'hello' in the comments and feel free to follow us on Twitter for updates on our work, open roles and life at Taxdoo.

Andrew is a Fullstack Developer and Tech Lead.

Andrew has been a Taxdude since 2019.

What made you decide to pursue a career in tech?
I always had an interest in tech, but had never really considered it. Programming seemed like something only for genius students of math and science, which I never was. However, I found some free online resources that taught web development and I immediately knew it was what I wanted to do. It took quite a lot of hard work to get good enough to land that first job, but it was definitely worth it.

As a self-taught developer, what were the most helpful resources you used to master your craft?
There are a lot of brilliant online resources; FreeCodeCamp was great for learning about frontend development. I also built a portfolio of my own projects and used resources from podcasts, completed some of Wes Bos' courses, attended tech meet-ups and read blogs which helped me to learn the skills needed to land my first developer position.

Raghda is a Fullstack Developer and Tech Lead.

Raghda joined Taxdoo in January 2021.What made you decide to pursue a career in tech?
My mum is my main inspiration; I grew up seeing my mum working as a web developer and that gave me a lot of passion for joining the field. When I first chose my major as computer science at university, I found it a bit challenging but as soon as I dived deeper into the courses, I enjoyed them and became more motivated to code and develop my own projects.

You're originally from Egypt; what do you like about life in Hamburg?
At the beginning it felt strange being in a foreign country but as soon as I settled here, I enjoyed being exposed to a different culture, following the rules and getting the chance to enjoy nature, especially now that I appreciate that Hamburg is a quieter city to live in than Berlin.

What are you most excited about for 2021 at Taxdoo?
Getting to learn a lot, technically and non-technically, and of course our new office in Hamburg.

Ahmed is a Full Stack Developer

Ahmed joined Taxdoo in November 2020.

How would you describe Taxdoo Engineering culture?
Rich; it's a rich culture because we have a variety of people. This is not just to do with cultural backgrounds but also personalities and this shapes the way that people think. People think differently from one another; you notice this when people review your code or make suggestions. It's not just based on experience but also mentality. Having this array of different perspectives means that it makes for a much richer product. The way that I write code compared to everyone else is different, so having a variety of perspectives and opinions makes you take a step back, review your own work and understand how to write a better solution.

What have been the highlights and biggest learnings of your career so far?
One of the biggest highlights was definitely changing countries; it's been very rewarding and I am gaining so much experience the more that I work. I recognise that I can think faster now. I have become more comfortable writing code in TypeScript since joining Taxdoo and I am now faster at solving issues. It was also my first time using AWS as a service provider.

Like the sound of our team? We are hiring! Check out our Engineering roles here or follow us on Twitter for the latest updates and news from our team.
The full version of this article was posted on our Medium site.