Skills
Perseverance in software development is the ability to continue an investigation when the first fix only treats a symptom, documentation does not cover the case, or a solution requires several trial cycles. It combines endurance, method, and memory of the path already taken: reproduce the defect, formulate a hypothesis, collect evidence, change one useful variable, verify the result, and retain what was learned. Without that discipline, tenacity can become an expensive repetition of the same attempts.
I therefore distinguish perseverance from stubbornness. Continuing is worthwhile when each iteration reduces uncertainty or moves closer to an observable criterion. Changing direction is better when the architecture, scope, or initial assumption no longer holds. This skill matters especially in migrations, custom visualizations, and complex business rules, where an apparently working solution may still hide a data, security, or interpretation error.
After the critical December 2025 patch, further research uncovered several additional React Server Components vulnerabilities, including one patched on January 26, 2026. The episode shows that complex problems require verification and repeated iterations until variants of the original flaw are addressed too.
Read the source: ReactThe migration from Odoo 16 to Odoo 19 could not be performed in a single operation. Each move to versions 17, 18, and then 19 exposed new errors in internal modules, third-party extensions, XML views, or Studio customizations. I had to read Odoo.sh logs, locate the inheritance or field that had become invalid in the source code, adapt the customization, rerun the migration, and verify that the fix did not introduce another regression. Some officially updated extensions still failed and required a local correction or manual migration.
Result — The migration was completed after several months with data and useful functions preserved. Perseverance did not mean rerunning blindly: every resolved error enriched the inventory and made the next migration more predictable.
In CAP2vie, the trajectory had to represent exact or estimated periods, five dimensions, and two reading modes, then remain consistent when the interviewer corrected an answer from the form or directly from the chart. My first integration relied on an insufficiently explored resolution algorithm. The bridge between questionnaire data and D3.js became the most reworked part of the project. Instead of accumulating exceptions, I revisited response transformation, interval construction, and the way edits returned to shared state.
Result — The prototype delivered a visualization connected to the questionnaire, editable from two entry points, and usable in demonstrations. This experience taught me that perseverance may require rebuilding part of the architecture instead of protecting the first code written.
Invoice margin calculation did not exist in the form the company needed. Accounting entries, invoice lines, and business rules had to be reconciled while respecting Odoo's internal engine. Early versions required many discussions with accounting and source-code investigation to understand which events recalculated values. After the migration, a defect around invoice margins again showed that a correct result in one scenario did not cover every real data condition.
Result — Management can access margin indicators during the financial year instead of relying only on closing analysis. I still treat this calculation as an area for improvement: its delivered value is real, but its complexity requires further performance measurement and test cases.
The evidence items describe specific episodes. This synthesis places them back in the complete case studies: context, my contribution, and outcome show what this skill made possible, while keeping the appropriate level of caution for each result.
I assess myself as advanced because I stay engaged with long, uncertain, and technically unrewarding problems until I obtain a usable outcome. I can revisit an assumption, read framework source code, and accept rewriting work. My improvement area is to support that perseverance earlier with test scenarios, measurements, and a decision log so fewer iterations happen late.
My advice is to define what the next attempt should teach before starting it. If it produces no new information, the method must change: reduce the case, add traces, request business expertise, or revisit the architecture. Perseverance becomes professional when it reduces uncertainty rather than merely consuming time.
Retain this endurance while reducing the time needed to recognize a poor direction. I want to improve hypothesis formulation, automated reproductions, and the use of metrics that make it possible to stop an unproductive approach sooner.
