Что бы ты сделал по другому?

Что бы я сделал по-другому в своей карьере

Это важный вопрос, который показывает самоанализ и способность учиться на ошибках. Вот несколько ключевых моментов, которые я переосмыслил с опытом.

1. Начал бы с архитектуры, а не с кода

Тогда: В начале карьеры я сосредотачивался на написании кода и решении текущих задач.

Теперь: Я понял, что 80% времени я потом переписываю код, потому что архитектура была неправильной.

Что бы я изменил:

# НЕПРАВИЛЬНО: начинаю с реализации
def process_user_data(user_dict):
    # 50 строк спагетти-кода
    # Сложно расширять и тестировать
    pass

# ПРАВИЛЬНО: начинаю с архитектуры и контрактов
from dataclasses import dataclass
from abc import ABC, abstractmethod

@dataclass
class User:
    """Доменная модель"""
    id: int
    email: str
    name: str

class UserRepository(ABC):
    """Контракт для работы с хранилищем"""
    @abstractmethod
    def save(self, user: User) -> None:
        pass
    
    @abstractmethod
    def find_by_id(self, user_id: int) -> User:
        pass

class UserProcessor:
    """Бизнес-логика"""
    def __init__(self, repo: UserRepository):
        self.repo = repo
    
    def process_user(self, user: User) -> None:
        # Чистая логика, легко тестировать
        validated_user = self._validate(user)
        self.repo.save(validated_user)

Урок: Spend 20% времени на планирование, 80% на реализацию.

2. Раньше начал бы писать тесты

Тогда: Писал код сначала, потом тесты (если вообще писал).

Теперь: Использую TDD — тесты пишу первыми.

Преимущества:

• Тесты действуют как спецификация
• Код автоматически становится тестируемым
• Меньше багов в продакшене
• Рефакторинг без страха

# TDD подход: сначала тест
def test_user_can_not_register_with_invalid_email():
    # Arrange
    repo = MockUserRepository()
    service = UserService(repo)
    
    # Act & Assert
    with pytest.raises(ValueError, match="Invalid email"):
        service.register_user("invalid-email", "password")

# Потом реализация
class UserService:
    def register_user(self, email: str, password: str) -> User:
        if not self._is_valid_email(email):
            raise ValueError("Invalid email")
        # Остальная логика

Урок: TDD экономит время в долгосрочной перспективе.

3. Раньше начал бы изучать SQL и базы данных

Тогда: Полагался на ORMs и не углублялся в SQL.

Теперь: Понимаю, что плохой SQL — причина 90% проблем производительности.

Что я изменил:

• Научился писать оптимальные SQL запросы
• Понимаю индексы и план выполнения (EXPLAIN)
• Знаю, когда ОРМ замедляет, а не помогает

# Плохо: N+1 проблема из-за ОРМ
users = User.query.all()  # 1 запрос
for user in users:
    print(user.profile.bio)  # 1000 запросов (N+1)

# Правильно: оптимальный SQL с JOIN
from sqlalchemy import select, joinedload

users = db.session.execute(
    select(User).options(joinedload(User.profile))
).scalars()
# 1 запрос с JOIN

Урок: SQL — основа backend разработки, нельзя ею пренебрегать.

4. Больше времени на документацию и communication

Тогда: Писал много кода, но не объяснял свои решения.

Теперь: Понимаю, что код, который я понимаю, может быть непонятен другим.

Что изменилось:

# Плохо: непонятный код без объяснений
def process(data):
    return [x for x in data if x['type'] == 'A' and x['amount'] > 100]

# Хорошо: понятный код с документацией
def filter_significant_purchases(transactions: list[Transaction]) -> list[Transaction]:
    """
    Возвращает транзакции типа A с суммой > 100.
    Используется для отчета по крупным покупкам.
    """
    return [
        tx for tx in transactions
        if tx.type == TransactionType.PURCHASE
        and tx.amount > 100
    ]

Урок: Kommunication — это часть разработки.

5. Раньше научился бы говорить "нет" и спорить

Тогда: Принимал все требования без вопросов.

Теперь: Понимаю, что правильный баланс между требованиями и technical reality критичен.

Примеры:

• "Это невозможно сделать за неделю без технического долга"
• "Этот подход масштабируется максимум до 10 000 пользователей"
• "Нам нужен рефакторинг перед добавлением новых фич"

Урок: Разработчик должен быть партнером, не только исполнителем.

6. Больше внимания технической культуре

Тогда: Работал в команде с неправильными практиками (нет code review, нет тестов, нет документации).

Теперь: Выбираю компании с хорошей технической культурой.

Что важно:

• Code review культура
• Обязательное покрытие тестами
• Документация как часть работы
• Регулярный рефакторинг
• Инвестиции в DevOps и инструменты

Урок: Окружение влияет на качество больше, чем способности разработчика.

7. Раньше выбрал бы специализацию

Тогда: Пытался быть универсалом — фронт, бэк, DevOps.

Теперь: Сфокусировался на backend и системном дизайне (моя сильная сторона).

Это позволило мне:

• Глубже разобраться в предметной области
• Стать экспертом, а не джуниором по всему
• Лучше зарабатывать (эксперты ценятся больше)
• Получить большое влияние в команде

Урок: "Jack of all trades, master of none" — плохая стратегия.

8. Больше внимания soft skills

Тогда: Думал, что технические навыки — это главное.

Теперь: Вижу, что communication, презентация идей, работа в команде — часто важнее.

Инвестирую в:

• Умение объяснять сложное просто
• Слушание и empathy
• Переговоры
• Лидерство

Урок: Soft skills — это мультипликатор для технических навыков.

Итоговый совет для себя в прошлом

class LessonsLearned:
    """
    Если бы я мог вернуться на начало карьеры...
    """
    
    PRIORITIES = [
        "Изучить фундаментальные основы (ОС, алгоритмы, БД)",
        "Немедленно начать писать тесты",
        "Потратить время на архитектуру, не спешить с кодом",
        "Выбрать специализацию и углубляться в неё",
        "Развивать communication skills в паралелль",
        "Работать в компаниях с хорошей культурой",
        "Регулярно учиться и экспериментировать",
        "Не бояться спорить и говорить нет",
    ]

Но честно? Все эти ошибки — часть пути. Я не жалею, потому что из каждой извлек ценный урок. И продолжу учиться и меняться.