привет, зайцы :)

Эту неделю тви для вас ведёт @nazarov_tech из Петербурга. Питонист, джаваскриптер (ну, такое) и организатор айти-движа.

Сейчас я пишу всякий веб для финтеха в @EXANTE_EU: ритейл-платформу, медиа. Помимо этого я член программного комитета конфы @PiterPy :)

ещё два проекта, где я орг: @spbpython (сообщество питонистов петербурга) и @djangogirls_spb (однодневный воркшоп для девушек).

допускаю, что кто-то может знать меня как автора "Эти токсичные, токсичные собеседования" ^^

habrahabr.ru/company/exante…

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

Всё началось в маленьком городке под названием Уфа, где я, будучи студентом матфака, нашёл летнюю стажировку в дочерней структуре Роснефти.

(зато оттуда Шевчук, Земфира, и Георгий Албуров @alburov)

так вот, айти в уфе в основном работает под нефтянку. Сколь-нибудь интересное, во всяком случае. Большинство знакомых получали опыт так.

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

я нигде не видел, чтоб люди так пили (а я видел медиков, например).

И ещё здесь я впервые увидел, как программисты (!) рисуют кнопки в фотошопе, чтобы подделать отчётность по ГОСТу. Неэффективность во всём.

но самая большая опасность, что таит в себе нефтянка для айтишника, в другом. Это невозможность её покинуть. Аналогично с банковской сферой.

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

если вы студент, вам будет очень сложно сделать правильный выбор в сторону свободы. Мне повезло: у меня был чудесный первый тимлид.

Этот человек научил меня многим очень правильным вещам: питону, гиту, Фейнману. Теперь я в свою очередь учу этим вещам других, отдавая долг.

забыл сказать, у меня есть некая неприязнь к банкингу из-за их (объяснимой) повёрнутости. Я не люблю, когда запрещён вайфай, например.

Следующим этапом стал @TheUfanet — это крупнейший местный провайдер. Там меня @ufaweb приобщил к вебу и к джанге :)

Уфанет был довольно необычной конторой. Т.е. действительно необычной. Тебя могли послать на обязательный тренинг по физиогномике :)

но при этом там были клёвые возможности для развития по меркам Уфы. Большинство бывших уфанетовцев работают в крутых конторах или за рубежом

и мы пытались мутить движ даже тогда. Уфанет и Rebranch устраивали #UfaPy (митап по питону в Уфе).Кажется, это был один из немногих митапов.

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

и с тех работаю почти исключительно на стартапы. Да, я тот самый startup junkie :) Как ни странно, петербург для такого вполне подошёл.

в петербурге я неожиданно для себя открыл новую нишу: делать айти-движ. Это @PiterPy, @spbpython, @djangogirls_spb. И даже получается!

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

Про города, раз уж затронул тему: разработчику в России комфортно в Москве и в Питере. Работы и развлечений вам хватит в обоих случаях.

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

в петербурге проще навигация, дешевле и проще аренда, ближе заграница и есть барная культура.

Помогла ли мне как-то математика (у меня даже диплом) в разработке? Тяжкий вопрос. Если кратко — да, но вообще не так, как принято думать.

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

в геймдеве требуется много математики (линал, тригонометрия, ..), но то ниша, в которой большинство из вас никогда не будут работать.

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

ну и неочевидный момент: диплом помогает завести трактор. На блюкарту в берлин нужен, в частности.

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

(до тех пор, пока вы способны хотя бы на уровне средней школы прочесть график, конечно)

Что касается высшего образования.. я скорее против, чтобы все ломились в вузы. Большинству людей, кто получал/получает вышку, она не нужна

если рассматривать это как инвестицию, это огромная инвестиция: 4-6 лет вашей жизни. Подумайте крепко, стоит ли оно того для вас.

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

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

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

мне лично пока интересно и весело в найме :) Потребность к организации удовлетворяю боковыми проектами.

распространённое заблуждение в инете про "не работай на дядю" — что в найме нет достойных денег/условий. Есть, надо уметь искать. :)

если вам вдруг любопытно, средний возраст фаундеров по данным @ycombinator — 29 лет.

поэтому существует практика менторства. Если вы нашли себе ментора (исторически это мог быть старший товарищ или преподаватель), вы молодец.

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

учитесь формулировать мысли у @nickolaykononov и @perepisal. Оформлять красиво у @ilyabirman. Джаваскрипту у @iliakan. Менеджменту в Бюро.

Как-то сегодня пока очень софткорно/бизнесово получается, надеюсь, вы не в обиде. Завтра-послезавтра будут более технические дни )

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

нужно ли мне раскрыть эту мысль и рассказать, чем первое отличается от второго?

если бы нам платили за строчки кода, джависты получали бы больше всех. Стоп, они и так получают больше всех :D неудачный пример

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

Филатов (facebook.com/filalogic) мне когда-то объяснил, что программист весьма похож на врача или адвоката. Его роль служебная: помочь.

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

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

существует определённая социальная стигма против тех, кто часто меняет работу. Особенно на exUSSR-пространстве. "Прыгуны".

эта стигма почти аналогична стигме про отсутствие диплома: имеет исторические причины, но сейчас уже играет мало роли.

конечно, бизнес хочет отбить деньги, вложенные в обучение/погружение сотрудника. Так что это вопрос срока.

если вы миллениал и работаете в стартапах, вопросов к вам будет меньше. Сама культура предполагает риски: forbes.com/sites/kaytiezi…

основной аргумент за смену работы — резкий рост доходов. Никакие повышения не дают такого эффекта forbes.com/sites/cameronk…

помимо этого вы получаете широкий опыт на разных проектах. Он не будет глубоко системным (это минус), но T-shape вы ещё успеете прокачать.

но вас осудят, как и в случае ухода из вуза.

Вас осудят крепко и страшно. Будьте готовы стоять на своём и оправдывать выбор снова и снова.

Что касается выбора стека и карьеры, то тут ничего нового не открою, к сожалению: держимся классики про 10,000 часов и trend is your friend.

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

а уже отработав эти условные 10,000 часов, вы будете достаточно квалифицированы, чтобы принять решение, куда углубляться и где остаться.

и что важно: во фронтенде живая обратная связь. Вы будете видеть результат работы сразу, как и счастливых юзеров.

но не всегда, см. нефтянку.

что есть "лучше для карьеры", например?

Круче тимлиды. Интереснее стек. Громче имя. Бюджет на выступления.

Но это индивидуально.

@backendsecret @nazarov_tech Запустил статистику backendsecret.ru/stats/

воспользуюсь тем, что я в берлине, и пойду припить бельгийского / купить себе LEGO :)

Задавайте пока вопросы / тем… twitter.com/i/web/status/9…

«Дайте мне всего три фронтендщика и я уничтожу @backendsecret» © Отто фон Даллес

утро!

сегодня поговорим про разные языки бэкенда: python, js, go, ruby, c#, java с перспективы питониста :)

(С перерывом на TXL ✈ LED.)

Лайкните этот твит, если Python – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если JS – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если Go – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если C# – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если Ruby – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если Java – основной язык, на котором вы пишете бэкенды.

забыл какие-то?

Простите, что опрос странным образом: тви не позволяет более четырёх вариантов, а сторонние сервисы не подтянутся на сайт.

Лайкните этот твит, если PHP – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если Perl – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если Scala – основной язык, на котором вы пишете бэкенды.

Лайкните этот твит, если Erlang/Elixir – основной язык, на котором вы пишете бэкенды.

Добавил к опросу Scala и Erlang.

Как я мог их забыть, неясно, учитывая, что @EXANTE_EU активно их пользуют: stackshare.io/exante/exante

но вообще я планировал начать оскорблять чувства верующих в другие языки чуть позднее. =/

постараюсь всё же быть объективным.

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

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

Мне нравится синтакс, мотто "мы хотим видеть вас счастливыми", интересные задачи в хороших проектах.

Мне не нравится общая немачурность языка (ломать всё минорным релизом), маленький рынок, меньшее число либ чем у питона.

Я знаю, что Ruby используют как основу стека серьёзные технарские команды. Например, @evilmartians_ru.

Продолжим о хороших языках.

Мне нравится Go. Чертовски нравится. Видимо, питонистам так положено :3

достаточно прозрачный и простой, мало оверхеда, асинк из коробки, деплой из коробки. Смешной маскот. Как не любить? 😍

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

на го написан, например, докер, но вот докер-компоуз – уже на питоне.

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

и почти везде он офигительно хорош.

фактором успеха является, наверное, обширное и любящее коммьюнити, управляемое правильным образом.

ну и то, что он с самого начала проектировался должным образом. Посмотрите на CSS или PHP, и вы поймёте, о чём я.

У питона (как и у остальных языков) есть ряд проблем и штук, за которые его принято ругать.

например, разделение версий на Python2 и Python3. Болезненно, но в 2020 второй питон депрекейтнется и должно стать полегче.

правда, уже ведут разговоры о Python4, так что..

другая претензия состоит в скорости питона. Вот это самая обидная, потому что необъективная.

если питон вам медленный – крайне велика вероятность, что вы пытаетесь его как-то не так использовать.

под капотом у питона C, а у его основных либ – плюсы. Стартовой точкой для понимания может стать пост Гвидо plus.google.com/u/0/1152120510…

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

Более серьёзная предъява к питону заключается в en.m.wikipedia.org/wiki/Global_in…

Считается, что Python – не конкурент NodeJS и Go в терминах concurrency. restapibuilder.com/blog/concurren…

поэтому на двух последних языках пишут нетворкня-рилейтед вещи в большом количестве.

@backendsecret morepypy.blogspot.ru/2017/08/lets-r… вот последняя статья на эту тему

например, @amel_true регулярно рассказывает мне, как хорошо дела у ноды.

я приземлился в петербурге, потеряв телефон в самолёте. Зато поболтал с капитаном.

Продолжаем.

@backendsecret от ноды уже даже автор ноды отказался в польщу Го
>I would definitely use Go for that. mappingthejourney.com/single-post/20…

Что ещё смущает в Go: скорость разработки.
@sysradium утверждает,что при должном опыте сравнима с Python, но мне в это трудно пока поверить.

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

Это отчасти так, но у нас теперь появился тайп-хинтинг, например: blog.pythonlibrary.org/2016/01/19/pyt…

Хитрота, которая сильно облегчает жизнь.

Эппловский Swift на бэкенде. Такое.

Алекс Федосов из Sportacam пробовал, говорит, прям ок.

Честно, ни разу не сталкивался. Расскажите, если есть опыт :)

Тут надо понимать, наверное: серверный Swift лишь прикидывается свифтом, как NodeJS прикидывается JS.

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

@kostenko @amel_true @backendsecret многопоточная. Есть механизм воркеров, с которыми можно общаться с помощью сооб… twitter.com/i/web/status/9…

@visualwatermark @kostenko @backendsecret воркеры это не потоки. А shared array пока в ноду не внедрили же.

Леди и джентльмены, много интересных реплаев, не осилю ретвитить/отвечать на всё. Думайте, читайте, открывайте треды сами.

NodeJS. Давайте поймём для начала, серверный джаваскрипт ведь уже перестал быть смертным грехом?

С типизацией здесь всё ещё хуже, чем у питона. И, как и в случае питона, здесь есть решения в эту сторону.

Некоторая немачурность всё ещё тоже присутствует. Важные штуки в ноду до сих пор доносят.

но фронтендеры скажут вам спасибо — это тот бэкенд, в который они смогут сравнительно быстро начать коммитить

(@wouldntfix рассказывал, что у них есть сервера на ноде отчасти по этой причине).

@backendsecret Есть)

medium.com/we-parse-json/…

и для меня это скорее плюс, но вдруг вы не миллениал? :3

@backendsecret Бэкенд, который мы заслужили

Продолжаем о хорошем. Крупная тема: Microsoft.

Ох.

тут периодически бывали люди, работающие с m$-стеком. Почему всех их объединяла лёгкая доля.. как это выразить. Вдохновлённости.

и это вызывало негатив у аудитории.

Попробуем поговорить про этот стек по возможности объективно.

Мне нравится C#. Приятный язык, чем-то похож на питон. Тоже есть добротная функциональщина (в виде F#).

As a matter of fact, первый код, за который я получил деньги, был написан на шарпе.

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

(Бабочка машет крылышками и над Атлантикой шторм, да.)

Но задачи шарпа это почти всегда какие-то скучные бизнес-приложения вроде бухучёта или махровый энтерпрайз. :( Мы писали воркфлоу.

Меньше фриланса. И самое главное — анальная замкнутость на m$-стек.

Не то чтобы это было плохо, но я, как уже писал в кейсе с нефтянкой, люблю свободу, широкие стеки и широкие рынки.

При этом огромная куча людей работают с m$-стеком и вполне счастливы.

Тем более что m$ после ухода Балмера наконец дружится с опенсорцом,
маппит убунту на ядро windows и вообще няшечки *_*

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

Что не так:

1) закрытость стека (всерьёз фиксят)
2) неумение заходить на рынки
3) усиленный промыв мозгов сотрудникам

2 и 3 хроническое.

Если б не задачи, я бы писал на шарпе и бед не знал. Не сомневаюсь в этом.

Тут надобно сделать лирическое отступление и решительно объясниться, почему я так странно оцениваю языки.

Почему я много смотрю на рынок, задачи, применение вместо парадигм, ООП-фич, синтакса?

Наверное, для меня бизнесовый взгляд на инструмент превалирует над техническим.

Хорошо ли это? Для разработчика, наверное, не очень.

В этом плане я неправильный. (Ещё я неправильный тем, что люблю людей больше кода.)

Но тут ещё такой момент, что основные языки последние годы идут примерно в одну сторону.

У всех ООП, у всех функциональщина с красивенькими лямбдами.
Большинство умеет веб (или пытается). Даже синтакс выглядит почти одинаково.

Голое техническое сравнение имеет всё меньше смысла.

@backendsecret Думается именно так и стоит оценивать инструменты. Ведь 80% нашей работы сводится к решению проблем… twitter.com/i/web/status/9…

@backendsecret Типизация имеет прямое влияние на стоимость разработки и поддержки, например.

А особенности реализации многопоточности и работы с памятью - на принципиальную возможность создания продукта. twitter.com/backendsecret/…

от хороших языков к прочим. Джава..

(не "ява", во имя материнской любви)

..не является ни хорошим, ни плохим языком.

Джава посредственная.

Вот пост, с которым я согласен на 100% blog.plover.com/prog/Java.html

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

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

..но вам будет скучно, потому что обычно это махровый энтерпрайз.

Не знаю. Многим норм. А вам?

Особняком идёт андроид, который мы тут не обсуждаем, потому что это и не бэкенд, и не джава. Это не скоуп данного твиттера.

Если вы очень хотите писать на джаве, на вас тошнит от неё, берите скалу. Скала хорошая.

С ней прям можно жить. Правда.

Или котлин какой-нибудь. Его сделали няшечки @jetbrains из петербурга.

@backendsecret ну во первых современная джава довольно миленькая :) а во вторых scala/kotlin/clojure/etc

верить нельзя никому. :) Мне — можно.

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

Причём питон он любил, даром что был плюсовиком с двадцатилетним стажем. (Такие обычно питон презирают.)

Я считаю, это перебор. Джава не так плоха. Она посредственна, не позволит написать что-то прекрасное, но это инструмент как инструмент.

(ну ладно, может быть, иногда я смотрю видео с дотнетом, когда остаюсь один)

(вы ведь помните, да, что большая часть любого кода будет выкинута/переписана?)

что касается читаемости, у питона нет равных. Это фактически псевдокод.

кроме может быть функциональных и очень питоник-частей, но к ним быстро привыкаешь. Всё-таки язык делал математик, а не лингвист (Perl).

PHP.

Язык, с которым у питонистов заслуженная вендетта.

Плохой язык, что родился в тёмные времена веба.

Панченко @asfdfdfd : "люди, которые пишут на php/firebird, напоминают мне солдат, прятавшихся в лесу и не веривших, что война уже кончена."

@backendsecret @asfdfdfd @straykov YII - плохой пример. Symfony - лучший пример. Laravel - "пишите на фреймворке, а… twitter.com/i/web/status/9…

Но все эти различия языков в конечном счёте фигня.

В московском офисе @voximplant меня поил вкусным кофе @grigoryvp — человек, который свободно пишет код на десятке языков

Старайтесь выбирать инструмент под задачу, знайте его, будьте счастливы :)

Я вернусь завтра, а пока снова объявляется трёп без адженды.

@mr_mig_by @backendsecret Совет никому не поможет. Он может не подойти под контекст. А вот на фундамент из принципо… twitter.com/i/web/status/9…

Результаты опроса по языкам бэкенда, девятичасовой срез pic.twitter.com/FW9Di6r5ZP

надо помнить, что это твиттер. Многие из тех, кто пишет на PHP и Perl, в твиттере не сидят.

Очевидно, по этой причине эзотеричные эрланг с эликсиром обогнали пёрл.

Go обогнал ноду и шарп вместе взятых. Приятно видеть.

Джава и питон почти вровень. Но мы ещё повоюем :)

Скала куда-то потерялась. v_v

Вот более правильный пайчарт pic.twitter.com/evVSeysHHE

В две тысячи третьем и правда сложно в твиттере сидеть: его ещё не изобрели. twitter.com/backendsecret/…

продолжаем. Ещё один опрос: ваша текущая позиция

вот я — бэкендер, который последнее время старается стать полноценным Full-Stack.

зачем мне это? Во-первых, мне во фронте интересно. Во-вторых, я расту в CTO / tech cofounder, для чего требуется понимать все части.

Но я отдаю себе отчёт, что все фуллстек-девелоперы на самом деле миф.

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

Нельзя 100% эффективности/времени кинуть и туда, и туда. И интересно будет больше где-то в конкретном направлении.

Но залезать в соседнюю область стоит. Причём для вас как для бэкендера это может быть и не фронтенд. А, например, девопс или бизнес.

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

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

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

Я ошибаюсь?

@backendsecret Когда куча задач по бэку и фронту, фуллстек нужен скорее для координации остальных разработчиков. Ил… twitter.com/i/web/status/9…

@backendsecret Плюс есть комплексное видение проекта. Если добавить умение общаться с простыми смертными — получается латентный CTO.

@backendsecret Когда искала работу, то ни на одном собеседовании фуллстек не просили. Хотя я веб стек вплоть до HTM… twitter.com/i/web/status/9…

Давайте поговорим про тестирование.

Пишете тесты? Какие? До или после написания функционала?

в большинстве проектов, что я видел, тесты не писались. Частично QA закрывался мануальным тестированием.

частая фраза "у нас нет времени/денег ещё и на тесты, функционал не успеваем".

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

вы можете достичь эту уверенность разными способами. Можно через мануальщиков, можно через каверадж, можно гибридно, etc etc

Кстати, о TDD (и её новой инкарнации BDD).

считаю, что строго следовать ей (как и прочим экстремальным/нишевым практикам) нерационально.

но если вы однажды всерьёз писали по BDD, это сдвигает вам мозг в очень правильную сторону. Это как на хаскеле покодить. Рекомендую.

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

удивительно, но для некоторых проектов это не столь страшно. Например, если это MVP-однодневка.

А ещё покрыть тестами — самый простой способ лить в опенсорц. Многие даже именитые проекты имеют с этим проблемы. Сделайте доброе дело. :)

кстати, полностью аналогично с документацией. Её даже проще писать, наверное.

в проекте, где всё было организовано системно, твой PR не мог быть принят CI, если понижал каверадж dev-ветки.

писать документацию ещё одна штука, на которую традиционно забивают разработчики. Мол, я написал код, всё окей. Но это _часть_ вашей работы.

впрочем, в некоторых (крупных?) конторах за вас это сделают техписы.

@backendsecret А еще - придумывать иллюстративные примеры. И желательно - в формате кода, который можно чекаутнуть… twitter.com/i/web/status/9…

@backendsecret Техписы работают далеко не во всех условиях. Если проект сложный - то объяснить техпису что писать ~= написать самому

Тесты и доку писать очень стоит, если вы делаете OSS. Как верно замечает @andrey_sitnik, в наше время людям нужен не тупо код, а продукт.

@backendsecret А знаете, почему они имеют с этим проблемы?

Потому что это сложнее программирования.

современные реалии таковы, что вы не можете просто сесть и начать писать тесты. Нужны инфраструктура и отлаженные процессы вокруг неё.

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

@backendsecret Говорю всем: если вас на собеседовании спрашивают "можете ли вы в юнит-тесты", то отвечайте вопросом… twitter.com/i/web/status/9…

Старая песня. Смиритесь: язык живой и меняется. Это слово уже используется в этом значении.

twitter.com/vastepanoff/st…

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

и, может быть, вам и не стоит? Подумайте, чего точно вы хотите достичь.

кстати, вспомнил иллюстрацию на эту тему. Однажды в додопицце разработчик совершил ошибку при переносе бд между тестом и продом.

Контора потеряла 10 млн рублей (спойлер: вернула усилиями нетехнарей, создав шумиху).

В каментах на vc.ru все как один бросились обвинять криворукого разработчика, Яндекс.Кассу, кого угодно.

Хотя по факту в случившемся виноват был CTO (которого вскоре после этого сменили). Именно CTO отвечает за процессы технического характера.

Ну и косвенно виноват CEO, который взял такого CTO, конечно. Но он извинился.

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

Хорошие процессы поставлены так, что ошибку будет совершить сложно / недорого.

Давайте я вам ещё офигительных историй

В одну контору устраивался джун, и в welcome letter ему пришли все ключи и пароли от прод-окружений.

оказалось, в этой конторе такой welcome letter приходил вообще всем.

что было дальше, угадайте?

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

Кто виноват в этой истории?

А теперь вишенка на торте: у них не было бэкапа.

@backendsecret Вот линка про это reddit.com/r/cscareerques…

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

компания отнеслась понимающе, всё оплатила и сказала так больше не делать.

Парню из уфанета повезло меньше. Он ошибся с циклом и отправил одному важному клиенту 10 смсок. Уволили.

Катастрофы вызваны интерференциями ошибок в процессах.

Если джуны ходят в прод, у всех любые права, а бэкапа нет — you're asking for it.

@backendsecret Я не согласен на счет сто. Он может заенфорсить. За процесс должны отвечать все сместе. Сто несет от… twitter.com/i/web/status/9…

@backendsecret Кстати, пользуясь случаем, напомню несколько подкастов по теме: bit.ly/2hxpya2 И особенно S… twitter.com/i/web/status/9…

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

Давайте может за докер поговорим? Используете?

я жил со всем и долго. Вагрант, докер, деб-пакеты.

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

вот например эпохальный материал с критикой thehftguy.com/2016/11/01/doc…

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

Это редкая штука, даже очень редкая, но не дай боже вам её словить. Или какую-то подобную.

Тут, наверное, как со сбербанком: люди, которым везло, искренне не понимают людей, которым не везёт. Я вот невезучий, ловлю любые грабли.

при этом @sysradium много рассказывал, как CloudLinux готовят докер в проде и всё отлично работает. Верю, почему нет.

@backendsecret Ни в одной компании где я работал не писали тесты. В одной были пустые разговоры типа"о да... Надо б… twitter.com/i/web/status/9…

@backendsecret Всегда, на все, бэк. Как писать без тестов вообще не представляю.

@backendsecret тест - это гарантия выполнения определенного участка продукта с заданным качеством. А гарантия может… twitter.com/i/web/status/9…

@backendsecret я один раз случайно отключил антиспам на сутки. Гендир получил 20к писем. Не уволили, но просили больше так не поступать.

@backendsecret Не хватает ответа "к сожалению, в том числе в проде". У меня один проект сильно от докера пострадал, неумело приготовили.

@backendsecret Моя любимая статья про документацию :) gaperton.livejournal.com/60632.html

при этом я его слышал вообще от айосника. Что ж. Они правда традиционно больше таким заморочены, наверное?

давайте про оптимизацию поговорим. Какая самая важная штука, что нужно про неё знать?

на мой взгляд, это то правило, что оптимизацию стоит предварять профайлингом/рисёчем.

сложность (в значении complex) современных стеков такова, что у вас практически нет шансов угадать боттлнек правильно.

об этом говорил то ли @bobuk, то ли @umputun в #tadiot. И дело не в ваших знаниях io/сети/языка/алгоритмов/..

другое правило в том, чтобы не думать об оптимизации преждевременно.

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

1) напиши 2) напиши чисто 3) напиши быстро

если грубо, то итерации выглядят как-то так. Но куча людей сразу прыгает на последний пункт.

а теперь самый ужасный факт: скорость работы прикладного кода сейчас не является приоритетом.

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

ты можешь писать сколь угодно эффективный код, кастомные JSON-парсеры (да, увы, работал с таким чуваком), но что толку, если твой ПМ плачет?

@backendsecret Вообще хайлоад мне напоминает дым и зеркала. На самом деле большинство данных, которые вы видите в интернете - кэшированы.

@backendsecret Сервера асинхронных операций, шина опять же.. В общем оптимизация высоконагруженных приложений - это… twitter.com/i/web/status/9…

@backendsecret Иногда история про оптимизацию разворачивается в кардинальное изменение архитектуры системы.

@backendsecret чому. оптимизацию, если уж на то пошло, не с профилирования начинают, а с понимания "чо такое достат… twitter.com/i/web/status/9…

@vassilevsky @backendsecret Кстати, хорошая тема для обсуждения, content delivery, он вроде как на стыке бэка и фронта

@vassilevsky @backendsecret Просто все эти "Вы gzip забыли", "У вас CORS GET с префлайтом", "Вы max-age не шлёте",… twitter.com/i/web/status/9…

@sananbozkurt @backendsecret Пожалуйста! info.jetbrains.com/JetBrains-Meet… Торопитесь, мест мало осталось! :)

@akenoweb @backendsecret А вы пишете на своем бэке хеллоуворлды? А тесты нужны почти везде, потому что при рефактор… twitter.com/i/web/status/9…

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

смешно, казалось бы? Ну это ж очень косвенное отношение имеет к разработке?

но я видел конторы, где все жили в одной ветке и был запрещён рибейз.

и я видел разработчиков, большую часть времени использующих wip/fixes/две точки в качестве commit message.

и для меня процессы вокруг dvcs говорят больше, чем многое другое.

Как вы относитесь к git rebase? (и его частям, меняющим историю: сквош, аменд, ..)

(предполагаем, разумеется, что речь о фичебранчах)

@backendsecret в своих бранчах - всегда. Но только что бы сквошнуть коммиты типа "fix, fix fix, fix for fix, bla bla".

@backendsecret линейная история круто

@backendsecret Ключевые слова - trunk-based development, branch by abstraction, feature toggles

@backendsecret Так я могу нахуячить говна в ветке, зачем мне оно в истории? Надо причёсывать прежде, чем вливать.

я люблю рибейз. Это путь к чистой и внятной истории коммитов.

разумеется, никакого изменения истории в шаред-ветках. А на основных ветках вроде develop, master, .. вообще должен лежать протект.

что ещё является хорошей практикой на мой взгляд, как правило? git-flow

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

под проект, кейсы, опыт и команду.

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

Что ещё ведёт к чистой истории в гите?

Правильное соглашение о коммит-мсджах.

я евангелю chris.beams.io/posts/git-comm…, но у вас может быть своё.

@backendsecret Не, на самом деле можно делать сравнительно быстро и весьма качественно (как мы например, хех), но это стоит овердохера денег

корневой момент: существующее соглашение в команде важнее, чем идеальное / в которое вы верите

я будучи джуном много воевал по глупости за идеальный мир.

сейчас я всё ещё воюю за него, но делаю это с нежностью и пониманием.

мыслите не от "как надо", а от "как есть, почему так есть и зачем/как это имеет смысл изменить"

и если решились, наметьте срок итерации, после которого взвесите всё снова.

Давайте об инструментах?

Хардварь, софтварь. Рабочее место.

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

сижу на чём попало. Вот это очень неправильно: спину лечить дорого, сложно, неприятно, и не довылечишь.

использую Linux (Ubuntu, Fedora). На маке мне тоже работать было в кайф. Обе ос отличные.

а вот Windows для разработки всё ещё неудобна. Они стараются, и есть куча полезных хаков/тулов, но нет. Простите.

из IDE у меня персональная лицензия на @intellijidea и я доволен. Оплачивает всё мой работодатель.

ну то есть это всё ещё неплохое железо и неплохой софт, но value у них сейчас очень низкое лично для меня.

@backendsecret @intellijidea Платил год за вебшторм. Потом уволился и ушёл с Большого Проекта. А свой код комфортне… twitter.com/i/web/status/9…

@backendsecret HermannMiller, Corei7/16GB, 24'' монитор (один), игровая мышь, регулярно меняю клавиатуры, игровой н… twitter.com/i/web/status/9…

@bhjkaser @backendsecret @intellijidea linux mintIDE phpstorm плачу сам, goglang пока сырая бесплатная.
Пытался р… twitter.com/i/web/status/9…

Переключение раскладки у меня на CapsLock. Ну а чего, бесполезная же клавиша. Linux позволяет настроить такое из коробки.

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

Давайте сочную тему возьмём. Что определяет хорошего тимлида/техлида?

Мне почему-то везло, как везёт всем дуракам. Я учился и учусь у лучших.

есть классический тред news.ycombinator.com/item?id=103950… про это

pic.twitter.com/dZTiCAfOIO

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

вам требуется опыт. Как хардкорный, так и софткорный. Умение слышать бизнес. Умение защищать людей от бизнеса и бизнес от людей.

неплохо быть готовым пробежать лишнюю милю. Если вы не готовы, от вас этого всё равно потребуют. Смиритесь.

вы не сможете столько времени уделять коду, как в те времена, когда были сеньором. Вас будут жрать митинги, орг проблемы. Смиритесь.

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

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

а ещё вы столкнётесь с непониманием. Его будет много.

И вас будут не любить за ваши решения. Вот про это подробно:
facebook.com/photo.php?fbid…

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

и по аналогичным причинам не открывают дело.

Не знаю.

Для меня это было не "не хочу начать", а "не могу не начать". Оно сильнее тебя.

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

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

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

снова и снова, опять и опять.

Учитесь формализации своих мыслей. Учитесь стоять на идеалах и идти на компромисс. Учитесь слушать и слышать.

сегодня это важнее, чем заучивать, как разворачивать бинарное дерево на салфетке. Последнее гуглится за минуту.

попросили меньше ретвитов. Попробую более вдумчиво.

@backendsecret Куда нам без контейнеров? github.com/clearcontainer…

Что делает разработчика счастливым?

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

Но есть два фактора, о которых большинство забывает или игнорирует. Это сон и коммьютинг.

Принято недосыпать.

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

Даёт ли это повышение производительности?

На локальном отрезке да. На глобальном отнимает и ведёт к ускоренному выгоранию.

Все по-своему переносят депривацию сна. Я вот как варёный и ни о чём думать не могу, медленно умираю, когда недоспал. А вы?

Как с этим бороться?

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

А ещё переработки не должны быть систематическими. Знаю, есть отрасли, где это не исправить. Возможно, вам стоит оттуда уйти?

Сильно помочь сну может сокращение коммьютинга (времени, затрачиваемого на дорогу между домом и работой).

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

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

Если вы добираетесь более чем ~40 минут в одну сторону, статистически уровень счастья начинает падает. И падает нелинейно

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

Да, люди находят способ себя занять в дороге. Поспать, послушать подкаст, почитать, пообщаться в соцсетях.

Это всё равно очень сублимированная эффективность, к сожалению. И лишь частично решает проблему.

Как сократить коммьют?

Берите удалёночку. Её с годами стало больше. Удалёночка есть добро.

Или просто арендуйте жильё у работы. Стандартный способ решения проблемы у миллениалов: отказаться от устаревшего концепта home-ownership

Кто-то любит офис. Без проблем. Много проектов позволяют выбирать дни недели, когда проводишь в офисе, а остальные дни работать удалённо.

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

Это значит, что доехать куда-то за 60 минут, но по прямой, намного удобнее для вас, чем доехать за 40, но с тремя пересадками.

Ну и, конечно, есть адские города, где коммьют сократить нет возможности, ибо стоимость аренды в центре запредельная. Это Москва.

Москва в этом плане настолько адская, что отчёт stackoverflow за 2016 год отдельно выделил её фразой про неадекватн… twitter.com/i/web/status/9…

Задумайтесь о том, чтобы не работать в Москве, как бы смешно эта мысль для вас не звучала. Или хотя бы в московском офисе не работать.

Другим специальностям нет пути без Москвы. Например, топовому айти-рекрутёру или финансисту мирового уровня.

Разработчику без Москвы норм.

@backendsecret Когда то я пешком ходил до офиса и совершенно не было времени на себя. Семья - работа - семья работа.

@backendsecret Сейчас еду полтора часа в одну сторону, минут сорок из них в электричке. Можно покодить. Lisp, opensource, петтродекты. Лафа.

@backendsecret Из личного опыта - я тоже был дурак и работал весело и задорно по 12-14 часов.
Больше так не хочу, хоть и по фану было

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

в этом плане очень хороши фриланс/консалтинг. Вы сами себе хозяин и планируете часы в день. Клиента они обычно мало волнуют.

за исключением часов присутствия, когда, например, митинги, конечно.

Но для успеха нужны офигенные софткорные навыки. Самодисциплина, планирование, переговорный навык, навык продаж.

Иначе вы пополните собой ряды несчастных фрилансеров или фрилансеров-факаперов, что стали притчей во языцех у клиентов.

Собственно, это причина дурной репутации фрилансеров. Многие из них решают, что готовы фрилансить, раз умеют в ЯП/технологии.

Особенно плохо, когда во фриланс идёт джун. Потому что у него нет понимания как управлять проектами.

Поэтому джунам я стараюсь советовать поработать какое-то количество лет в команде. К сожалению, это не всем доступно. Например, в провинции.

и кстати фуллтайм тоже вполне себе бывает с оплатой за часы, а не подённо

почитайте, например forbes.ru/karera-i-svoy-…

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

Кому-то не нравится удалёнка из-за отсутствия социализации. Кто-то на это отвечает, мол, я лучше пообщаюсь с друзьями, чем с рандомами.

Не знаю. Мне плюс-минус хорошо как в офисе, так на удалёнке. В этом плане мне снова везёт.

Вот вам радикальное, но хорошее мнение от @ilyabirman: ilyabirman.ru/meanwhile/all/…

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

..но один за 60 тысяч рублей, а другой за 3500 долларов. Да. Этот пример из практики.

но это не единственная причина. Другая — незнание рынка.

И вот тут я вас плавно подвёл к теме митапов и конференций. Оу, держитесь. Это мой конёк. ^_^

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

Можно вести себя так и сейчас, но это выйдет вам дороже. И в цифрах дохода, и в знаниях. Швеи-одиночки теряют цену.

Чтобы знать рынок, надо общаться с людьми. И очно общаться. Ходите на интервью (даже если не ищете работу), митапы и конференции.

Участвуйте во фронтенд-завтраках. Пейте на дринкапах. Слушайте и рассказывайте.

не сформулирую лучше Келсо, впрочем pic.twitter.com/w23zGQIQzZ

в айти всё то же самое, только скорость и количество изменений ещё выше.

А ещё важно не просто слушать, но и выступать. Учиться сторителлингу. Учиться выражению мыслей. Учиться технологиям через своё выступление.

вот отличный материал от @grigoryvp про это habrahabr.ru/company/mailru…

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

"Болтология", "делают маркетинг", "кто не умеет, тот учит"

смело плюйте на эту стигму и ссылайтесь на меня. Сейчас я расскажу, чем она вызвана. :)

Разработчикам свойственно защищать экспертизу. У нас инженерное ремесло, и без такой защиты оно развалится (вероятно).

Но публичные выступления (посты в блогах, доклады, ..) не являются угрозой для экспертизы. Они тоже инструмент обучения.

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

Так было в СССР: мы смотрим что-то по телевизору, читаем в газетах, и верим, что человек эксперт. Ну а как иначе он бы попал туда?

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

новые концепты называются work & tell, а ещё learn in public. Это отличные и мощные идеи, которые вас забустят.

на #yac2017 был отличный доклад про это от Ольги Павловой: medium.com/sobaka/%D0%BA%…

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

и да, оно в том числе про прокачку вашего бренда. Или бренда вашей конторы. Что в этом плохого?

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

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

@BeiZero @Dmiterko_Roman @backendsecret Соль в том, что при самозанятости, эффективно работая 4 часа в день по свое… twitter.com/i/web/status/9…

Чуваки.

Не надо ревностно защищать Москву, пожалуйста. Я сам знаю, что хорошая. У меня про это лонгрид даже был: facebook.com/nazarov.tech/p…

речь была исключительно в терминах аренды и коммьюта для разработчика.

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

и со временем этот тренд будет только нарастать.

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

@etosova @backendsecret со мной живет отличный пример — учился на филфаке, научился прогать, сейчас работает senior… twitter.com/i/web/status/9…

Но у них выше риски, чем у нас, и менее интересная работа. А ещё конкуренция выше twitter.com/evgenyrodionov…

хотите стать руководителем — почему бы не прийти туда из разработки? Знакомый ПМ, получающий 5к долларов, всё грустит, что без бэкграунда.

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

касательно рисков: программист в этом плане вообще уникальная профессия. У нас рисков ноль.

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

Отличный пример: так с программистом-то ничего не случилось. CTO сменил работу, но наверняка у него тоже всё ок twitter.com/evgenyrodionov…

какие вы знаете способы попасть в срок?

@evgenyrodionov @backendsecret а на практике twitter.com/tedneward/stat…

@backendsecret Не делать жёсткие сроки. Нет сроков - нет стресса. Нет стресса - здоровее программист.

@backendsecret Хорошая декомпозиция задачи (WBS) + PERT. У меня всегда работает, если скоуп хорошо определен. Для F… twitter.com/i/web/status/9…

@backendsecret Делать всё в последний день😂

@backendsecret Вести расчёт в идеальных часах (у нас есть 4 идеальных человека-часа в день) и планировать на каждого человека персонально.

@backendsecret Я думаю что слишком далеко планировать в принципе невозможно.
Начинаем с важного, не тратим зря врем… twitter.com/i/web/status/9…

@backendsecret Иметь опыт разработки подобного, расписать на задачи по 4-16 часов, умножить итог на 1.3

@backendsecret Не распыляться на несколько проектов/задач. Погружение в один проект творит чудеса – делаешь даже больше, чем планировал.

Итак, эстимейтинг — одна из крупных болей разработки.

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

первое правило, что я услышал от тимлида — "умножай на пи". Это значит, что свою оценку вы должны умножить на 3.14.

У всех эта константа своя.

Правило призвано пофиксить оптимизм программиста. Мы все оптимистичны в оценках.

"Не так страшны первые 90% проекта, как вторые 90% проекта"

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

Это метод прогрессивного джипега artlebedev.ru/kovodstvo/sect…

и бюрошная методология #fff
bureau.ru/about/fff/

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

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

важное правило номер раз: в эстимейтинге должен принимать участие человек, которому это пилить.

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

и подгоняться под то, как каждый человек перформит. А ещё чтобы считать велосити.

важное правило номер три: нет задач на день или на неделю. Есть на 1, 2, 4 часа. Если больше — это не задача. Декомпозируйте.

потому что задача на день может быть и на три. А задача на неделю может быть на месяц.

Существует практика эстимейтить исходя из наработанного опыта. По этой практике все задачи делятся на несколько категорий:

риддлы (не знаю, как делать)
обычная задача (не делал, но представляю как)
рутина (уже делал и знаю, как)

Деление может быть иным.

и в зависимости от категории разный подход и разная оценка. Риддлы вообще нельзя эстимейтить. На них ставится отдельная задача на рисёч.

Если вы работаете с клиентом сами (минуя ПМа), например, во фрилансе, не забудьте побить проект на майлстоуны. Так безопаснее вам обоим.

Вот большой и адекватный материал на тему эстимейтинга forasoft.github.io/software-estim…

Что делать, если вы менеджите сразу несколько проектов, деля ресурсы (время)?

Фиксед слоты + регулярно чекаем, что больше горит, и свичимся

Эстимейтинг в этом случае ещё больше усложняется. Закладывайте гэпы. Волшебного решения, увы, нету.

и айти традиционно такими полна. Сочувствую всем нам, мы знали, на что шли.

В обычной команде за software delivery (в т.ч попадание в сроки) отвечает тимлид, и он же чинит проблемы, связанные с этим.

Техлид (если это отдельный человек) занимается больше архитектурой и кодом.

Впрочем, эстимейтить вам всё равно придётся и постоянно, так что учитесь этому навыку.

Вся наша жизнь это эстимейтинг. Вся наша жизнь это продажи. Вся наша жизнь это инвестиции.

Тут смотря с какого угла посмотреть.

учитесь разным навыкам. Так завещал ещё умница Хайнлайн pic.twitter.com/myF8J5PVQZ

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

Зачем стив джобс учился каллиграфии? Ведь она не помогает производить железо или софт.

Но полученные навыки помогли продуктам эппл выглядеть круто. А чувство прекрасного повлияло на видение.

Зачем на моей полке стоит book.glvrd.ru Ильяхова? Ведь программист пишет код, а не тексты.

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

Не говоря уже о подписях к кнопкам и текстам лендингов. (Нет, макет не покрывает все кейсы. Марсиане твердят об этом постоянно.)

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

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

Ищите свои.

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

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

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

А ещё я писал lua-скрипты для вова и прокачивал лидерство, водя 25ppl-рейды.

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

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

на этой ноте я прервусь на дела, а вы позадавайте свои комментарии пока :)

—Ты чо код не пишешь?
—Вы не понимаете, наше ремесло шире и глубже.
—Анус твой сейчас станет шире и глубже! Код пиш… twitter.com/i/web/status/9…

Сайд-проекты, OSS, митапы — это всё круто, конечно.

А что делать, если времени нету на них? Откуда взять?

мало работа, так ещё же есть семья. Друзья. Увлечения. Квартира и машина.

какие-то компании (вроде Google) предоставляют человеку время на собственные проекты и развитие. Скорее всего, вы в них не работаете. :(

(я в них тоже не работаю)

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

есть радикальный подход: первые лет десять-пятнадцать усиленно топить карьеру, забив на всё остальное. Типа, остальное ещё успеется.

@vergeev @backendsecret А потом на собеседовании у тебя спрашивают «А почему у вас github пустой?»
ПОТОМУ ЧТО Я РАБОТАЮ, БЛЯДЬ

@backendsecret Вроде гугл уже перестал так делать или порезал возможности

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

Но большинство из вас не работают в таких конторах. И я тоже.

Так что же остаётся?

@backendsecret а потом оказывается, что вся жизнь прошла мимо

Искать правильный для себя work-life balance. Планировать дни, чтобы в них было больше продуктивных часов. Работать эффективно.

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

Первые десять лет вам придётся учиться фокусу и приоритетам. Кому-то это удаётся очень быстро. Кому-то не удаётся на протяжении всей жизни.

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

Только лишь страдание несёт в себе интенсивное развитие. Эту мысль мне когда-то сказал пожилой девопс.

Суббота.

Как бессемейный разработчик может проводить свой выходной?

в диджитале есть практика отдавать всю рутину вроде мытья посуды или уборки дома на откуп чувакам с youdo и qlean. Наше время стоит дорого.

я пробовал, но понял, что не моё.

У меня есть специальный парко-хозяйственный день – суббота.

зачем так делать?

Почитайте rakh.im/weekend_cleanu…

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

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

в воскресенье я стараюсь устроить чистый-чистый выходной. Без дел.

Планирование дня и недели, кстати, чертовски важная штука. Сейчас проиллюстрирую.

мы как-то ужинали на афтепати со спикерами крупной конференции. Их было где-то десяток за столом.

ребята серьёзные. Многим за сорок. Очень крутые, из проектов с именем. Руководители, ЛОМы.

что меня поразило – их общая черта. У каждого, как оказалось, был чёткий распорядок дня.

и что особенно удивительно, у многих был слот в духе "час на саморазвитие". Чтение дайджестов, кодинг пет-проджектов. Каждый день.

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

именно поэтому деревянная табличка над моей дверью гласит "focus & discipline". Это те последние штуки, которых мне не хватает в жизни.

возможно, вам тоже? Или это скорее редкость для разработчика?

Поговорим про источники.

Какие подкасты, ресурсы, блоги, книги, дайджесты, сообщества или конференции принесли/несут вам большую пользу?

сам я читаю @ThePracticalDev, хожу на питерские митапы, иногда слушаю #radiot

ещё у нас есть несколько тематических чатов в рабочем слаке. Заодно поддерживает атмосферу.

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

из необычного. Очень хорош недельный дайджест @stackshareio. И посты @codehipsters.

вот эпик тред про книги stackoverflow.com/questions/1711…

могу отметить

Code Complete
The Pragmatic Programmer
Surely you're joking, Mr. Feynman

кнут мне не оказался особенно полезен. Он чересчур ударяется в хардкор. Намного круче книги Седжвика.

впрочем, это дело индивидуальное. Начинайте читать всё, что повернётся. Продолжайте то, что пришлось по вкусу.

Однако я не советую читать (и тем паче покупать) прикладные книги. Они устаревают ещё до выхода.

Томиком мануала по старой версии JQuery или старой версии дотнета сейчас разве что камин растапливать.

И ради всего святого, не читайте ничего про разработку на русском. Если вы не 1С-программист, конечно.

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

Используйте вместо него реддит, hackernews, зарубежные блоги.

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

Есть интересная штука про хороший контент: он влечёт за собой ссылки на другой хороший контент. Цепная реакция.

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

И, как и с людьми, "you shouldn't be the smartest person in the room". Ищите источники контента, которые заставляют вас думать и учиться.

И помните: приоритеты.

Ошибка новичка здесь – забить инфопотоки под завязку. Толку от такого ноль. Ищите своё, смело режьте остальное.

А ещё наше ремесло сугубо практическое.

Это значит, что сделать что-то самому обычно учит эффективнее ста чужих материалов.

а потом, я надеюсь, вы расскажете о сделанном уже другим ;) work & tell

Английский язык. Ещё одна больная тема.

Обязателен ли он? Для кого? В какой мере?

я считаю, что обязателен. Мы профессионалы, и работаем в глобальном мире.

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

многие из вас знают его в какой-то мере, но боятся говорить, например, поскольку нет практики. Это глупо)

никто не осудит вас за уровень языка. И даже не выскажет неодобрения. Зарубежные чуваки не страдают нацизмом.

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

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

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

не течь, а тек.
не дата, а дейта.
не хеигхт, а хайт.

habrahabr.ru/post/124403/

однажды я сделал вежливое замечание разработчику (наедине, разумеется: "хвали при всех, критикуй тихо"), что services — это не "сервИсес"

и в ответ получил хмыкающее "ну ты что же, будешь теперь всех переучивать тут?"

Буду.

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

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

Кстати, распространяется это не только на людей, прямо подконтрольных мне.

Если ошибку допустил дизайнер/контентщик/пиарщик/эйчар из соседнего департамента, я найду способ добраться до человека и добиться фикса.

Позиция "моя хата с краю" мне не близка ни разу. Если я в проекте/конторе — мы плывём в одной лодке и меня заденут и не мои косяки.

Аналогично я поощряю людей не из разработки приходить и сообщать о проблемах, будь то мелочь (опечатка) или нечто крупное.

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

Обычно такому рады. Странно, да?

Не странно. Всегда комфортнее, когда тебе сообщает о проблеме кто-то внутри.

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

Это снова что-то такое русское, видимо.

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

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

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

И снова из личного. По дурости я не боялся увольнений и всегда спорил в важных случаях, включая конфликты с CEO.

Мне ничего не сделали.

@backendsecret Один думает "ну мне же скажут, если я не прав", другой думает "ну он наверное же знает что делат"

@backendsecret это не русское, а азиатское. Особенность жизни в авторитарном окружении.

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

Как распознавать такие случаи будучи подчинённым, я и сам не очень понимаю пока.

Пробуйте максимально коммуницировать, а там по ситуации?..

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

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

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

Что вам в целом может помочь?

Умение слушать людей и разговаривать с ними. Эмпатия. Развивайте эмпатию.

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

И таких контор много. Мало в СНГ, но очень много в мире. Я в берлине много общался с разработчиками и тимлидами.

Русские традиционно не умеют в инвестирование и в долгосрочный/косвенный профит. Они не понимают, как конференции принесут им деньги.

Как ни странно, это понимают крупные компании у нас. Яндекс, Мейл, ..

Все, кто крупный, наконец мутят движ и растят кадры. Это отлично! ^_^

в Берлине маленький стартап пошлёт тебя, джуна, на крупнейшую конфу в Будапешт на 3 дня. Оплатит дорогу и проживание.

Как вам это?

@backendsecret Это точно. Каждый раз когда я не интересовался смежными областями и считал что они знают что делают… twitter.com/i/web/status/9…

и дело не только в деньгах, а ещё и в отгулах на эти дни, например. Откуда вы их возьмёте?

как говорил Циолковский, "регионы — колыбель человечества. Но нельзя же всю жизнь прожить в колыбели"

Вырастайте и переезжайте в петербург/москву. А когда вырастете и из них, вас ждут берлин/лондон.

И ничего никогда не бойтесь.

На этом я заканчиваю день и объявляется свободный трёп.

@backendsecret Это круто! Это прям как у @RayDalio. Правильно что в компании по поводу работы все открыто, всм, каж… twitter.com/i/web/status/9…

"пел, пел про абсолюты и мерил нас по рок-н-роллу"

Неделя была софткорная. Всё как надо. А что постгре быстрее мон… twitter.com/i/web/status/9…

"и время его истекло,
и тот, который во мне сидел, вдруг ткнулся лицом в стекло"

Прощайте, зайцы. Привет из спб.… twitter.com/i/web/status/9…