DEV Community: Andrew Kelly

Breaking a project down into manageable work

Andrew Kelly — Fri, 06 Jun 2025 11:36:14 +0000

I am one week in to a 6 week project to build a tech debt management dashboard. I have been working on the design for it this week and I thought it would be useful to explain how I take a large project and break it down into the actual work that I will do.

So let's start with a high level overview of the project to remind ourself what we are trying to build. The idea for the dashboard is that it would take tech debt issues from issue trackers, outage data from incident trackers, build and release data from CI/CD systems and some user provided data. All of this data would then be processed and the results presented in a dashboard with possibly a few views of the data in tables and graphs.

So with that very high level overview I then split that up into a few broad areas:

We will need integration with a number of external services to gather data
We will need the ability to sign up and sign in with some account administration functionality.
We will need to gather and store the data
We will need to process the data into a form which can be easily viewed in the dashboard
We will need a way for users to view the issues so we will need an issue list view and an issue detail view.
Ability to import and create issues manually as and when new issues come along

For each of these high level requirements there is a lot more detail to get into as and when we work on them but for now, we need to consider these at a high level otherwise we will get lost in detail and not make progress on planning the high level approach.

In addition to these high level requirements, the guiding principle for the design is that I want to make it as easy as possible to get the dashboard set up with all of the config, integrations and data it needs. We are trying to make people's lives easier and the setup should be a frictionless as possible. So let's apply that to the requirements:

We will need an onboarding wizard to help integrate with a number of external services to gather data
We will need the ability to sign up and sign in with some account administration functionality. When someone signs up they should go through the onboarding wizard.
We will need to gather and store the data
We will need to process the data into a form which can be easily viewed in the dashboard
We will need a way for users to view the issues so we will need an issue list view and an issue detail view.
Ability to import and create issues manually as and when new issues come along

Adding an onboarding wizard will help create a frictionless setup. Now I want to pick out a rough order for how I would work on these. This is not really set in stone and I could move things up or down as needed. I need to choose a starting point that will give me a good base to build the rest of the app from. For this app, I think that starting with the user auth and onboarding would lay a lot of the groundwork for the app such as:

Having the authentication setup for the app
Kicking off integration with third parties, storing the settings and credentials for these
Storing the issues we import
User account and team setup settings

Therefore I think I should proceed in this order:

Week 1: User auth and Onboarding
Week 2: Issue list screen
Week 3: Issue detail screen
Week 4: Outage data integration (includes processing of the data)
Week 5: CI/CD data integration (includes processing of the data)
Week 6: Manual issue creation

Progress this week

I posted on my personal LinkedIn account an announcement that I will be starting building Velocity Pilot and aim to get to 1000 users in 6 months. Posting from my personal LinkedIn account got more reach than posting from the company page for Velocity Pilot.

Other than one friend who has signed up, no-one else has clicked through to the website for Velocity Pilot from the post. Organic traffic to the website is very low at 1-2 views per day. Organic visits to the LinkedIn page has been non-existent since last weekend.

I have to admit it has been a bit tough this week and has made me start to question my decision of not paying for any ads on LinkedIn. I am going to experiment with video content from the VP LinkedIn page next week.

Retool

I have been using Retool to create mockups for the dashboard and had considered that I would use this for the first version of the app. However I have been designing more of the app this week and the app will need multiple OAuth integrations with 3rd party systems. This is theoretically possible in Retool using Retool Workflows (think Zapier -style automation) but would be very clunky. Therefore I have decided to ditch Retool for building the app. I will still use it for mockups and prototyping but I will code the first version of the app myself.

The tech stack I am going to use will be Typescript, Vite, React and React-Admin for the frontend. For the backend I am thinking of using Python, Poetry and FastAPI with PostgreSQL. I am also considering Supabase but need to see how that could cope with OAuth integrations.

Last weeks goals

Add another 100 engineering managers to my personal network

I have added 39 managers to my network this week. My strategy has been to send connection requests to my 2nd degree connections who I have a number of mutual connections. I am averaging 40% acceptance rate with this approach but the number of 2nd degree connections who fit the bill are running low. I will continue this next week but expect the number of connections to drop.

Get VP LinkedIn company page to have 150 followers

I had invited a lot of people in my network to follow the page but I still only have 9 followers. I had hoped that the personal post I made could generate more followers too. I had also thought that commenting on posts would drive more followers but that was not the case. I think if I just post more from the VP page and then repost it on my personal page I will get more. I think that once I have some of the app actually working I can post some videos of that and those might do better.

Comment every day on relevant tech debt posts on LinkedIn as Velocity Pilot

I did this for 4 days straight before deciding to stop. I was seeing that I was getting very low impressions on the comments I made and there was no increase in visits to the company page. It did take quite a bit of my time scrolling through LinkedIn to find good posts to comment on so I decided that this was not a good use of my time.

Goals for next week

Complete basic app with authorisation and onboarding wizard
Post a video on VP LinkedIn page of some of the functionality of the dashboard and then repost on personal. Does this approach increase follower count or signups?
Add 25 more managers to my network

Tools used:

Retool - more mockup screenshots
Cursor - AI-supported coding
React-admin - low-code dashboard framework
Supabase - considering that for the backend, includes PostgreSQL, authentication and serverless functions

👋 I am building Velocity Pilot, a dashboard for engineers and engineering managers to help them explain the impact of tech debt on their work.

I am committed to building out in the open and will share progress on Dev.to. Including what is working and what is not working. Follow me as I go solo from 0 to 1000 users in 6 months. 🚀

🌍 Velocity Pilot
🟦 Follow Velocity Pilot on Linkedin

Unleash your idea: Building a landing page

Andrew Kelly — Fri, 30 May 2025 12:50:19 +0000

At the start of this week I launched the landing page for Velocity Pilot as a first step in launching the tool. I wanted to explain some of the thinking that went into this which would be useful for anyone else who has an idea they want to unleash on the world!

As an engineer it's probably tempting to crank out some static website using a bunch of front end tooling but I wanted to keep this as simple as possible. I decided to use a SaaS tool for the landing page and for gathering sign up details from people.

The landing page has two purposes:

Explain and showcase the idea behind Velocity Pilot
Get interested people to sign up to a closed beta

Building the page

I decided to keep the page short and simple with a large hero image that displays a mockup for the tool. ChatGPT helped with this and I created a mockup using dummy data in Retool.

Retool is a no-code app building SaaS tool which I will likely use to build out the initial version of Velocity Pilot for the beta. I will go into more detail in this choice in a future post.

The result is something that I think quite succinctly explains the tool and teases how it could solve the problem of getting tech debt prioritised.

Closed Beta

I am going to run a closed beta for Velocity Pilot starting in about 6 weeks. The idea behind this is to start to get people using the tool so that I can get their feedback on how it should work. I can also use it as a measure for validating the idea in the first place. If there are plenty of sign-ups then it's a strong indication that people are interested in the solution that I am proposing. I am hoping to get 100 people in the beta.

Progress this week

In the background I have building my personal network on LinkedIn. From next week I will post more about Velocity Pilot from my personal profile rather than the company page. I have thus far posted from the company page and that has limited reach. The posts there struggle to get more than 50 - 100 impressions. I'm hoping I can drive more people to sign up from my personal posts.

I am also going to offer short 15 minute research calls with anyone who is interested in the tool. I would use the time to present the mockups that I have and then get any feedback to understand if I'm on the right track for how I think the tool should work. Anyone who signs up for these could be a potential future customer.

Goals for next week

add another 100 engineering managers to my personal network
get VP company page to have 150 followers
comment every day on relevant tech debt posts on LinkedIn as Velocity Pilot

Tools used:

Systeme - for the landing page and CRM
Retool - for creating the mockup screenshot
Canva - image manipulation
ChatGPT - wordsmithing text on the page and company logo
Google Analytics - for monitoring traffic

👋 I am building Velocity Pilot, a dashboard for engineers and engineering managers to help them explain the impact of tech debt on their work.

I am committed to building out in the open and will share progress on Dev.to. Including what is working and what is not working. Follow me as I go solo from 0 to 1000 users in 6 months. 🚀

🌍 Velocity Pilot
🟦 Follow Velocity Pilot on Linkedin

Teams that manage Tech Debt well do this

Andrew Kelly — Thu, 29 May 2025 16:09:53 +0000

Lately I've been researching how engineering teams manage their tech debt. I have collated responses from just over 20 teams on how they manage tech debt in their work. Read on to learn how the best teams do this.

From the data, there were broadly 3 techniques that emerged and the technique depended on how much effort would be required to fix an issue.

1. Refactor as you go

For small issues in code these are things that engineers can and should do as they go along. They viewed this as part of the work of engineers and falls under the concept of leaving the campground cleaner.

2. Refactor and then start

Where a larger refactor is needed this would be raised in planning or estimation sessions and incorporated into the estimate when some work would be done on the affected area. This meant that the tech debt didn't need to be prioritised separately alongside product features. It was also viewed as just part of the work that needed doing by the Product Owner.

3. Allocated time or capacity

A popular approach for larger pieces of work that needed to be prioritised alongside new features, was to use some kind of allocation of time or capacity. The various approaches taken were as follows:

a defined number of points per sprint
a whole week or sprint once every n sprints or once a quarter
a percentage of team time
one team has an annual code freeze during which they will work on tech debt or housekeeping tasks

For these larger pieces of work, all the teams reported some degree of challenge of having to explain or make the case for working on tech debt.

However, there was one little gem that stood out from a number of teams that were most successful in getting tech debt prioritised.

They don't refer to it as tech debt.

They’ll describe the impact that the tech debt has in business terms.

Time and money. The effect on customers or sales.

"Silent failures in the billing service caused 4 hours of downtime last month"

"Slow page load times in the dashboard view cause drop-off during trials, reducing conversion from freemium to paid"

That's how they get it prioritised, and you can too.

👋 I am building Velocity Pilot, a dashboard for engineers and engineering managers to help them explain the impact of tech debt on their work.

I am committed to building out in the open and will share progress on Dev.to. Including what is working and what is not working. Follow me as I go solo from 0 to 1000 users in 6 months. 🚀

🌍 Velocity Pilot
🟦 Follow Velocity Pilot on Linkedin

The two key skills junior engineers need for effective AI coding

Andrew Kelly — Mon, 31 Mar 2025 11:25:24 +0000

It has never been easier or faster for a junior engineer to get help with their work than at any time in the history of software engineering. LLMs have put the insights from massive collections of codebases at the fingertips of software engineers.

A wealth of LLMs have sprung up to help engineers in their work but how should a junior engineer approach the use of these powerful tools?

There are two things to bear in mind when using LLMs to support you in your coding:

The quality of the answers you get is directly related to the quality of the prompt you use. If you don't accurately define what you are trying to achieve you may get a misleading response.
LLMs can be confidently wrong. The answers they give may seem convincing but could be completely wrong or have a bug in it.

So, how can we avoid these pitfalls whilst being productive?

Asking the right question

If you don't specify the question well then you can get a confidently wrong answer which could mislead you. It can be difficult to articulate the problem or question as a junior because you may have a limited understand of the language, tools and libraries you are using.

When you prompt an LLM, provide as much context as you can. Simple questions can easily give misleading results. Mention the language, libraries and frameworks you are using. Explain what your code is supposed to be doing. Be specific about the expected inputs and outputs. As you gain more experience with the language, tools, frameworks and libraries that you use, the easier this will become. You will have a better grasp of what is going on with your code and will be able to more tightly describe the issue or task to an LLM.

Understanding what you get back

I have often seen engineers copy-paste a solution from the Internet that they do not understand. In the past this might been a line or two from a forum post or a Stack Overflow answer. With an LLM, this has the potential to be a whole module of copy-pasted code.

Engineers adding chunks of poorly understood, AI-generated code to a codebase is the biggest risk that software teams have when adopting AI in their workflow. Poorly understood code is difficult to maintain. It can be difficult for an engineer to understand code that they have written themself just 3 months after they wrote it. Imagine how much more difficult that would be if they didn't write it in the first place.

It is important to understand what the LLM is recommending you. Don't just blindly use it without taking the time to sense check it. The code could turn out to be wrong or there is a bug in it. You could then waste time trying to debug it and the LLM then becomes a hindrance rather than a help.

Cross reference the results with official documentation to sense check what the LLM is recommending. Sometimes it's answers may refer to an older version of a framework or library or it could use a function that does not exist. The documentation for a language or library is the authoritative resource on what functionality exists and how it works.

If you are confused by an answer, then don't just blindly copy paste. Apply the 30 minute rule. This would be a good point to ask for help from a colleague.

Key skills for using AI

There are then two key skills for using AI to support you in your software development work:

Prompting effectively
Code comprehension

Prompting effectively

Try to give as much context as you can to get the best results. The more knowledgable you become in the languages, tools and libraries you use, the better you will become at explaining problems and questions to an LLM.

Code comprehension

Code comprehension is key in helping you understand the code that an LLM generates. The better you get at this the quicker you can sense-check / verify answers that the LLM gives you. See my article on this for advice.

Happy coding!

Photo by Lisheng Chang on Unsplash

Code naming: How to improve the readability of your code

Andrew Kelly — Tue, 11 Apr 2023 21:33:37 +0000

When I'm reviewing code written by junior engineers there is one common issue that I see. Often I will see functions or variables whose names are not descriptive enough.

Naming in code is important because it helps people more easily understand the code that you have written. This will help your colleagues when they come to make changes to your code in the future.

Bad naming in code makes it more difficult for anyone who is trying to read and understand the code. We say that this increases the cognitive load of the reader. They will literally need to think harder about how the code works and hold more information about it in their head.

What good naming looks like

The names you use for functions or variables should answer the following questions:

What is the effect of calling this function?
What data does this variable refer to?

Let's look at some examples.

def process_file(file_path: str) -> list[str]

What on earth does process_file() do? The name of this function is too vague because it does not describe the effect of calling this function. What processing is being done on the file? To understand what this function is doing you will have to go and read its code. This takes more time and will require the person reading this to hold more information in their head.

Let's rename the function so that it describes the effect of calling this function:

def remove_duplicate_lines_from_file(file_path: str) -> list[str]

This is much better. Now we can clearly see what this function will do with the file we pass to it. We won't have to refer to the code of the function unless we are curious as to how the duplicate lines are being removed.

Now let's look at a vague variable:

file_data = remove_duplicate_lines_from_file ('file.txt')

At first glance file_data seems like a reasonable choice. It makes sense that the function will turn the data from the file. But what actually is this data? What format is it in? What can I do with it? To answer these questions I would have to go and read the code of the function and possibly even examine the file as well.

Let's rename the variable so that it describes the data it refers to

unique_postcodes = remove_duplicate_lines_from_file ('file.txt')

Now we know what the data refers to. We can make some reasonable assumptions about the format of the data too. It's likely to be a list of strings where each string is a postcode. We can assume that the file has a postcode in each line. Perhaps even an address? This is all possible because of the choice of variable name.

Conclusion

It's easy to overlook issues with names in your code because you will be extremely familiar with the code that you write. You will not need to rely on the names you have used to understand what you have written. We've seen in the examples how good names can make code easier to understand. If code is easier to understand then it will make it easier for other engineers to maintain it in the future.

Don't stress too much about getting the name perfect the first time you write it though. The best name for something may actually change as you make progress on your code. Personally I will often rename a function or variable 4 or 5 times as I work on it so that I get the name just right.

Let's have a bit of fun now. Below is an example function in Python with poor naming. I've added a comment to explain what the function does. Add a comment with your proposal for how it should be renamed and I will review your proposal and provide feedback!

def apply_rules(items: list[Product], rules: list[Discount]) -> float
    """
    Applies discount rules to a supermarket customers basket 
    of goods and returns the total value the customer must pay 
    after all eligible discounts have been applied
    """

Andrew KellyFollow

I have 20 years of experience in tech with nearly half of that in leadership roles. I have worked for a variety of startups, FTSE 100 and Fortune 500 companies both in London and Silicon Valley.

Code comprehension: an underrated skill

Andrew Kelly — Mon, 03 Apr 2023 06:10:18 +0000

Code comprehension is the skill of reading and understanding code. It is an important skill for any engineer but it is rarely mentioned alongside other skills an engineer needs. In fact I would say it is just as important as being able to write code.

Before you began your career it is likely that all of the code you worked on was written by you from scratch. This code will be easy for you to understand because you wrote it. Now that you are working as an engineer you are more likely to be adding code to an existing codebase rather than writing code from scratch. This means that you will be working with code that you are not familiar with. It is important that you understand the code that you are changing before you change it. If not, then it is likely that you will break the code you are trying to change in a confusing way.

When I see a junior engineer with weak code comprehension skills they will get lost in the code. They will make a change that causes an error to occur or a test to fail. They will then have to debug the problem but because they didn't understand the change they made to the code, it is even harder for them to fix it. In the worst case this happens for every change they make and then it seriously slows them down. They get stuck in a cycle of change, break, debug, change, break, debug...

How to improve your code comprehension

To improve at code comprehension there is no substitute for just reading code. The more you read and understand the better you will become. That being said there are a few things you can do to help yourself along the way.

1. Ensure you understand the syntax of the code you are reading.

If you don't understand the syntax then you will struggle to read the code. Each language has its own way of laying out and describing code. Semicolons, braces, angled brackets, colons keywords, arrows, brackets and indentation may all hold meaning depending on the language you are reading. Learn these. If you find bits of code that you don't understand when reading it then make a note of these gaps. They are something you should learn and practice.

2. Use the navigation tools built into your IDE

Your IDE will have features designed to help you navigate code. They can help you move from a usage of a function to where the function is defined, they can help you to search code and move through windows and tabs quickly. Learn these features and shortcuts to help you move through the code easily. VS Code has a guide here and JetBrains has a guide here.

3. Understand the context

Before diving into the code, try to understand the context of the application first. What is the purpose of the app, tool or repo whose code you are reading? What are it's major features? Ask a colleague to answer these questions for you. It's much easier to decipher the code when you know what it is supposed to be doing.

Reading and understanding code is something that you will just get better at over time. I hope these tips will help you on that journey. It is important to persevere with this skill because it will help you become a better engineer. If your code comprehension is strong you will be able to add new functionality and debug issues more quickly. It will help you learn to appreciate well-written code and be able to develop a sense of what is well-written and what is not. All of this will help you as you move towards being a mid-level engineer.

Happy reading!

👋 If you like this article you might like my other series where I am building a tech debt management dashboard over the next 6 weeks. I am committed to building out in the open and will share progress on Dev.to. Including what is working and what is not working.

Follow my progress here: 🚀Velocity Pilot: 0 to 1000 users in 6 months

Asking for help - The 30 minute rule

Andrew Kelly — Thu, 23 Mar 2023 19:31:43 +0000

As a manager, a common pattern I see with Junior engineers is that when they run into a problem they will try to solve it on their own. They may spend a whole day going down all sorts of rabbit holes trying to get around the problem.

Most of the time people don't ask for help because they don't want their teammates to feel that they are being bothered by them. Believe me when I say that it is their job to be bothered by you and it is your job to bother them with questions. Your more senior teammates are expected to help out and share their knowledge and it is your job as a junior engineer to learn from them.

However it can be difficult to balance the trade-off between persevering with a problem or asking for help with it. That is where the 30 minute rule comes in.

The 30 minute rule

My advice is that if you have run into a problem and have not been able to get around it after 30 minutes then you must Ask. For. Help.

30 minutes is long enough to have ruled out simple mistakes by checking what you have done. It's long enough to have Googled any error message and tried out one or two possible solutions you find online. It means that you will have done some basic due diligence to try and get around the problem yourself. The benefit of spending this time is that you will know you have a legitimate issue that you can't easily get around. You won't feel like you're annoying your colleagues with trivial problems.

It's also a good idea to not spend less than 30 minutes trying to solve your issue. If you just ask for help as soon as you run into a problem you can waste the time of your colleagues if the problem you have has a trivial solution that is one Google search away. Also by not persevering and trying to find the solution yourself, you are denying yourself the opportunity to practice debugging. Debugging is a skill in it's own right and every problem debugged is an opportunity to hone this skill.

So don't waste your whole day. Use the 30 minute rule and accelerate your learning.

Follow my progress here: 🚀Velocity Pilot: 0 to 1000 users in 6 months

Photo by Gary Bendig on Unsplash