Three things I appreciate more now that I'm coding.
This week: I now understand why you all hate updating JIRA.
Over the last couple of weeks, I’ve been chipping away at my dev project and having a great time with it. At times, I’m a little heavy on the Copiloting. Still, based on the features I’ve been building and how each is slightly different in nature, I have needed to get resourceful and dig deep into those dev forums to see how I can string it all together and drive the outcomes. I’ll share a few of these below.
Even though I’m running a project for myself and self-imposing all the deadlines, I realized a few things I wanted to share. So, in addition to the updates this week, I want to share these thoughts in a “retrospective/gaining empathy for the people who do this for a living” type of way.
First, let’s hit on the progress I’ve been making in what we’ll call Sprint 2.
Current Progress
Set Up on Google Cloud Platform (GCP): This week, I configured GCP to host my project, allowing me to push my code to the web and make it accessible. It’s been a major step forward in getting the project fully operational. I tried several platforms (Heroku, my own web hosting Cpanel) but struggled to get them up and running, so configuring GCP and seamlessly updating worked well for me.
Live Testing Enabled: After successfully pushing the project into production, I ran end-to-end testing on each of the features and tweaked them along the way. It was rewarding to see everything in action, making it feel like the project was coming together.
Next Steps: I plan to add an option for outputting results to a user-provided email address and set up a database to store contact information securely. These additions will enhance the project's functionality and scalability. I’m not quite sure what database situation I’m going to go with, so if you have any recommendations, let me know.
As I mentioned, being the all-in-one person for a project like this means you need to decide how far you want to go to recreate what it’s actually like at work. I thought it was important to understand better what my engineering partners go through, so I went all out with JIRA, full-on CI/CD, and all the other bells and whistles. I wanted to make it feel like a best-case-scenario experience.
However, I did find a few things pretty enlightening about running the project this way. Let’s explore three of my biggest realizations so far.
Realization #1: Constantly Updating JIRA (or any tracking tool) sucks.
Keeping project details in order on a tool like JIRA feels necessary but can also be disruptive. There’s a tension between focusing on the work itself and documenting every change, especially when working solo.
I found that every time I’d get into a flow, breaking to update JIRA slowed my progress and made it harder to re-enter that productive “zone.” But I’ve also seen the downside of not updating it regularly - losing track of minor details or overlooking something critical is more manageable.
I’ve come to appreciate JIRA updates as a balance: keeping them minimal but meaningful is key. Instead of logging every single small step, I capture key milestones and blockers so the record reflects real progress without clutter.
This experience has shown me that the process can’t always be as granular as in larger teams but can still be effective without becoming burdensome.
Realization #2: Focus and ‘getting in the zone’ are non-negotiable.
The second lesson hit hard - focus time is essential when working on complex problems.
Meetings, even when spaced out, can disrupt the creative problem-solving process. I’ve realized that entering a flow state, where the work feels almost effortless, is critical for coding or problem-solving, especially when working solo without immediate team input. Once in that zone, I can work faster and more effectively.
To guard my focus, I’ve started setting designated “focus blocks” on my calendar, treating them as unmovable. I’ve also begun cutting down on multitasking during these blocks by turning off notifications and committing to work on only one specific task at a time. It’s a productivity boost that’s hard to replicate with fragmented time.
This project has underscored the need to protect my focus fiercely, something I now see as essential to consistent progress.
Realization #3: Sometimes, you just need to step away.
There’s a certain irony in needing a break to
solve a problem, but it’s been a recurring theme in this project. I’ve had moments where staring at the same code block for too long only confused the problem. Stepping away—even for 15 minutes—often allows my mind to reset, and I return with fresh ideas and insights that weren’t there before.
Taking a break can also be a way to solve problems indirectly. I’ve found that going for a quick walk or doing something entirely unrelated to coding can create those “aha” moments.
It’s easy to forget that breaks aren’t just pauses in productivity; they’re often catalysts for problem-solving. This has been a reminder of how important pacing is, particularly in solo projects where there’s no one to tag in for a fresh perspective.
Final Thoughts
Working solo on this project has taught me much about balancing the “admin” work with the actual coding. Trying to keep JIRA updated without losing focus on the building has shown me why a lighter touch - focusing on key milestones and blockers - can still be practical without the drag of constant updates.
And honestly, I now see why keeping meetings tight, with only essential people, can help maintain momentum. Wearing all the hats has given me new respect for the focus needed to get in the zone and the value of stepping away when things get stuck.
Until the next sprint.