Skip to content

Latest commit

 

History

History
392 lines (296 loc) · 8.95 KB

File metadata and controls

392 lines (296 loc) · 8.95 KB

Professional vs Unprofessional Comments

The Problem

Unprofessional comments in code:

  • Damage reputation - Code may be reviewed by clients, auditors
  • Create HR issues - Offensive language in workplace materials
  • Hurt team morale - Insulting comments about colleagues
  • Legal liability - Discriminatory language creates legal risk
  • Career damage - Your GitHub is your resume

Why This Matters

Your Code Is Public

// BAD: This is in your Git history forever
function process_payment() {
    // This fucking API is garbage
    // Piece of shit times out constantly
}

Who might see this:

  • 👔 Clients during code audits
  • 🏢 HR during investigations
  • 👨‍💼 Future employers reviewing your GitHub
  • ⚖️ Legal teams during lawsuits
  • 🌐 The entire internet if code is open-source

Real Consequences

Example 1: Client Audit

// Client has the worst taste in colors
// This looks like a 90s Geocities site

Result: Client sees comments during security audit, fires agency.

Example 2: Open Source Project

// Users are idiots who can't follow instructions

Result: Screenshot posted on Twitter, project loses contributors.

Example 3: HR Investigation

// John wrote this and it's total garbage
// Dude can't code his way out of a paper bag

Result: HR investigation for workplace harassment.

Example 4: Legal Discovery

// Chinese time zones are weird as hell

Result: Discovered in discrimination lawsuit, used as evidence.

Example 5: Real-World Anecdote - Production JavaScript

Found in inherited project (still viewable on archive.org):

Translation:

// I'm very sorry. It had to be done. Quick, hard and dirty,
// that's how you like it, isn't it...

Context:

  • Discovered in production JavaScript file during project relaunch
  • Still archived on archive.org (searchable by anyone)
  • Inappropriate innuendo in client-facing code

What Makes Comments Unprofessional

1. Profanity and Vulgarity

// BAD
// This fucking function is a pain in the ass
// Holy shit this is garbage

// GOOD
// This function requires refactoring for improved performance
// Current implementation has reliability issues

2. Insulting Others

// BAD
// WTF was the last dev thinking?
// Previous developer's code is complete garbage

// GOOD
// Refactored from legacy implementation
// Original approach had performance constraints

3. Insulting Users

// BAD
// Users are idiots
// Babysitting stupid users

// GOOD
// Additional validation to improve user experience
// Defensive programming for edge cases

4. Inappropriate Humor

// BAD
// Strip spaces like a stripper on payday lol
// Time to make it rain! $$$$

// GOOD
// Normalize card number format by removing spaces
// Process payment transaction

5. Discriminatory Language

// BAD
// Chinese time zones are weird
// Female designer picked this color

// GOOD
// Handles IANA timezone database entries
// Brand colors per style guide

6. Personal Venting

// BAD
// I hate this feature
// Why do we even need this? Nobody uses it

// GOOD
// Feature requested by marketing team
// See requirements: docs/features/import.md

7. Passive-Aggressive Comments

// BAD
// Boss has no clue how long things take
// Management too cheap to upgrade

// GOOD
// Deadline constraints require phased implementation
// Using legacy API until budget approved for upgrade

8. TMI (Too Much Information)

// BAD
// Writing this hungover from last night
// Coded at 3am after a few drinks

// GOOD
// Implemented as emergency hotfix
// May require optimization in next iteration

Good Professional Comments

1. Technical Explanation

/**
 * Calculate tax based on configured rate.
 * 
 * Tax rate changes frequently based on business requirements.
 * Rate is configurable via admin settings to accommodate changes.
 * 
 * @param float $amount Pre-tax amount
 * @return float Tax amount
 */

2. Constructive Context

/**
 * Retrieve user data by ID.
 * 
 * Refactored from legacy implementation to improve performance.
 * See ticket #1234 for details.
 */

3. Solution-Oriented

/**
 * Synchronize data with external API.
 * 
 * API has known reliability issues with occasional timeouts.
 * Implements retry logic with exponential backoff.
 * 
 * See API documentation: https://api.example.com/docs
 */

4. Architecture Decisions

/**
 * Uses WordPress transients for caching.
 * 
 * Decision factors:
 * - Compatible with all hosting environments
 * - Works with object cache plugins
 * - Automatic expiration handling
 * 
 * See: docs/adr/0001-use-wordpress-transients.md
 */

5. Collaborative Tone

/**
 * Handle edge case discovered during QA testing.
 * 
 * Edge case: User submits form with empty required fields.
 * Added validation to prevent data corruption.
 * 
 * See test documentation: tests/integration/form-validation.php
 * Bug report: #4567
 */

The Professional Standard

DO Write:

Technical explanations - Why code works this way
Business context - Requirements, tickets, decisions
Known issues - Documented limitations
Future plans - Planned improvements
References - Links to docs, tickets, ADRs
Warnings - Important gotchas for future developers
Examples - How to use the code

DON'T Write:

Profanity - Ever, for any reason
Personal attacks - On anyone, past or present
Complaints - About management, users, clients
Jokes - Unless G-rated and professional
Sarcasm - Doesn't translate well
Assumptions - About users, developers, anyone
Personal info - About your life, feelings, etc.
Discriminatory language - Race, gender, religion, etc.

The Test

Before writing a comment, ask:

  1. ❓ Would I say this in a client meeting?
  2. ❓ Would I want my boss to read this?
  3. ❓ Would I want this on my resume?
  4. ❓ Could this offend anyone?
  5. ❓ Is this helpful or just venting?

If any answer is "no," rewrite it.

Real-World Guidelines

Instead of Venting:

// BAD: "This API is a piece of shit"
// GOOD: "API has reliability issues. Implemented retry logic."

// BAD: "Client keeps changing their damn mind"
// GOOD: "Requirements updated frequently. Configuration-driven approach."

// BAD: "Management too cheap to upgrade"
// GOOD: "Using legacy system until budget approved for upgrade."

Instead of Blaming:

// BAD: "Previous dev wrote garbage code"
// GOOD: "Refactored for improved maintainability"

// BAD: "QA team can't do their job"
// GOOD: "Edge case discovered during testing. Added validation."

// BAD: "Users are stupid"
// GOOD: "Enhanced validation for better user experience"

Instead of Sarcasm:

// BAD: "Oh great, another brilliant validation function"
// GOOD: "Standardized validation to ensure consistency"

// BAD: "Let me just pull a report out of my ass"
// GOOD: "Quick implementation. May require optimization."

Career Impact

Good Comments:

/**
 * Implement caching strategy for API responses.
 * 
 * Reduces API calls by 80% and improves page load time by 2.3s.
 * 
 * Cache invalidation triggered on:
 * - Manual content updates
 * - Scheduled sync (daily at 2 AM)
 * - Cache age exceeds 24 hours
 * 
 * Performance metrics: docs/performance/caching-results.md
 */

Impression: Professional, thorough, data-driven developer.

Bad Comments:

// This fucking API is so slow
// Added caching because this shit takes forever
// Whatever, good enough for now

Impression: Unprofessional, frustrated, low-quality work.

The Bottom Line

Your comments represent you professionally.

// This says: "I'm unprofessional and immature"
// Fucking garbage code

// This says: "I'm professional and solution-oriented"
// Refactored for improved performance. See ticket #123.

Write every comment as if:

  • Your client will read it ✓
  • Your boss will read it ✓
  • Future employers will read it ✓
  • It will be quoted in court ✓

Key Takeaways

Be professional - Always, no exceptions
Be constructive - Focus on solutions
Be respectful - Of everyone
Be helpful - Explain, don't complain
Be factual - Stick to technical details
Be solution-oriented - Document fixes, not frustrations

❌ Don't use profanity
❌ Don't insult anyone
❌ Don't complain
❌ Don't vent
❌ Don't use inappropriate humor
❌ Don't make assumptions about people
❌ Don't share personal information
❌ Don't use discriminatory language

Remember

"Would I want this comment on the front page of the newspaper with my name on it?"

If not, delete it and write something professional.

Your code is your professional reputation. Make it count.