Scenario: You are a junior developer at a health-tech start-up. Your manager asks you to ship a patient-monitoring feature by Friday, but your testing reveals a bug that causes the system to misreport critical vital signs roughly 2% of the time. When you raise it, your manager says, "It's a small percentage — we'll fix it in the next sprint."

Structured ethical analysis:

Outcome (illustrative): The manager, seeing the formal documentation and the involvement of compliance, agrees to delay the release by one week. The bug is fixed. Your professional reputation is enhanced — not damaged — because you demonstrated judgement and courage.

Key principle: When ethics and business interests conflict, document, escalate, and propose solutions. Silence is complicity.

Scenario: A senior colleague asks you to review their code before merging. You find a hard-coded API key in a public repository. The colleague says it's "just a test key" and that removing it will delay the release by a day.

Recommended action: Decline to approve the pull request. Explain clearly that the key must be moved to environment variables, and offer to help make the change in 15 minutes. Also recommend that the key be rotated immediately if it was ever pushed publicly. This is both ethically correct and constructive.

Scenario: In a four-person college project, two members want to use Flutter for the mobile app; two want React Native. The project has stalled for a week.

Position-based approach (fails): Each side argues for their preference. Neither is willing to concede. The team spends another week arguing.

Interest-based approach (succeeds):

Outcome: The team decides to build the POC option — each side builds one screen in their preferred framework over 3 days, then the team evaluates against the criteria. React Native wins by a small margin on development speed, and both factions accept the decision because it was based on evidence, not argument.

Time cost: 3 days for the POC. Time saved: 1+ week of continued deadlock. The POC is not wasted — the code becomes the starting point for the project.

Scenario: A production incident takes down the college fest registration system for 2 hours on the day registrations open. The junior developer whose change caused the outage is terrified.

Blameless post-mortem:

Blameless conclusion: The developer who changed the registration flow made a reasonable code change. The failure was systemic — the team had no load-testing practice, no alerting, and no rehearsed rollback. The post-mortem identifies three action items: (1) implement basic load testing in CI, (2) add alerting on p95 latency and error rate, (3) rehearse the rollback procedure quarterly. The developer is not named in the report.

Why blameless matters: If the developer had been blamed, the next developer would hide their mistakes — and future incidents would be detected later and cost more. Blameless post-mortems are a practical engineering choice, not merely a compassionate one.

Project: Build a college event registration system in 8 weeks.

Path analysis:

Result: Both paths are 33 days — this is a coincidence and means the project has two critical paths. The project duration is 33 days (≈ 6.6 weeks at 5 working days/week), leaving roughly 1.4 weeks of buffer within the 8-week deadline.

Implication: Any delay on either path delays the whole project. The project manager should:

• Monitor tasks B, D, C and E carefully — these are the highest-risk items.
• Consider assigning the most reliable team members to D and E.
• Add a small contingency (2–3 days) to the schedule to absorb minor overruns.
• If a delay occurs on one path, add resources to the other to keep them aligned.

Project status at end of week 4:

• Planned Value (PV) = ₹80,000 (the budgeted cost of work scheduled by now)
• Earned Value (EV) = ₹60,000 (the budgeted cost of work actually completed)
• Actual Cost (AC) = ₹75,000 (what has actually been spent)

Analysis:

\[ \text{CV} = 60{,}000 - 75{,}000 = -₹15{,}000 \] (over budget)

\[ \text{SV} = 60{,}000 - 80{,}000 = -₹20{,}000 \] (behind schedule)

\[ \text{CPI} = \frac{60{,}000}{75{,}000} = 0.80 \]

\[ \text{SPI} = \frac{60{,}000}{80{,}000} = 0.75 \]

Interpretation: The project is significantly over budget and behind schedule. For every ₹1 spent, only ₹0.80 of value has been delivered. At this rate, the project will require approximately \(1/0.75 \approx 1.33\times\) the original time, and \(1/0.80 = 1.25\times\) the original budget if no corrective action is taken.

Recommended actions: (a) investigate the cause of the overrun — was the estimate too optimistic, or is there rework? (b) review remaining scope for opportunities to reduce; (c) consider adding resources or reducing scope to bring schedule back; (d) re-baseline the plan with revised estimates and communicate openly with the sponsor.

Actions: The highest-scoring risks (12–15) receive the most attention. Deployment rehearsal is scheduled for two weeks before the deadline. Documentation is maintained continuously, not written at the end.

Epic: Notice Management for the Campus Notice Portal.

Total for this epic: 19 story points. If the team's velocity is 20 points per two-week sprint, this epic can be delivered in one sprint with a small buffer.

Data from the last four sprints: 24, 28, 26, 22 story points.

\[ \text{Average Velocity} = \frac{24+28+26+22}{4} = 25 \text{ points/sprint} \]

Remaining backlog: 187 points.

\[ \text{Sprints Remaining} = \frac{187}{25} = 7.48 \rightarrow 8 \text{ sprints} \]

With two-week sprints, the release is approximately \(8 \times 2 = 16\) weeks away.

Engineering note: Add a buffer of 1–2 sprints for integration, hardening and unplanned work. A commitment of 18 weeks externally with an internal plan of 16 weeks is a professional approach — it protects credibility while maintaining focus.

Interpreting variance: The velocity range (22–28) shows ~27% spread. If the lowest velocity (22) is used for forecasting instead of the average, the estimate becomes \(187/22 \approx 8.5 \rightarrow 9\) sprints (18 weeks). This conservative approach is preferable for external commitments.

Title: CampusCare — A Student Mental Health Support and Resource Platform

Problem statement: University counselling services are under-resourced, with typical wait times of 2–3 weeks for an initial appointment. Students who need immediate support often do not know where to turn, and stigma prevents many from seeking help. A digital platform can provide immediate access to vetted self-help resources, anonymous peer support, and a streamlined appointment booking system — reducing the barrier to the first step.

Objectives:

1. Design and deploy a web platform accessible to all students via university SSO.
2. Provide a curated, professionally reviewed library of mental health resources organised by common concerns.
3. Implement anonymous peer-support forums moderated by trained student volunteers.
4. Build a booking system integrated with the counselling centre's calendar, reducing appointment scheduling time from 15 minutes to under 2 minutes.
5. Achieve adoption by at least 300 students within the first three months.

Scope: Includes resource library, anonymous forums, appointment booking, and crisis-hotline integration. Excludes: telehealth/video sessions, clinical record management, and integration with external health systems.

Methodology: Agile with two-week sprints; React + Node.js + PostgreSQL; deployed on a PaaS; continuous integration via GitHub Actions.

Timeline: 14 weeks — Requirements (2), Design (2), Implementation (6), Testing (2), Deployment and documentation (2).

Team roles: Product owner (student lead), two full-stack developers, one designer, one QA and documentation lead.

Resources: GitHub, free-tier cloud hosting, Figma, university SSO credentials, counselling centre staff as domain advisors.

Top risks: (1) Ethical/privacy concerns — mitigate with data minimisation, anonymous forum design, and a formal ethics review; (2) Low adoption — mitigate with a student ambassador programme and integration with orientation week; (3) Content quality — mitigate by getting all resources reviewed by a qualified counsellor; (4) Moderation burden — mitigate with trained volunteers and clear escalation procedures; (5) Scope creep — mitigate with formal change control.

Expected outcomes: A functioning platform used by at least 300 students in the first three months, with appointment scheduling time reduced by 80% and positive user feedback (NPS ≥ 30) on the resource library. All source code published under an open-source licence.

Ethical considerations: Strict privacy and data minimisation (no tracking, no third-party analytics); anonymous forums with clear moderation guidelines and escalation for crisis situations; all resources reviewed by qualified professionals; prominent crisis hotline information available on every page.

Situation: You are an SDE-1 at a fintech company. Two days before a major release, you discover a vulnerability in a payment module: under a rare race condition, a transaction could be double-charged. It would take approximately three days to fix properly. The release is a major product milestone and delays would be very visible to the CEO.

Analysis:

Recommended action:

1. Document the vulnerability with a reproducible test case. This is essential — an undocumented bug report is easily dismissed.
2. Estimate the impact quantitatively: "In stress tests, the race condition occurred 3 times in 10,000 transactions. At projected volume, that is approximately 200 affected transactions per day."
3. Present options, not just the problem. Recommend option (b) — ship the rest of the release, disable the affected feature, and enable it after the fix is verified.
4. Escalate through channels if the manager dismisses the concern: send the report in writing to the manager with a copy to QA leadership. If still dismissed, escalate to the engineering director.
5. Do not go around the chain of command to the CEO, but document your escalation so responsibility is clear.

Outcome: The manager accepts option (b). The release ships on time without the vulnerable feature; the fix is deployed three days later. Your professional reputation is enhanced — you showed both technical judgement and the ability to find a path that respected business constraints.

Key lesson: Escalate with options, not just objections. A junior engineer who raises a problem and proposes a solution is far more persuasive than one who simply blocks progress.

Situation: A three-person team delivers a college project. During the final presentation, one member — the team lead — presents all the work as "our team's achievement" but subtly implies that the technical design and implementation were primarily his. In reality, the other two members did the bulk of the implementation; the lead coordinated and wrote the report.

Analysis:

• Is the lead's behaviour unethical? Yes — it violates the principles of fairness and professional integrity. If he presents in a way that misleads, he misrepresents contribution.
• Is coordination less valuable than coding? No — coordination and documentation are essential contributions. The issue is not that the lead didn't contribute; it is that he minimised the contributions of others.
• Should you confront the lead publicly? No — a public confrontation damages the team and the presentation. Address it privately afterwards.

Recommended action:

1. During the presentation, if asked directly, respond factually: "I implemented the backend API, and [colleague] built the front-end." Do not contradict the lead publicly.
2. After the presentation, speak with the lead privately: "In the presentation, I felt our specific contributions weren't clear. For the report, can we include a contribution table that lists exactly who did what?"
3. In the written report, include a contribution matrix. This is standard practice in professional projects and protects everyone.
4. If the lead continues to claim disproportionate credit (e.g. in job applications or scholarship essays), consider addressing it with the faculty supervisor. But only if the pattern continues and affects you materially.

Key lesson: Contribution should always be documented. In professional teams, this is normal — it is not a sign of distrust but of professional practice.

Situation: During a code review, a senior colleague says your code is "poorly structured" and requests significant refactoring. You believe your structure is fine and that the senior is applying a personal preference, not a technical requirement.

Analysis:

• Is this an ethics issue? Not directly, but how you respond reveals professional maturity.
• What is at stake? The quality of the code, the working relationship with the senior, and your reputation as a collaborator.
• What are the interests? The senior wants maintainable code that matches team standards. You want your work respected and to avoid unnecessary rework.

Recommended action:

1. Ask clarifying questions: "Can you point me to specific issues? Is there a team style guide that specifies this?"
2. If there is a style guide, follow it. Team standards supersede personal preferences.
3. If there isn't a style guide, ask: "Would it be helpful to write one down? That would help future reviews." This transforms a personal critique into a team improvement.
4. If, after discussion, you still disagree, you have two choices: (a) implement the senior's preferred structure (low cost, preserves relationship) or (b) escalate to a tech lead for a decision. Option (a) is usually correct for style preferences; option (b) is for technical concerns that affect performance, security or correctness.
5. Never argue at length about stylistic preferences. Save your energy for issues that matter.

Key lesson: In professional environments, choosing your battles is a skill. Style disagreements should be resolved by standards; technical disagreements should be resolved by evidence.

Situation: You work on an e-commerce analytics team. Your manager asks you to build a model that predicts users' likelihood to purchase based on the time of day they browse. The data includes purchase history, which is fine, but you also notice that the dataset includes location data collected for delivery purposes — not for marketing. Using location as a feature could improve the model's accuracy but was not disclosed to users in the privacy policy.

Analysis:

Recommended action:

1. Raise the concern with your manager directly: "I noticed we would be using location data, which was collected for delivery. Should we confirm with legal that this is within the policy?"
2. Propose a solution: build the model without location and present both versions with the accuracy difference. If the gain is marginal, the ethical decision is clear.
3. If the gain is significant, the correct path is to update the privacy policy and provide users with clear notice — not to quietly use the data.
4. If the manager directs you to proceed regardless, escalate to the privacy officer or legal team. Document the concern.

Key lesson: Data collected for one purpose should not be used for another without disclosure. The right question is not "can we technically do this?" but "should we, and would users approve if they knew?"

Situation: In a four-person capstone team, one member consistently misses deadlines, does not respond to messages, and has not committed to the repository in three weeks. The rest of the team is covering their work, and frustration is high. The final submission is in four weeks.

Analysis:

• Is this a personal failing or a systemic issue? Possibly either. The member might be struggling with personal circumstances, or might simply be disengaged.
• What is the team's obligation? Both to the project and, to a reasonable extent, to a struggling teammate.
• What are the consequences if ignored? Team morale suffers, other members burn out, and the project quality drops. If the situation continues, the supervisor should be informed.

Recommended action:

1. Hold a private, non-confrontational conversation. Ask open questions: "I've noticed you haven't been able to contribute lately. Is there something we should know about?" Do not accuse; seek to understand.
2. If the member reveals a genuine difficulty (health, family, workload), the team can adjust expectations or reassign tasks. This is both ethical and practical.
3. If the member reveals no issue and simply has not prioritised the project, restate the expectations and offer support: "We need X by Friday. Is there anything blocking you?"
4. If behaviour does not change within a week, involve the faculty supervisor. Provide documentation — task assignments, communication logs, commit history. This is not "telling on" the member; it is protecting the team's work and the member's opportunity to rectify the issue.
5. If the member ultimately does not contribute, request that the grading reflect individual contribution — most institutions permit this.

Key lesson: Address problems early and directly. Silence and resentment compound; early conversation usually resolves more than expected.

Definition: Professional ethics is the set of principles, values and standards of conduct that guide the behaviour of individuals within a profession. It defines what is right and wrong in professional practice, beyond what is merely legal or personally convenient.

Six core principles with examples:

1. Integrity — being honest and consistent in words and actions. Example: reporting a bug you introduced rather than hoping it goes unnoticed.
2. Objectivity — making decisions on evidence, not personal interest. Example: recommending a technology because it is technically superior, not because a friend works there.
3. Confidentiality — protecting information entrusted to you. Example: not discussing customer data or unreleased products outside the workplace.
4. Competence — maintaining the knowledge required for your role. Example: declining a task outside your expertise and requesting training.
5. Professional behaviour — treating colleagues with respect. Example: disagreeing with an idea without attacking the person who raised it.
6. Accountability — taking responsibility for your actions. Example: acknowledging a production outage caused by your change and driving the fix.

Application to the scenario:

Recommended action: (1) document the vulnerability with a reproducible test case; (2) quantify the impact; (3) escalate in writing to your manager with a proposed mitigation; (4) if dismissed, escalate further with a retained record; (5) never ship known-vulnerable software silently.

Why Storming is necessary: Storming surfaces genuine disagreements about roles, methods and priorities while the team is still forming. Teams that suppress this phase carry unspoken resentment and unexamined assumptions into later stages. In Storming, positions are tested, roles are clarified and a real consensus emerges — one that is based on discussion rather than assumed agreement. The goal is not to avoid conflict but to manage it constructively, ensuring it focuses on ideas rather than personalities.

Interest-Based Relational (IBR) approach:

1. Separate people from the problem.
2. Focus on interests, not positions.
3. Generate options for mutual gain.
4. Insist on objective criteria.

Application to a technology disagreement:

Outcome: a POC decision based on evidence, accepted by both sides because the criteria were agreed in advance. The conflict becomes a technical evaluation rather than a personal contest.

Definition: Psychological safety is the shared belief that team members can take interpersonal risks — ask questions, admit mistakes, challenge ideas — without fear of punishment or humiliation. It is one of the strongest predictors of team effectiveness.

Why it improves performance:

• Members raise problems early, when they are easy to fix.
• Junior members contribute ideas that would otherwise go unspoken.
• Bad news travels fast and is treated as a system problem rather than a personal failing.
• Calculated risk-taking and experimentation are encouraged, driving innovation.
• Learning is continuous; defects are caught early and cheaply.

Blameless post-mortem for a production incident:

Conclusion: the developer made a reasonable code change. The failure was systemic — no load testing practice, no alerting, no rehearsed rollback. Action items: implement load testing in CI, add alerting on p95 latency and error rate, rehearse rollback quarterly. The developer is not named in the report.

Why blameless matters: if the developer had been blamed, future developers would hide mistakes — and incidents would be detected later and cost more. Blameless post-mortems are a practical engineering choice, not merely a compassionate one.

Triple constraint: Quality = f(Scope, Time, Cost). The three constraints are interdependent.

Example: A team building a college fest app is asked by the coordinator to add a payment gateway two weeks before launch. Scope has increased. To absorb it within the same deadline (time fixed), the team must either (a) drop an existing feature to make room (reduce scope), (b) bring in extra developers (increase cost), or (c) ship the payment feature without full testing (reduce quality — which is unacceptable for payment processing). The honest answer is (a): drop a lower-priority feature to make room for the payment module, or negotiate a delayed launch.

Five project life cycle phases:

Definition: Scope creep is the uncontrolled expansion of project scope without corresponding adjustments to time, cost or resources.

Three prevention methods:

1. Clear scope statement — write an explicit scope document at the start, listing in-scope and out-of-scope items. This makes new requests obviously out of scope.
2. Formal change control process — every proposed change is documented, assessed for impact on time and cost, and formally approved or rejected by the project sponsor.
3. Disciplined delivery — build exactly what was specified. Resist gold plating — the temptation to add features that were not requested but seem interesting.

WBS for a college event management system (three levels):

1.0 Event Management System
├── 1.1 Requirements
│   ├── 1.1.1 Stakeholder interviews
│   └── 1.1.2 Requirements document
├── 1.2 Design
│   ├── 1.2.1 Database schema
│   ├── 1.2.2 API specification
│   └── 1.2.3 UI mockups
├── 1.3 Implementation
│   ├── 1.3.1 Event creation module
│   ├── 1.3.2 Registration module
│   ├── 1.3.3 Payment integration
│   └── 1.3.4 Notification service
├── 1.4 Testing
│   ├── 1.4.1 Unit tests
│   ├── 1.4.2 Integration tests
│   └── 1.4.3 User acceptance testing
└── 1.5 Deployment
    ├── 1.5.1 CI/CD pipeline
    ├── 1.5.2 Production deployment
    └── 1.5.3 Documentation and training

Given tasks: A (5d), B (4d, after A), C (6d, after A), D (12d, after B), E (10d, after C), F (4d, after D and E), G (5d, after F), H (3d, after G).

Path analysis:

Result: Both paths are 33 days — the project has two critical paths. The total project duration is 33 days.

Impact of a 2-day slip on task D:

Task D is on the first critical path. If D slips by 2 days, that path becomes 35 days, and the overall project duration becomes 35 days — a 2-day delay to the entire project. The second path (via C and E) remains at 33 days, so it now has 2 days of slack relative to the new critical path.

Recommended response:

• Add resources to task E (on the second path) or accept that the second path is no longer critical.
• Look for opportunities to compress the fixed-duration tasks (G, H) if possible, or negotiate a 2-day extension.
• Investigate why D slipped and address the root cause to prevent further slippage.
• Communicate the revised timeline to stakeholders immediately — do not wait until the original deadline is missed.

Given: PV = ₹1,20,000, EV = ₹90,000, AC = ₹1,10,000.

\[ \text{CV} = \text{EV} - \text{AC} = 90{,}000 - 110{,}000 = -₹20{,}000 \]

\[ \text{SV} = \text{EV} - \text{PV} = 90{,}000 - 120{,}000 = -₹30{,}000 \]

\[ \text{CPI} = \frac{\text{EV}}{\text{AC}} = \frac{90{,}000}{110{,}000} \approx 0.82 \]

\[ \text{SPI} = \frac{\text{EV}}{\text{PV}} = \frac{90{,}000}{120{,}000} = 0.75 \]

Interpretation:

• CV = −₹20,000: The project is over budget by ₹20,000. It has spent more than the value of work completed.
• SV = −₹30,000: The project is behind schedule — it has completed less work than planned.
• CPI = 0.82: For every ₹1 spent, only ₹0.82 of value has been delivered. If this continues, the project will require approximately \(1/0.82 \approx 1.22\times\) the original budget.
• SPI = 0.75: The project is progressing at 75% of the planned rate. If this continues, the project will require approximately \(1/0.75 \approx 1.33\times\) the original duration.

Three corrective actions:

1. Investigate the cause. Determine whether the overrun is due to underestimated effort, rework, or scope changes. The response differs in each case.
2. Re-baseline the plan. Update estimates using the observed CPI and SPI. A revised budget of ₹1,20,000 × 1.22 ≈ ₹1,46,000 and a revised schedule of the original × 1.33 should be discussed with the sponsor.
3. Reduce scope or add resources. If the deadline and budget are fixed, identify lower-priority scope that can be deferred. If they are not fixed, negotiate with the sponsor for more time or more resources. Do not attempt to "work harder" without a structural change.

Four values of the Agile Manifesto:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

(Items on the right still have value — the manifesto prioritises the left.)

User story:

"As a student, I want to view my attendance record for each subject so that I can track my progress and know whether I am at risk of falling below the minimum attendance requirement."

Acceptance criteria:

• Given a logged-in student, when they open the attendance page, then they see a list of all enrolled subjects with attendance percentage and number of classes attended out of total.
• Given a subject with attendance below the institutional threshold, when the student views the record, then the subject is visually highlighted with a warning indicator.
• Given a student with no attendance records for a newly enrolled subject, when the page loads, then the subject shows "No data yet" rather than an error.
• Given a mobile device, when the attendance page is opened, then the table is responsive and readable without horizontal scrolling.

Story point estimate: 5 points (using a Fibonacci scale of 1, 2, 3, 5, 8, 13, 21).

Justification: The story is moderately complex — it requires a database query, an API endpoint with authentication, and a responsive front-end table. It is more involved than a simple CRUD operation (3 points) because of the warning indicator logic and the responsive design requirement, but less involved than a complex feature (8 points) because there is no complex business logic or algorithmic content.

Given: Velocities = 20, 24, 22, 26 story points. Remaining backlog = 165 points.

Average velocity:

\[ \overline{V} = \frac{20 + 24 + 22 + 26}{4} = \frac{92}{4} = 23 \text{ points/sprint} \]

Sprints required:

\[ \text{Sprints} = \frac{165}{23} = 7.17 \rightarrow 8 \text{ sprints} \]

With two-week sprints, the release is approximately 16 weeks away.

Why a conservative estimate should be used for external commitments:

• Velocity variance: the observed range (20–26) shows a spread of 30%. A bad sprint could reduce throughput materially.
• Scope growth: in practice, backlog items are refined and new requirements emerge. The backlog rarely shrinks by exactly the estimate.
• Non-feature work: the raw velocity figure excludes integration effort, documentation, hardening, release preparation, and unplanned production incidents.
• Dependencies and blockers: external API readiness, compliance review cycles, and third-party approvals are outside the team's control.
• Historical inaccuracy: story-point estimates are relative and imprecise; systematic underestimation is the norm.

Conservative estimate: using the lowest observed velocity (20) instead of the average:

\[ \text{Sprints} = \frac{165}{20} = 8.25 \rightarrow 9 \text{ sprints} \]

Plus a buffer of 1–2 sprints for integration and hardening gives a commitment of 10–11 sprints (20–22 weeks), while the internal plan targets 8 sprints. Publishing the conservative figure protects credibility; planning to the optimistic figure maintains focus.

Three Agile anti-patterns:

Purpose of a capstone project: A capstone is a culminating academic experience that requires students to integrate and apply the knowledge and skills acquired across the programme to solve a substantial, realistic problem. It is the bridge between academic learning and professional practice.

Its purposes are: integration (combining knowledge from multiple courses), application (solving a realistic problem with real constraints), evidence (producing a portfolio artefact), professionalism (planning, collaboration and delivery under deadline) and reflection (considering what was learned and what remains).

Eight phases of a capstone:

Structure of a capstone proposal:

1. Title — clear and descriptive
2. Problem statement — what problem exists, who is affected, why it matters
3. Objectives — 3–5 specific, measurable objectives
4. Scope — what is included and explicitly excluded
5. Methodology — approach, technology stack, development process
6. Timeline — phases with milestones
7. Team and roles — members with responsibilities
8. Resources — tools, infrastructure, budget, mentor support
9. Risk assessment — top 5 risks with mitigation strategies
10. Expected outcomes — what will be delivered and how it will be evaluated
11. Ethical considerations — privacy, security, fairness and safety implications

Scenario: You discover that a colleague has been committing API keys to a public repository.

Analysis using the IEEE/ACM code:

Recommended course of action:

1. Do not ignore it. Silently leaving the vulnerability in place is complicit.
2. Speak to the colleague privately first. Explain the risk clearly and without accusation. If the key is still live, it must be rotated immediately — removing the file is not enough because the key is already in the Git history.
3. Help fix it. Move the key to an environment variable or a secrets manager. Purge the key from the git history using git filter-repo or the BFG tool. Force-push and inform collaborators.
4. If the colleague refuses to act, escalate. Inform the security team or your manager in writing. This is a serious risk that affects the whole organisation.
5. Recommend a systemic fix. Add pre-commit hooks or CI checks that scan for secrets before they are committed. Add a .gitignore entry for .env files. Document the correct pattern in the team's onboarding guide.

Key principle: the goal is not to punish the colleague but to eliminate the risk and prevent recurrence. A supportive, solution-oriented approach is more effective than a punitive one — and more consistent with the professional code.

How AI is changing software engineering:

Three skills that remain human:

1. System design and architecture — deciding how components interact, what trade-offs to make, and how the system will evolve requires judgement that AI cannot supply.
2. Security review and threat modelling — evaluating whether a design is secure against adversarial actors requires reasoning about intent and context, not just pattern matching.
3. Stakeholder communication and negotiation — explaining trade-offs to non-technical stakeholders, prioritising requirements and managing expectations is fundamentally a human activity.

Three emerging roles:

1. AI/ML Engineer — builds, trains and deploys machine learning models in production.
2. Prompt Engineer / AI Application Developer — designs prompts and integrates LLMs into applications.
3. AI Ethics / Responsible AI Specialist — ensures AI systems are fair, transparent and accountable.

Core principle: AI tools raise the floor but do not remove the ceiling. Engineers who use AI well are more productive than those who do not. But engineers who rely on AI without understanding fundamentals produce code they cannot debug and systems they cannot reason about. Fundamentals become more important, not less, in an AI-augmented world.

Engineering mindset: the set of intellectual habits and dispositions that characterise excellent engineers and distinguish them from competent coders.