A Week in the Life of a Busy Developer – 2021 vs. 2022 vs. 2023

A Week in the Life of a Busy Developer - 2021 vs. 2022 vs. 2023

2021 – It’s just you and your IDE

Day 1 – It’s a lovely, exciting Monday morning at meetingdeadlines.io. You just came out of a meeting where the product manager introduced the features for the following week. You’re already pumped with ideas on how to implement it and happy that some of the irritating product problems are addressed. You still don’t have any product definitions to work by because the product team needed your feedback to finalize the content. Actually, you still need to provide some assessments and do some research, so you won’t be idle today.

What have you been doing: Meetings and some research

Day 2 – The day started with a bug reported by one of the testers, which relates to last week’s delivery. Nothing major, but it does require your attention. It took a couple of hours to find it and another two hours to fix it, write tests that could have detected it and deploy the fix. Apparently, if you had devoted more time to testing beyond the two happy-path cases you prepared, it could have saved this morning. You head back to research and get a good feeling about the feasibility of this week’s content. You present the rough estimations to the product team and added one day for code testing. You start coding. No product definition yet, so you start with general infrastructure work.

What have you been doing: Bug fixing, and some more research

Day 3 – You’re in the zone; other than some small interruptions, you are done with the infrastructure you needed to implement this week. Still no written product requirements, but you’ve been in the meetings and the discussions, so you have a rough idea of how to implement some of the features.

What have you been doing: 98% of infrastructure work is done, and 30% of the features

Day 4 – You start coding; documentation is underway, but most details are missing. This starts to slow you down, and you need to surface many missing details about the product. Misunderstanding the product team’s intent wasted some time as well. Your colleague offers you to use this week to practice TDD, but you refuse: not this time. You only have two days to the end of the week, and some unexpected challenges are surfacing. Also, the documentation isn’t quite ready.

What have you been doing: 70% of the week’s features are ready

Day 5 – Gladly, most challenges are solved by the early afternoon, and you start thinking about your weekend plans. But you still got a couple of hours to go, so you start checking your code. First, you inspect it for one hour and then invite your colleague to code-review it. He is surprised that you don’t have tests yet. You add a couple of happy path tests and one edge case, then perform a pull request. The code coverage is high, but your confidence that the code you delivered is bug-free is low.

Overall – 5 days:

  • Meetings & Research: 1 day
  • Bug fixing: 0.5 day
  • Coding: 2.75 days
  • Writing tests: 0.25

Confidence level: Low

2022 – You’ve started using GitHub Copilot and ChatGPT

Day 1 – It’s a lovely, exciting Monday morning at meetingdeadlines.io. You just came out of the meeting where the product manager introduced the features for the following week. Your company has recently acquired GitHub Copilot and ChatGPT licenses for its developers. It’s going well; you’re gaining confidence in the results and the time it saves you. You still don’t have any product definitions to work by because the product team needed your feedback to finalize the content, actually, you still need to provide some assessments and do some research, so you’re not going to be idle today. Using ChatGPT for the research phase really speeds things up; you complete your research by the end of the day.

What have you been doing: Meetings and finished research

Day 2 – This day started with two bugs reported by one of the testers, which relate to last week’s delivery. Nothing major, but it does require your attention. It took half a day to find and half a day to fix it, write tests that could have detected it and deploy the fix. Apparently, both bugs were in areas of code that the coding assistants produced, and although you did go through the generated code, it wasn’t thorough enough to detect it. You keep a mental note that you must invest more time reviewing the results or producing more tests. Actually, you had quite a few automatically generated tests that ChatGPT produced for you, but you deleted most of them because they didn’t run or were just wrong. Eventually, you were left with five trivial tests that weren’t able to detect these bugs. A wasted day, but with your new accelerated development, you’re confident you will finish your tasks on time. No product definition yet, but that’s ok.

What have you been doing: Bug fixing

Day 3 – You’re in the zone. Other than some small interruptions, you are done with the infrastructure you needed to implement this week. Written documentation is starting to materialize in the shared document (The product team has been adopting ChatGPT as well). Using GitHub Copilot really speed things up, and by the end of the day, you’re done with the infrastructure and half of the week’s features.

What have you been doing: 98% of infrastructure work and 50% of the features are done.

Day 4 – You start the day by reviewing the auto-generated parts of your code and writing some trivial and edge cases tests for your code. You continue coding, and documentation is ready; nothing can slow you down. However, some misunderstandings still occur between the product team’s intent and what you understood, which wastes some time. Your colleague offers to use this week to practice TDD since the documentation is ready, and half of the code isn’t written. You agree, but it seems that writing tests that validate spec and writing code are two different ball games. Since you still need to complete half of the features, you move back to coding.

What have you been doing: 100% of the week’s features are ready

Day 5 – Gladly, you have the whole day for testing and inspecting quite a lot of code. Now it is more important than ever since large portions of the code were written automatically. You finish the tests before the end of the day, and you feel an overall productivity improvement over the previous year, although the tasks took roughly the same time as before. You now have more time to validate your code and write more meaningful tests. Your confidence is high, but it is only because you invested a lot of time in testing your code. You don’t really have a choice since code completion doesn’t always catch your intent or produce bug-free code.

What have you been doing: Code inspection and writing tests

Overall – 4 days:

  • Meetings & Research: 1 day
  • Bug fixing or Writing tests: 1 day
  • Coding: 2 days

Confidence level: Medium (you invested a lot in testing but do not know how meaningful the results are)

2023 – You’ve started using qodo (formerly Codium)

Day 1 – It’s a lovely, exciting Monday morning at meetingdeadlines.io. You just came out of the meeting in which the product manager introduced the features for the following week. You now have a lot of experience with GitHub Copilot and ChatGPT, and it’s going well. You understand their value, but you’re also familiar with their limitations. You now devote more of your time to writing meaningful tests, so you decided to install qodo (formerly Codium) to help you with that, and it’s going great. You still don’t have any product definitions to work by because the product team needed your feedback to finalize the content. Actually, you still need to give back some assessments and do some research, so you won’t be idle today. Using ChatGPT for the research phase really speeds things up; you actually complete your research by the end of the day.

What have you been doing: Meetings and finished research

Day 2 – Because of the thoroughness of the tests, no bugs were discovered by the testers this week. You’re eager to try TDD, but the product definitions aren’t ready yet. But, unlike previous years, a) the product team knows that product definitions expedite the development, so they are super motivated, and b) you, as a creator, are now part of the definition process, so product definitions are ready by the end of the day. Until then, you have enough on your plate to start with; you use GitHub Copilot to speed up your infrastructure work. For any finished code component, you use qodo (formerly Codium) to generate the tests for you. You discover some bugs and fix them, feeling confident by the end of the day to move to other features.

What have you been doing: 98% of infrastructure work is done.

Day 3 – Product documentation is ready. You ran qodo (formerly Codium) on yesterday’s modules alongside the documentation and got more insightful, meaningful, and thorough tests. You also started practicing TDD regularly now that you can instantly create tests from documentation, existing code, and function headers. With qodo (formerly Codium), you were able to generate tests for code you still haven’t written and discover bugs as GitHub Copilot completes your code. By the end of the day, you’ve finished most of the features.

What have you been doing: 70% of the week’s features are ready

Day 4 – You have finished the remaining tasks by lunchtime, all the tests are already written and passed, and you’re ready to perform a pull request and move on to your next tasks.

What have you been doing: 100% of the week’s features are ready

Overall – 3.5 days:

  • Meetings & Research: 1 day
  • Bug fixing or Writing tests: 0.25 day
  • Being involved in product definition: 0.5 day
  • Coding: 1.75 days

Confidence level: High (you didn’t invest a lot of time in writing tests, but you know you’ve got meaningful tests from qodo (formerly Codium))

More from our blog