The phone numbers listing screen suddenly had its horizontal spacing removed. Looked weird, so flagged it in our internal Slack channel. Could be a small thing, perhaps the code owner missed during a manual verification pass or something along those lines. I pushed a fix for it.

Spent a lot of time planning out the changes for implementing a simplification for the concept of automations that exists in our system. Even after being handed an AI-generated wire-frame, I had to take a call on which data-model to re-use, what features to have on the listing page, the details page. I also had to take a call on how and where and if to link to an existing page on the newly proposed screens. The entire feature also requires a data migration, I've yet to think through how that's going to work. Currently decided to tackle the issue piecemeal.

Added a presentation layer for WhatsApp message delivery errors to make it more human-friendly, so that the user understand exactly what to do. For example, if the contact has opted out of marketing messages, instead of showing "This message was not delivered to maintain healthy ecosystem engagement", which could be a tad vague, we now show "WhatsApp did not deliver this marketing message to protect the recipient experience. Try again later." We will keep on improving the error message mapping.

I will keep my PRs that are not yet ready to be merged, even if from a implementation POV its "done". The other option is to update the PR title or add a header in the top of the PR body to flag that it's not to be merged. I wasn't done with verifying my changes in the browser, but the PR got merged. I need to signal to the entity (flesh-and-bones colleague or AI agent) that it's not to be merged yet more strongly. I'm assuming legit mistake by the entity who merged the PR, maybe they didn't read the PR body or the comment activity on the PR activity thread. I lost time that I could have used to work on a more impactful feature, due to managing multiple git worktrees and branches, since the merge pruned the feature branch from remote.

You clearly identified and categorised the issues - that's half the battle won

Added a preview CTA for WhatsApp messages with PDF attachments in our chat inbox UI. First cut I added an iframe based preview in the message container/component itself. This was my read of the task put up on Linear. After sharing the PR for review, I was told the "why" of the feature. This gave me extra context and shaped the next cut of the feature, which ended up being arguably simpler. Now, the preview CTA opens the browser's native PDF preview - we might later change it to use PDF.js for giving a consistent UX. Did not go with PDF.js right away cuz I decided we don't need a new dependency right away. We can revisit this decision if customers complain later down the line about inconsistent PDF preview UX across browsers.

I noticed one of my PRs that introduced a new KPI on an entity-level analytics tab got merged without having added screenshots to the PR body. This feature was something that I had driven purely with AI, and had parked last Friday with only manual verification left to do. When I ran the development server, I saw that a tooltip was styled incorrectly, so it rendered using the default browser styling. I so pushed a follow-up PR that made the UX better.

Focused practice is the way to go, I used similar strategy. Not for Spring Boot but for Rails. Leveraged AI as interviewer, used voice transcribing feature as if I was talking to an actual person - it helped.

I built support for a guard clause on pipeline enrolment automation - all the way from the UI, controller and back-end automation trigger code, which will skip pipeline item re-enrolment if said item is already part of another pipeline in a non-terminal stage, such as closed won/closed lost. Figuring out if the fix will actually work for the live customers. Customer ops team who triage customer issues across multiple pipelines, one automated by AI and another a human pipeline. This fix should help with the following scenario: Due to pre-existing automation, a pipeline item might get enroled in the AI pipeline. Human agent decided they need to take-over, so they transer the item to a terminal stage on the former pipeline to enrol them on the human pipeline. Their interaction with the customer re-triggers the automation that would re-enrol the item in the former pipeline, even though they're on the human pipeline. This guard clause fix should, in practice, allow the user to configure when not to re-enrol the item in the AI pipeline, to a certain degree.

I started work on consolidating multiple "edit" surfaces - basically multiple pop-ups for configuring a pipeline, things like metadata, pipeline stage configuration like stage order, name, colour etc. I "finished" when I merged all of the scattered product surfaces into a single, long, scrollable page - without considering that it will be quite cumbersome for a user to see such a big form. I got feedback during code review based on the screenshots I had uploaded. It made sense. I wasted the time it took to the get the implementation just right instead of thinking whether even is it the right UX for my user. Lesson learnt, will start my asking coding agent to give options for UIs and make concious effort to see if the UX might be good/bad. Will also ask designer colleague to eyeball it, even that I forgot unfortunately...

Built changes in the overview page of our pipelines feature - it was a copy change, which would make it more intuitive for customers to navigate to the logical first step in any lead/customer success pipeline, which is seeing how many "items"/"leads"/"customers" are there in a pipeline's stage. Also simplified the UI by removing cards that showed stage-specific item counts on the overview page.

I noticed that new accounts that onboard on our platform might not have a specific setting configured which would cause our pipelines feature's item short id generation logic to be skipped - pushed a fix for the same. Now, we fallback to a generic value for the setting. This was important because asking the user to configure the setting isn't surfaced yet during our onboarding. This edge case came to my mind during morning shower.

Even if you have the resources, your attention cannot be or rather shouldn't be divided between doing multiple things - focus is paramount. In other words, "There are lots of things you can do, but it’s doesn't mean you should." Paraphrased from Seth Godin's blog titled "Resources and focus".

With the help of a coding agent, went about architecting pipeline analytics for stuff like First Response Time (FRT), Time in Stage (TIA) etc. Understood the current product surface, looked at the proposed UI changes with the help of the agent, and understood the proposed solution before sharing with the team to request for comments on the architecture and UI. Leveraging the artefact generated by the coding agent cut down the discussion from what needed to be built to what needed to be removed/simplified.

I noticed a Sentry issue some time after deployment of the new disposition tracking changes. I used a coding agent to try to reproduce the issue locally - I asked it to fetch the traces, breadcrumbs etc from Sentry MCP and then asked it to first list the manual verification steps. After reading through said steps and ensuring they made sense, I asked it to use the Browser integration to verify if the issue was legit or not. I came to the conclusion that it was a browser-cache related issue, but I am still keeping an eye out for regressions.

I built a way for customer ops folks to track disposition fields on pipeline stage transitions so that they can record won/lost reasons or track additional metadata within our product itself.Fixed the UX of the current implementation for disposition fields too along with this new feature and deployed it as well.Hopefully customers start using it and provide feedback if anything needs improving.

I'm stuck on a task for attributing the creator of an item added to a pipeline, initially the task had a defined scope.During code review it seemed like the product requirements were different. We wanted to track the source of the pipeline item in a more generic way, have yet to come up with a solution.Had to put the PR in draft state.

I built an improvement for our automation rule configuration screen which now allows the user to select the automation trigger condition using a simple Select2 drop-down component.I also simplified an existing part of the automation UI, viz. merging two distinct UI cards within the same section because conceptually they were supposed to be linked, even if the back-end data modelling is done differently.

I built a simplification of an existing status-based filter that should hopefully signal to the user which items need immediate attention on the pipeline.

I'm stuck on releasing one feature for the past 3-4 days.Thankfully it didn't block me from releasing other features/improvements.Every iteration I asked the agent if we missed anything - which brought up certain considerations that I had missed during the planning phase.One core assumption was also changed during review, due to which I had to plan out one more round of refactoring.

I flagged how some of our Linear tasks did not describe the issue accurately because vagueness is part and parcel of solving problems but when even an agent doesn't understand the issue from the Linear task title or body, that's the point I question whether the issue to solve was described properly.

I learnt instead of forcing customers to not go to other vendors, keeping that "captive", might have the opposite effect from Seth Godin's blog titled "A captive audience".

I built a fix for our shared chat inbox UI's load more feature replacing the already loaded chat activities (messages, order statuses, agent assignment) with the requested page of chat activities

I built short-IDs for lead/customer pipeline items that are searchable and copy-able with the ability to configure the short-ID prefix at the tenant and pipeline level

I learned that the agent harness can potentially move the needle in terms of task completion and cost from Databricks' article featured on Hackernews titled "Benchmarking Coding Agents on Databricks' Multi-Million Line Codebase"

I built a way to configure automations for lead tracking on the product's pipeline/stage tracking UI surface. Product already had a separate UI to configure automations but we wanted to make it easier for users to configure pipeline related automations from the pipelines UI itself.

[Interview] Advanced Nikhil at Q5

I built a simpler way to trigger automations for inbound and outbound messages on WhatsApp Business App numbers

I learned "The engineers who thrive won't be the ones who generate the most code, they'll be the ones who understand the systems they build" from a blog titled "Do you understand your Code?"

I learned what are entities in a domain-driven design and how it's supposed to be used to track continuity and state changes for a domain model from the blue book (DDD by Eric Evans)