Позднее Ctrl + ↑

Турник и площадка во дворе

Короче, Варламов топит за мангал в каждый двор, а я буду топить за турник и ровную площадку в каждый двор.

Серьёзно, для обывателя не нужно ни рукоходов, ни брусьев, ни лестниц, а достаточно одной загогулины и поверхностью под ней, чтобы отжиматься и всякое такое делать не пачкаясь.

Короче, вот такая штука, как у Лебедева, только с одним турником.

А ещё в подъезде нужно между 4 и 5 этажом турник на стене повесить на зимнее время.

P.S. За картинку спасибо Рите.

Если задумываться — не получится

Когда люди начинают играть на гитаре, они много задумываются над постановкой пальцев, над тем, чтобы нужные нотки звучали, о том, как издавать звук медиатором. И некоторые остаются на этом этапе, не сумея сыграть ни одной песни потому, что там нужно быстро аккорды менять.

Поэтому нужно идти играть в группу, а в группе вводить правило, что если ты ошибся, нельзя останавливаться. Останавливаться можно, если появилась отличная идея, но основная задача — сыграть всю песню. Конечно, по-началу ты ошибаешься постоянно и ничего не получается, но со временем образуется навык, и ты играешь уже не задумываясь о постановке рук и так далее. И это очень пригождается на концертах, когда тебе нужно общаться с залом, а не смотреть на гриф.

То же самое с разговором на иностранных языках. Пока ты учишься, ты допускаешь много ошибок. Если ты будешь задумываться о каждой ошибке, то ты не сможешь говорить. Поэтому и переезд к носителям помогает очень быстро — ты вынужден доносить свою мысль несмотря на ошибки, а их сможешь исправить уже после.

Вероятно, подобные вещи можно уловить и в отношениях — пока ты переживаешь о каждом неправильном слове, отношения целиком строятся очень медленно.

Но есть и следующий этап.

Даже если ты выработал навык, но стал снова на новом уровне задумываться о том, как именно это делать, ты можешь снова потерять возможность играть или говорить.

Поэтому задумываться, конечно, очень важно, но важнее — делать, и начинать раньше, чем ты со всем разобрался (потому, что невозможно со всем разобраться).

Хорошо, когда работа идёт без тебя, часть 2

Когда я собрался увольняться из компании, в которой вёл большой проект со стороны интерфейса, к нам пришёл молодой разработчик сразу после университета. Он не знал конкретных библиотек, которые мы использовали.

За этот месяц я рассказал ему, что необходимо, и он довольно быстро включился в процесс. По прошествии нескольких месяцев, бывшие коллеги рассказали мне, что так получилось, что сейчас он единственный поддерживает разработку интерфейса этого большого проекта. И что разработка идёт вполне себе устраивающими темпами.

У него есть мои контакты, но он ни разу мне не писал. Конечно, он может спросить что-то у коллег, но и они говорят, что он не так часто это делает.

И это комплимент для меня. Если большую систему с сотнями представлений и страниц можно успешно поддерживать не имея большого опыта, то это значит, что та архитектура, те принципы, которые были использованы были правильными.

Хорошо, когда работа идёт без тебя, часть 1

Однажды ко мне пришёл менеджер и сказал, что нужно сделать развёрнутую систему прав. Я был ведущим разработчиком на проекте, у меня оставалось два дня до отпуска, а систему прав нужно было выпускать через 2 недели, когда я ещё буду в отпуске.

Я задумался. К тому времени у нас была очень простая система прав. У нас было что-то вроде 7 разделов и если кто-то имел доступ к разделу, то мог делать в нём всё. Теперь требовалось сделать так, чтобы для разных пользователей были доступны или нет конкретные действия и кнопки: просмотра, редактирования, удаления.

Но были и плюсы:

  • мы уже обсуждали будущую необходимость появления системы прав с бекэндером и он знал, как это можно сделать;
  • мы никогда не опирались на то, что фронтенд сам что-то контролирует, поэтому запрет редактирования заключался не в скрытии кнопочки, а в том, что и по API редактирование не будет доступно;
  • у нас были конфигурации каждой страницы. Страницы были описаниями какие данные где взять и как их отобразить, а не вёрсткой каждой страницы отдельно;
  • в начале проекта я настоял на том, чтобы каждая страница отображала одну сущность, или один набор сущностей. К примеру, кнопка удаления была только на странице редактирования документа, а не где-то ещё. Запретив переход на эту страницу мы автоматически запрещали и редактирование, и удаление. Сделал я это исходя из удобства пользователю, но оказалось, что это удобно и нам.

Я написал за несколько часов заглушку бибилиотеки, проверяющей права. Договорился с бекэндером о том, в каком формате он будет присылать список прав для каждого пользователя. И рассказал своей команде, что именно нужно делать для того, чтобы всё заработало.

И пошёл в отпуск.

Когда я вернулся, система была готова и выпущена, в отпуске меня никто не тревожил, а ребята смогли придумать пару вещей, о которых я не успел подумать до отпуска, но которые несколько улучшили систему.

Я обрадовался. Если ребята могут это сделать без меня, то значит, что код, который я написал понятен, подход, который я предложил тоже, подготовка ребят достаточная, а я могу не тратить время на такие задачи и переходить на ещё более сложные.

А вот если бы мне каждый день звонили в отпуске, то это бы значило не то, что ребята не знают границ, а то, что я недостаточно хорошо объяснил и подготовил работу.

Про профессиональный рост

Меня часто спрашивали что-то такое: «А не боишься ли ты, что если автоматизируешь свою сегодняшнюю работу, то тебя просто уволят за ненадобностью?» И я видел, как много людей топчатся на месте, лишь бы этого не случилось.

Мне всё время это казалось ересью. Наоборот, если ты автоматизируешь то, что уже умеешь делать или отдашь это молодому коллеге, то у тебя освободится время для того, чтобы делать что-то на уровень выше или просто другое. Например, если ты автоматизируешь создание новых страниц и на каждую страницу станет уходить два часа, а не три дня, то после этого можно будет провести исследование, какие именно страницы удобнее: ведь менять их вариации теперь легко. Или, можно будет остановиться на скорости работы программы, посмотреть на нёё в комплексе. Если бы автоматизации не было, то и времени бы на это не осталось.

Конечно, такими путями через несколько лет ты и вправду может упереться в потолок внутри конкретной компании: все необходимые для роста продукта вопросы уже решены. Ну что ж, в таком случае, можно либо придумать, что ещё полезного ты можешь сделать, чтобы приподнять этот потолок, или найти компанию, где твой сегодняшний опыт будет началом пути.

Про то, как я ответил на вопрос, на который не знал ответа

Сделали мы новый проект и пришло время его тестовой эксплуатации.

В компанию приехал технический пециалист заказчика и стал задавать всякие каверзные вопросы. Сначала с ними справлялся менеджер, но в какой-то момент перестал и в кабинет позвали меня, как ведущего разработчика проекта.

Представитель заказчика задал какие-то вопросы, о которых мы подумали и на которые я знал ответ и вот прихоло время следующего вопроса. Он говорит:

  • Вы сделали прекрасную историю изменений, которой нет у конкуретнов. Теперь в истории хранится не только время и автор изменения, но и весь слепок версии на то время. Однако, мы боимся, что документы будут меняться часто и история начнёт занимать слишком много места за года использования. На основном сервере мы не можем обеспечить столько места на жёстких дисках, и хотели бы вынести историю в отдельную базу на другом сервере. Можно ли так сделать? Сможете ли вы это запрограммировать?

В моей голове завертелось следующее:

  • проблема есть;
  • выносить в отдельную базу, значит, потерять внешние ключи, это значит, что мы не сможем контролировать целостность, и, наверно, появятся ещё какие-то проблемы;
  • программировать что-то для частного случая не хочется, так мы можем придти к 15 БД;
  • любое программирование — это деньги компании и мне придётся объяснить, почему мы это делаем;
  • эта проблема точно возникала не только у нас, множество продуктов хранят историю и вообще очень много данных;
  • мы используем PostgreSQL, это наиболее развитая свободная СУБД и там точно есть решения для этих проблем, когда данные не помещаются на один жёсткий диск.

И я сказал: я думаю, что нам не нужно будет ничего программировать. Мы сможем вынести таблицу с историей на другой сервер посредством возможностей СУБД.

Представитель удивился, сказал, что хорошо, если так и я пошёл на рабочее место. Там я спросил у бекэндера, был ли я прав. Он ответил, что да, и что это называется «внешние таблицы».

Мораль в том, что проспо подумав и прикинув вероятность того, что что-то работает так, как тебе нужно, ты можешь придумать решение для разных ситуаций. Правда для этого нужен какой-никакой кругозор.

Поэтому я и трачу существенную часть рабочего времени на то, чтобы этот кругозор нарасти и не потерять.

Про уверенность

Однажды на работе мне дали задачу сделать новый продукт вдвоём с бекэндером — он делает всё, что на сервере, я всё, что в браузере. И этот продукт должен стать платформой для других новых продуктов. Впрочем, я и сам подводил к тому, чтобы эта задача досталась мне.

К тому времени текущие продукты были сделаны на смеси Java + Spring + Angular 1 + JQuery. То есть на сервере хранились .jsp-странички к которым были подключены JS-библиотеки, лежажие прямо здесь, устаревших версий, в которых предыдущие программисты ещё что-то меняли руками, поэтому обновлять их не было никакой возможности.

К тому времени я начитался в интернете о том, что существует какой-то npm-репозиторий с библиотеками, что есть React.js и какие-то другие фреймворки, что есть какой-то компонентный подход, который используется в новом Angular 1.5 в том числе. Ещё мне откровенно не нравилась Java на бекэнде. Мне представлялось, что у нас вырос какой-то невероятный энтерпрайз-монстр, который в первую очередь обслуживал сам себя, а не мифическую высокую нагрузку.

Если вы не фронтенд-разработчик и не поняли, что написано выше — неважно. Важно то, что я понимал, что сегодняшняя архитектура неимоверно сложна, что есть пути проще и популярнее, и что я совершенно не знал, работают ли они.

И с этим всем я пошёл на совещание с директорами, для того, чтобы мы с бекэндером представили новый подход к технической платформе. Там мы рассказали об этих новых способах, получили согласие и разошлись работать. На совещании с нами сидел опытный фронтендер, который не занимался этим проектом, но мог что-то прокомментировать. Он сказал мне несколько слов уже после совещания. Они были такими: «У тебя не получится так сделать».

И вправду, я и сам был не уверен в том, что у меня получится, я же не делал такого никогда. Я был уверен только в том, что другие так делают и у них получается и в том, что не боги горшки обжигают.

Всё закончилось хорошо. Продукт мы разработали в срок, на его основе выросли огромные проекты.

Подобные вещи случались многократно, каждую неделю мне нужно было делать что-то такое, что ни я, ни кто-то другой в компании не делал.

И в этом и суть. Ты растёшь сам и помогаешь расти компании только когда берёшься делать то, в чём совсем не уверен, что справишься.

Если ты делаешь многократно что-то, в чём уверен, то нужно либо передать эту работу молодому коллеге, или автоматизировать, чтобы не топтаться на одном месте.

Можно делать меньше

Часто люди пытаются сделать даже промежуточные работы и отчётами идеальными. Прорисовывают каждую деталь, делают аккуратно, запариваются о пикселях и так далее. Так не надо. А надо так, чтобы решало задачу.

На работе мы часто обмениваемся скриншотами, на которых помечено куда смотреть. Часто люди ставят специальные программы и следят за тем, чтобы их подчёркивание или выделение были ровненькими. А нужно так:

Притом так даже лучше, чем когда ровненько: ты сходу понимаешь, что выделение — часть скриншота, а не самого интерфейса.

Или, например, при работе над дизайн-проектом можно сначала сделать коллаж из мебели, а не 3D-визуализацию. Прикинуть, как будут сочетаться цвета и мебель по нему можно, исправить будет легко, а силы на визуализацию не будут потрачены.

Так что не только можно, а нужно делать меньше.

Про курсы обучения чему-нибудь

Когда-то я, сомневаясь в себе, выбирал какие-то курсы в интернете: программирования там, иллюстрирования и так далее. И потом получалось, что в видео, которые выкладывают в курсе, ребята с плохопоставленной речью рассказывают то, что написано в документации к тем инструментам, что я изучаю.

Конечно, не все курсы такие. И на курсы стоит идти не за этими знаниями, а только за тремя вещами:
дедлайнами,
общением с преподавателем,
общением с однокурсниками.

Второе особенно хорошо, если представляется, что именно этот преподаватель может рассказать что-то важное из собственного опыта.

Если эти плюсы не перевешивают, стоит просто познакомиться с оглавлением тем, и пойти их погуглить.

В общем-то то же самое, касается и университета. Самое крутое в нём — возможность общаться с однокурсниками и преподавателями. Ну ещё диплом и допуск к чему-то такому, что так просто не попробовать, если это важно в вашей сфере.

Меняться местами

Когда мы играли в музыкальной группе, то часто через час репетиции менялись местами. Гитарист — за барабаны, вокалист — за бас, басист за гитару и барабанщик на вокал. Ну или как-нибудь по-другому.

И так мы играли пару песен. Получалось, конечно, паршиво, но суть не в этом. А в том, что в такие моменты можно лучше понять, что именно делает другой человек в группе, как он это делает, что важно и что нет, а ещё понять, что другие-то тоже нехило так стараются.

И так, конечно, стоит делать в любом коллективе.

Ранее Ctrl + ↓