Home Company We Did a Hackathon!

We Did a Hackathon!




We define ourselves as a startup, and while we proudly carry such a title, we also carry extraordinary responsibilities. After all, you mean to change the world with great products.

If you are lucky enough to end up with a solid product, keep adding new features; always looking to add talented people to the team, and your user base just keeps growing it sure seems you are on the right track.

Imagine receiving a video from a user sharing some annoyances about their user experience with your product. Signing up went perfectly smooth, but after that, adding rules to dashboards didn’t go that smoothly; adding the product to their workflow was not that easy, and even the search bars could be improved. Wasn’t your product just perfect? What would you do? 

Well… we did a hackathon!

Disclaimer: This is NOT how we build products at Codacy! 

Having a product backlog is key to ensure you actually build a product people want to use. In fact, we keep our product roadmap public and open to your suggestions. However, always focusing on impactful features might leave aside minor improvements that are equally loved by your customers and that’s nothing a Hackathon can’t resolve.

During the first 2 weeks of April, our engineers (I mean avengers 🦸) together with product managers, technical writers, and marketing were free to team up among them to solve all the annoyances delivered on a Trello board. Teams needed to be a minimum of 2 avengers and could solve only one annoyance at a time. To ensure we fixed the maximum number of annoyances in 2 weeks, all annoyances that took more than a week were added to the product backlog for further discovery and planning work.

Fortunately, we also had 2 Nicks Fury on the team (a product manager and a product designer) to remove all roadblocks on the way and ensure all hypotheses were valid and able to test.

Take a look below at the annoyances we got rid of at Codacy.👇

The repository list was not being updated after installing the GitHub App

Solution:  After a user installs the Github App, we now refresh our cache. That means the repository list will update automatically.

When tools on Codacy fail, they fail silently

Solution: When a tool fails on a commit, the Pull Request page shows a warning to alert the user some commits had problems with the analysis.

Image When tools on Codacy fail, they fail silently

On the patterns page, scrolling through the list can be cumbersome

Solution: Filters, toolbars, and side panels now stick at the top when scrolling down.

Image On the patterns page, scrolling through the list can be cumbersome

Users can’t test Codacy without having to request access to an organization

Solution: We added 3 cards of public open-source repositories using Codacy on our homepage. Users can visit these repositories’ pages on Codacy (without an account) and GitHub.

Image Test Codacy without having to request access to an organization

Clarify why does Codacy needs all these permissions?

Solution: We ask for the permissions we need only! Since it’s not possible to incrementally ask for permissions, we improved our documentation and present a banner explaining why we need those permissions.

Image Why does Codacy need all these permissions?

When an analysis completes, you need to manually refresh the page to see changes

Solution: Instead of seeing the analysis wheel rotating endlessly, users now see a message asking to refresh the (commit or pull request) page when the analysis completes.

When a repository is too big the CLI crashes with OutOfMemoryError

Solution: The memory limits of the CLI were set to 3GB of memory without any way to change them.

Now you can pass the –max-tool-memory option.

$ codacy-analysis-cli analyze –max-tool-memory 5G

I want to know my repository/files grade via API

Solution: Instead of having to calculate the grade of your repository from the numeric grade, now you can have it directly from the Codacy API.

Image I want to know my repository/files grade via API

GitHub Action to make running client-side tools easier


👉  Reports coverage for multiple repos using an Account API token (with the API, reporter and GitHub action)
👉  Send CLI reports for multiple repos using an Account API token (with the API, CLI and GitHub action)

New in CLI action:

👉  Run GoSec and StaticCheck
👉  Parse and push results from Clang-Tidy and Faux Pas

Reanalyzing commits after analysis configuration changes must be done manually

When you change your analysis configuration such as patterns and tools, ignored issues, and file extensions, these changes were applied only on the next analysis and we didn’t mention it.

Solution: We now show a notification informing the user that a reanalysis is needed to reflect the changes. This notification includes a link to trigger the reanalysis.


That’s it! We are done with annoyances for now! 😅

At the end of the day, we feel pretty good with the end result since we got rid of as many annoyances as we could.

And also, employee wise we got the chance to work with people we were not used to (and we want to ❤️) and we all know, sometimes avengers just need to reunite with whoever they wish to because… well…  avengers.



Please enter your comment!
Please enter your name here

Subscribe to our newsletter

To be updated with all the latest news, offers and special announcements.

Recent posts

How to implement coding standards in your organization

Coding standards are a set of guidelines and best practices designed to ensure that your code is consistent and readable, making...

Leading Your Team to Engineering Excellence

On March 7th, we did a webinar called Leading Your Team to Engineering Excellence. Guest speaker Steve Berczuk, Lead Software Engineer...

3 popular C# style guides that will help your team write better code

C# is a popular programming language developed by Microsoft, and you can use it for developing web applications, games, and more....

February Product Update 🚀

Hi there 👋, Here are a few updates from February with very exciting news, so keep on...

Velocity vs. Cycle Time: understanding the key differences

Velocity and Cycle time are two standard metrics to measure the efficiency and effectiveness of software development teams. They help you...