Structured Critical Reflection
What Happened? (Concrete Experience)
In week 8, Dhruhil showed me the accounts settings screen where inputs fields including the
address fields would not save in the database. With a week left before the deadline, the feature
was marked as high priority on Trello. During the lab session Dhruhil (backend developer) and
Trisha (frontend developer) worked with me to debug the problem. Address fields were in the
checkout table but not in the users address table. I noticed that the naming field conventions were
different (he used “Address Line 1 and Postcode” while my API needed “Address”). While
Dhruhil finished the checkout, I wrote temporary code to test the connection. When he messaged
“checkout is completed” I changed the layout to match the address requirements in the checkout
page.
What Was It Like? (Reflective Observation)
What frustrated me at first was the naming structure on the front and back-end. It caused us
problems close to the deadline. Working through the problem, I calmed down when I
understood the main issue. I was concerned about our lack of a standard front-end UI and a
singular address table. Poor communication led to isolated work. Dhruhil handled checkout,
while I focused on profiles but without alignment in our data structure. I wanted to blame
others at first but I realized I should have noticed the inconsistency sooner. This showed how
the independent approach affected our cohesion. When Dhruhil looked confused about the
issue, I realized I was being too technical. This made him lose interest. This revealed how one
choice impacts other components, overlooked in our team structure.
What Have I Learnt / Noticed? (Abstract Conceptualisation)
This experience helped me understand important concepts about software architecture and team
dynamics. I recognized that my perfectionism affected my communication. The inconsistencies
emphasized Fred Brooks’ “conceptual integrity” principle that the quality of a system comes from
concepts and their relationships applied in consistent ways throughout the system. This aligns with
Conway’s Law; he theorizes that organizations design systems that mirror their own
communication structure. I tend to focus on technical purity than rational collaboration which
mirrors what Donald Schön identifies as the "Technical-Rational" mode which too commonly
limits professionals. This dilemma of Perfectionism versus Realism is rooted in my fundamental
self-concept—I worry about code accuracy but must understand that computer programming while
written to run should be user-centric.
What Will I Do/Try Next? (Active Experimentation)
I see this as a learning experience that changed my software engineering style.
I will change cross-team communication with routine interface review meetings where
frontend and backend engineers show their implementations before integration. Through
making visual documentation which shows data flow between components, I will ensure
everyone understands the connection of fields from UI to database preventing naming conflicts
within fields by adopting a common vocabulary document. I realize how my own
communication impacts collaboration—I listen first before I repair, since technical repairs fall
short due to people miscommunicating. I've had feedback on my communications and
completed a showcase workshop to enhance those abilities. I learned that addressing
architectural challenges accelerates my growth as a developer rather than avoiding them.
What Happened? (Concrete Experience)
In week 8, Dhruhil showed me the accounts settings screen where inputs fields including the
address fields would not save in the database. With a week left before the deadline, the feature
was marked as high priority on Trello. During the lab session Dhruhil (backend developer) and
Trisha (frontend developer) worked with me to debug the problem. Address fields were in the
checkout table but not in the users address table. I noticed that the naming field conventions were
different (he used “Address Line 1 and Postcode” while my API needed “Address”). While
Dhruhil finished the checkout, I wrote temporary code to test the connection. When he messaged
“checkout is completed” I changed the layout to match the address requirements in the checkout
page.
What Was It Like? (Reflective Observation)
What frustrated me at first was the naming structure on the front and back-end. It caused us
problems close to the deadline. Working through the problem, I calmed down when I
understood the main issue. I was concerned about our lack of a standard front-end UI and a
singular address table. Poor communication led to isolated work. Dhruhil handled checkout,
while I focused on profiles but without alignment in our data structure. I wanted to blame
others at first but I realized I should have noticed the inconsistency sooner. This showed how
the independent approach affected our cohesion. When Dhruhil looked confused about the
issue, I realized I was being too technical. This made him lose interest. This revealed how one
choice impacts other components, overlooked in our team structure.
What Have I Learnt / Noticed? (Abstract Conceptualisation)
This experience helped me understand important concepts about software architecture and team
dynamics. I recognized that my perfectionism affected my communication. The inconsistencies
emphasized Fred Brooks’ “conceptual integrity” principle that the quality of a system comes from
concepts and their relationships applied in consistent ways throughout the system. This aligns with
Conway’s Law; he theorizes that organizations design systems that mirror their own
communication structure. I tend to focus on technical purity than rational collaboration which
mirrors what Donald Schön identifies as the "Technical-Rational" mode which too commonly
limits professionals. This dilemma of Perfectionism versus Realism is rooted in my fundamental
self-concept—I worry about code accuracy but must understand that computer programming while
written to run should be user-centric.
What Will I Do/Try Next? (Active Experimentation)
I see this as a learning experience that changed my software engineering style.
I will change cross-team communication with routine interface review meetings where
frontend and backend engineers show their implementations before integration. Through
making visual documentation which shows data flow between components, I will ensure
everyone understands the connection of fields from UI to database preventing naming conflicts
within fields by adopting a common vocabulary document. I realize how my own
communication impacts collaboration—I listen first before I repair, since technical repairs fall
short due to people miscommunicating. I've had feedback on my communications and
completed a showcase workshop to enhance those abilities. I learned that addressing
architectural challenges accelerates my growth as a developer rather than avoiding them.
