Personal Characteristics
- 🔥 Constantly striving for self-development;
- 🔥 Responsibility, precision and loyalty to the position;
- 🔥 Organization of the work process, teamwork;
- 🔥 Rapid assimilation of information and, accordingly, its adequate implementation in the working position;
- 🔥 Creative and innovative approaches in project development;
- 🔥 Constantly strives to develop and improve knowledge and skills on a professional and personal level;
Main Responsibilities
- 🔥 Create reusable code and libraries for future use
- 🔥 Developing and maintaining technical specification, architecture diagrams, and documentation
- 🔥 Maintaining a well-tested codebase with CI; robust unit and integration tests; test automation and QA process (Jest, Vitest, Cypress, Go Testify, etc.)
- 🔥 Optimization for maximum speed and scalability
- 🔥 Considering security in design and implementation
- 🔥 Driving technical depth and quality in solutions
- 🔥 Fostering team alignment on technical decisions and standards
- 🔥 Balancing delivery considerations with quality and sustainability
- 🔥 Ensuring consistency with existing codebase and practices
- 🔥 Development, implementation, maintenance and improvement of software applications
- 🔥 Participation in the design, scope, development and maintenance of features and components
- 🔥 Defining project requirements and developing work schedules for the team
- 🔥 Providing management assistance, including hiring, deploying, training, and team coordination
- 🔥 Strong sense of responsibility with a commitment to deliver quality results on time
Working approach
During my working day, I prioritize performance first, then architecture. Other factors I consider include maintainability, scalability, and team alignment. When proposals or opinions clash, I benchmark and test the options, compare performance and architecture, and choose the solution that scores best on both. I also seek a second opinion when it matters and document the rationale so the decision stays transparent and can be revisited. Context and use cases vary, but that is the approach I follow by default.
Conflict Solving Solutions
- 🔥 Benchmark / spike: When you disagree on approach (e.g. library, pattern), each side does a small proof-of-concept or benchmark. Compare results (performance, complexity, maintainability) and decide from that.
- 🔥 Proof of concept: Time-box a short POC for the disputed approach and evaluate against clear criteria.
- 🔥 Owner / DRI: For a given area, one person has final say (with input from others). Avoids endless debate.
- 🔥 Voting or consent: For low-stakes choices, use dot-voting or “no strong objection” so you can move on.
- 🔥 Assume good intent: Treat the other person as trying to do the right thing. Ask: “What problem are you solving?”
- 🔥 Clarify criteria: Agree on what “good” means (speed, security, simplicity, delivery date) before arguing solutions.
- 🔥 Second opinion: Involve a third dev or tech lead when two people are stuck. Fresh perspective often unblocks.
- 🔥 Time-box discussion: “We have 15 minutes to decide; if we can’t, we escalate to [tech lead / architect].”
- 🔥 Document and revisit: Capture the disagreement and decision (e.g. in ADR or ticket). Schedule a short follow-up if needed instead of dragging the meeting on.
- 🔥 Standards and style: Use shared style guides, linters, and conventions so many “taste” arguments never start.
- 🔥 1:1 conversation: Talk in private, focus on impact and behavior, not character.
- 🔥 Mediation: If two people keep clashing, a lead or manager facilitates a structured conversation and agreed next steps.
- 🔥 Separate “what” from “who”: Decide the technical outcome first; then assign who does it based on capacity and skills, not who “won” the argument.