Три повседневных навыка в работе программиста

 Публичный пост

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

В связи с этим хочу попросить сообщество [программистов] написать примерно 3 навыка (можно меньше), которые вам нужны практически каждый день (ну или чаще других). Навыки должны быть конкретными, такими, которым можно целенаправленно научиться самостоятельно (скажем, если вы останетесь одни, у вас будет компьютер, интернет и подходящая книжка). Не обязательно они являются сутью вашей работы: например, вы можете работать над автономными роботами, но навык, который вы указываете - умение писать юнит-тесты на Python. Как правило это те действия, которые вы делаете часто и "из головы", хотя я не хочу ставить такое условие - вполне обычно, если вы иногда смотрите в документацию

Пример подходящего навыка - применение awk в bash скриптах для вытаскивания ошибок из логов.

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

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

Снова зачем - чтобы дать начинающим и не только разработчикам информацию о том, чему уделить внимание.

На примере меня (программист инфраструктуры СУБД), 3 навыка:

  • умение писать с ходу jsonpath выражения (чтобы выстаскивать поля из K8S объектов)

  • умение писать умеренно сложные SQL запросы из головы (статистика работы сервисов лежит в СУБД, иногда приходится использовать window functions, и CTE чтобы, скажем, сегментировать время ответа сервиса и скоррелировать дату с каким-то еще событием)

  • умение писать unit и regression тесты на Gо.

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

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

Ваш ход :-)

59 комментариев 👇
Yury Katkov, миддл формошлёп 1 июля в 21:40
  • маппить массивы в другие массивы
  • умение делать маленькие инкрементальные изменения, результат которых можно посмотреть прям щас. Привычка в каждый момент времени иметь пригодную к демонстрации версию фичи, которую ты точишь.
  • при написании новой фичи - умение найти в проекте похожую фичу и применить тот же подход (скучный и однообразный код - лучше чем необычный и разнообразный)
  • чутье насчет того, где лучше писать кастомное решение, а где городить свои огороды ни в коем случае не надо (например, работа с датами и временем, парсинг файлов, задачи разбиения текста на строки, расстановка переносов и прочий layout)
  Развернуть 1 комментарий

@ganqqwerty, маппить массивы? т.е. например использовать векторные функции, а не поэлементно, или о чем ты?

  Развернуть 1 комментарий

@sol, ну типа есть у тебя массив объектов таких-то, а надо из каждого него понадергать свойств и сделать массив объектов сяких-то

  Развернуть 1 комментарий

@sol, верстаешь такой экранчик для странички банка. На страничке отображается [например] список контрагентов. В заголовке элемента у тебя имя контрагента [КА], а в подзаголовке степень риска взаимодействия с ним. Вот список КА (с именем, ИНН, номером телефона и прочим) может отдавать один сервис, а статус этого КА - другой сервис

То есть, нужно сделать два запроса в два разных сервиса, получить два массива (Contractors и ContractorsStatuses), а на основе двух этих массивов сделать один, дергая уникальные данные каждого из массивов

Например, из Contractors берешь ФИО, id, ИНН, еще чего, а из ContractosStatuses только статус, так как условный id уже взяли из первого массива

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

  Развернуть 1 комментарий

@fillooow, хм, а это точно общепризнанный термин?

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

  Развернуть 1 комментарий

@sol, ну я конкретно пример Юрия более наглядно показал

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

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

  Развернуть 1 комментарий

@sol, даже соответствующие классы и функции будут называться SomethingSomethingMapper

  Развернуть 1 комментарий
  • Умение пользоваться vim'ом. Если надо подправить конфиг или чуть изменить скрипт на удаленной машине, то vim — это единственный редактор, который по умолчанию там есть. Даже если пишешь код в супер крутой IDE, даже если фанат emacs'a (каковым я и был до определенного момента), навык работы с vim экономит кучу времени.

  • Понимание, как работает Git внутри. Чтобы git merge, reset, rebase, etc не вводили в ступор и не порождали снежный ком косяков. Рекомендую книгу Version Control with Git. У нее еще летучая мышь на обложке.

  • Пункт применим не ко всем, но тем не менее: умение захватывать и анализировать сетевой траффик в Wireshark или подобном инструменте. Отлично дополняет development mode браузера и помогает находить тонкие низкоуровневые баги.

  Развернуть 1 комментарий

@ktrushin, вот это в точку! К vim я бы ещё добавил tmux и в целом «уверенность» при работе в терминале. А вместо wireshark я бы упомянул tcpdump — опять же из-за консольности и, как следствие, универсальности

  Развернуть 1 комментарий

@ktrushin, Либо вместо того, чтобы изучать ещё один редактор, освоить tramp-mode.

  Развернуть 1 комментарий

@dottedmag, это хорошая опция, но лично мне этого показалось недостаточным.

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

  Развернуть 1 комментарий

@ktrushin, Ну... tramp-mode и с M-x shell интегрируется.

Я согласен, что vi где-нибудь далеко за тремя jump-хостами удобнее, чем пропихивать TRAMP. Но если это один SSH-хоп, то можно из Emacs не вылезать.

  Развернуть 1 комментарий

@dottedmag, спасибо за подсказку. Буду иметь ввиду.

  Развернуть 1 комментарий
Egor Suvorov, Программист/преподаватель C++ 1 июля в 21:19

Три про отладку:

  • Чётко формулировать "ожидаемый" и "реальный" результат от неработающего кода.
  • Минимизировать код с проблемой до MCVE при помощи двоичного поиска по коду: закомментировали половину/убрали внешнюю зависимость/захардкодили данные, проверили, воспроизводится ли проблема.
  • В уме: интерпретировать/компилировать сниппеты на 5-15 строк и запускать их на небольших данных. Полезно, когда происходит какая-то чушь, а минимизировать больше некуда. Тогда уже надо либо опечатки/баги искать глазами, либо репортить баг в компиляторе/своём понимании языка программирования.
  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@yeputons, Дениска Абрамов одобряэ бинарный поиск по коду!

  Развернуть 1 комментарий

@yeputons,

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

это хорошее описание юнит-теста :-)

  Развернуть 1 комментарий

@yeputons, двоичный поиск по коду - просто в голос от названия метода.)

  Развернуть 1 комментарий
Миша Гусаров, Инженегр-погромист 2 июля в 07:51

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

Неконкретно, но тренируется с помощью задания себе вопроса «это точно первопричина?»

  Развернуть 1 комментарий

@dottedmag, иногда доходит даже до вопроса "а этот код вообще нужен, или уже нет?" :)

  Развернуть 1 комментарий
  1. Навык не сдаваться после N-ого по счету фейла. Каждый раз находить путь, который ещё не проверен, и после этого найти силы его проверить. Этот навык принесёт вам славу. Но единственный способ его получить, который я знаю - это фейлить.
  2. Найти что-то в повседневной работе, самую мелочь, какой-то аспект, который приносит удовольствие. Сильно связан с предыдущим пунктом, потому что ничто не мотивирует лучше, чем успех, а неудача демотивирует сильнее всего. "Ну и что, что я положил базу на проде, зато я сделал это неизвестным ранее способом!"
  3. Постоянно изменять своё рабочее окружение. Новый язык, фреймворк, тулза, оптимизированная сборка, да хотя бы новый алиас в консоли - делайте что-то новое постоянно. Иначе пиздец, стремительный и неотвратимый.
  Развернуть 1 комментарий
Holovin, разработчик−дизайнер 1 июля в 21:22

— гуглить
— использовать дебаггер (а не console.log / echo / print)
— потратить 2-3 минуты на решение вопроса самостоятельно, а уже потом спрашивать у кого-то «постарше»

  Развернуть 1 комментарий

@holovin, по второму пункту - есть полярно противоположная рекомендация и несколько анекдотических примеров, нагугленных на скорую руку:

  Развернуть 1 комментарий

@ganqqwerty, я не говорю что нужно всегда использовать дебаггер, нужно хотя бы уметь и знать про него. А то больно иногда смотреть, когда люди извращаются с принтами чтобы сложное что-то вывести, когда можно в 1.5 клика глянуть в дебаггере.

  Развернуть 1 комментарий

@holovin, согласен, или когда люди не знают про watches и долго и упорно идут по шагам или повторяют итерацию цикла пока не дойдут до нужного значения переменной.

  Развернуть 1 комментарий

@hintbits, print statement внутри if’a! (Картинка Винни-пуха в смокинге)

  Развернуть 1 комментарий

@ganqqwerty, во времена кернигана наверное не было еще нормальных дебаггеров вместе с IDE + eval expression.

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

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

  Развернуть 1 комментарий
Nikolai Lopin, Фронтендмейстер 2 июля в 06:03

Самое сложное в освоении для меня:

  • Придумывать, как разбивать задачи на маленькие PR, чтобы их быстро смотрели
  • Умение работать с фича флагами, чтобы выкатывать неготовые фичи в прод. Не всегда очевидно, куда их поставить. Плохой навык оборачивается ветками с «новой версией», которые требуют много координации и работы
  • Умение писать тесты, которые имеют смысл и мокать зависимости (каждый раз страдаю с этим в Jest)
  Развернуть 1 комментарий
Ярослав, Data Analyst / Data Engineer 4 июля в 12:23
  1. Концентрация внимания (ядрёный и редкий навык)
  2. Абстрактное мышление
  3. Скоропечать
  Развернуть 1 комментарий

@yaroslav_miroshnikov, а третий пункт-то зачем? Часто упоминается как мастхев, но собсна в 2021 везде есть автокомплит и интеллисенс, из-за чего никто уже не пишет полотна кода как на печатной машинке. Уже хоткеи и то сильно больше нужны

  Развернуть 1 комментарий

@kadron141, 1) Предпочитаю даже первыйе пару символов не набирать однопальцевым методом.
2) Комментарии к коду и документацию делать как будешь? Автокомплит тут не поможет.
3) Коммуникация в чатах занимает время, тоже одним пальцем без проблем будешь печатать?
4) А в гугл запросы вбивать?

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

@kadron141, В целом согласен, но, всё-равно считаю, что скоропечать — важный навык для каждого, особенно для кодера.

  Развернуть 1 комментарий

@yaroslav_miroshnikov, ну вот я не умею, например) Когда проходил различные тесты на скорость печати, то моим методом, который тупо выработался за годы сидения за компом, выбивал наравне с десятипальцевым (по нижней границе). Я печатаю вслепую 5-6 пальцами но ходят они нифига не оптимально, просто очень быстро. И я вот хоть убей не пойму нафига мне мучать себя чтобы печатать ещё быстрее, вроде как в марафонах на переписывание "войны и мира" я не участвую :D

  Развернуть 1 комментарий

@kadron141, Я понял. У нас разная дефиниця скоропечати.

Я НЕ имел ввиду «правильный метод, с приучением правильной постановки пальцев на клавиатуре, и попеременным нажатием на пробел большими пальцами левой\правой руки»

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

  Развернуть 1 комментарий

@yaroslav_miroshnikov, а, понял, ну тут согласен, без этого тяжко жить) Просто в среде программистов обычно люди уже быстро пишут, поэтому когда кто-то набрасывает на эту тему, то речь идёт о десятипальцевом методе и как он крут, но никто не может объяснить, почему)

  Развернуть 1 комментарий

@kadron141, а, понял, не, я не адепт Шахиджаняна))) проходил его курс скоропечати, но не сектант.
просто хотел более эффективно печатать, т.к. часто в чатах болтаю, и ваще раньше моя деятельность была сильно на копирайтинг завязана.

  Развернуть 1 комментарий

@yaroslav_miroshnikov, ух бля, мне до сих пор от него рассылка умудряется проходить фильтры иногда))

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий
Петушков Александр, Самодур и сквернослов 2 июля в 07:52
  1. map
  2. filter
  3. reduce

а еще твердо сидеть на попе в миллионный раз делая одно и то же

  Развернуть 1 комментарий
  1. Регулярки!!! И парсинг, и сложные эндпоинты, и sed, и валидаторы, даже поиск файлов/текста в IDE.

  2. Умение пользоваться cat/grep/find/awk/sed/xargs и т.д., писать на баше. Очень полезно для работы с большим количеством файлов, при работе с процессами/контейнерами на компе, при анализе логов и т.п. Можно скриптовать рутинные операции (например, git-хуки)

  3. Работа с ssh, sshfs, scp, а также с ключами, настройкой хостов и ключей в ssh-конфигах, и работа с ssh-агентом. Умение с ними работать помогает настроить любое рабочее окружение под любой сетап. Особенно, когда у вас несколько гит-серверов, есть удаленная и локальная машины и т.п.

Всё это пригождалось всегда, независимо от стека

  Развернуть 1 комментарий

@dmitvitalii, про регулярки - а давай примеров из рабочего дня! Кажется, я в повседневной работе только точечку со звездочкой использую, и букву i иногда в конце.

  Развернуть 1 комментарий

@ganqqwerty, я примером поделюсь
Работал над системой, построенной поверх API переводчиков от Гугла, Майкрософта и прочих, в ней заказчик (обычно это для саппорта использовалось, где хотелось минимальным количеством людей покрыть максимальное количество языков) мог определять всякие сокращения, которые бы на нашей стороне раскрывались в полноценные фразы, которые бы уходили в переводчик и затем к клиенту (клиенту нашего заказчика).
И была дана возможность заказчикам определять некоторые шаблоны с помощью регулярок. Что в итоге аукнулось в какой-то момент регулярными падениями запросов у нас в серверах, дебагом с попытками разобраться и в итоге выяснением, что заказчик насоздавал шаблонов с такими жадными регулярками, что всё падало по памяти и таймаутам.
Ну, тут не совсем пример ежедневного использования регулярок, сколько важность понимания того, что "и так бывает"

  Развернуть 1 комментарий

@ganqqwerty, преобразование строк в одном формате в другой, в каком-нибудь Splunk делать extract полей

  Развернуть 1 комментарий

@ganqqwerty, специально собрал реальных примеров. Было больше, но либо мелкие совсем, либо похожи на эти.

Обычно для vim. Специфика в том, что количество символов указывается так:
\w\{10}
То есть открывающаяся скобка у "{n}" должна экранироваться символом "\"

Чистим логи

s/^\d* \d*-\d*-\d* \d*:\d*:\d*\.\d*//g
Превратит строки
38406 2021-09-04 14:52:00.742 INFO Start processing <...>
В такие
INFO Start processing <...>

\.\/\w*.log:\d*:\d*-\d*-\d* \d*:\d*:\d*.\d*
Превратит такое (результат grep <..> -nr .)
./super_logfile.log:40462:2021-09-04 14:52:45.399 INFO IR packet Dropped. freq: <...>
Вот в такое
INFO IR packet Dropped. freq: <...>

Правим .dot файл графа

Есть большой файл графа. Настолько большой, что graphviz его не может визуализировать, а в Gephi не удаётся его привести ни к какому виду.
Поэтому его проще читать текстом. Для этого надо убрать лишнее.

%g/0x.*" \[arrowhead=none\]/d
Удалит строки
"0x55580fd483a0" -> "0x55580fd3a4f0" [arrowhead=none]

"0x.\{12}" -> "0x.\{12}"$
Удаляет

"0x55580fd3a4f0" -> "0x55580fc0a860"
"0x55580fd3a4f0" -> "0x55580fd3bcf0"
"0x55580fd3a4f0" -> "0x55580fd3bdd0"

rule\d\{5}
и
label=".\?phony"
Уберут все ненужные лейблы

"0x555816caaa20" [label="rule42507", shape=ellipse]
"0x555816ca6220" -> "0x555816caca20" [label=" rule42509"]

"0x55582a0376e0" [label="phony", shape=ellipse]
"0x55580f57c350" -> "0x55580f587cf0" [label=" phony"]

Ну и под конец зачистим сами адреса
%s/^"0x.\{12}"\s//g
Чтобы почистить

"0x555817b69410" [label="prebuilts/misc/common/robolectric/3.6.1/lib/hamcrest-library-1.3.jar"]
"0x555817b69520" [label="prebuilts/misc/common/robolectric/3.6.1/lib/httpclient-4.0.3.jar"]

И получить

[label="prebuilts/misc/common/robolectric/3.6.1/lib/hamcrest-library-1.3.jar"]
[label="prebuilts/misc/common/robolectric/3.6.1/lib/httpclient-4.0.3.jar"]
  Развернуть 1 комментарий
Dmitry Moskalchuk, Software Developer and Architect 2 июля в 07:22

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

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

......
File "/usr/lib/python3.8/http/client.py", line 1293, in _send_request
    self.putheader(hdr, value)
File "/usr/lib/python3.8/http/client.py", line 1225, in putheader
    values[i] = one_value.encode('latin-1')
UnicodeEncodeError: 'latin-1' codec can't encode character '\u2018' in position 0: ordinal not in range(256)

Выясняю. Оказывается, дело в том, что кастомер так засетапил нужную environment variable:

export VAR=‘123’

Лёгким движением руки на глазах у кастомера ввожу в терминал:

export VAR='123'

И всё работает! Кастомер рвёт на себе волосья и вопрошает: «Что это было?»

  Развернуть 1 комментарий

@crystax, классека. Ненавижу мак за это.

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

  Развернуть 1 комментарий

@LionZXY, Так я и не спорю. Насмотренность, да. Много раз уже набивал шишки, сходу поэтому знаю многое. А со стороны выглядит как магия.

Но что значит «отдельно такое качать очень сложно»? Это и не надо качать, это само приходит со временем. Если, конечно, работать в трезвом уме и твёрдой памяти. VIM тот же, о котором тут уже упомянули. Спрашивают: «у меня не получается в терминале скопировать текст мышкой, если он открыт в vim-е». Отвечаю: «Сделай :set mouse-=a». Работает! Спрашивает: «Как? Я уже десять лет работаю, в том числе в vim-е, а об этом не знал». Ну, так работал, видимо, не очень приходя в сознание.

  Развернуть 1 комментарий

@crystax, лично я бы вместо этого полез в то место, где читаются эти переменные, и поставил бы там валидацию и человекочитаемые сообщения об ошибках, чтобы клиент исправил эти кавычки сам

  Развернуть 1 комментарий

@golergka, Скрипт не мой, править его не могу. Но проблемы кастомера, платящего деньги — это также и мои проблемы, увы и ах. Поэтому часто приходится копаться в говнах, даже если сам бы выкинул такую поделку к чёртовой матери.

  Развернуть 1 комментарий
Igor Toporkov, Erlang разработчик 1 июля в 21:55
  • Писать несложные sql запросы: сджойнить пару таблиц, сгруппировать данные, посчитать агрегат. Часто помогало получить какую-то базовую оценку качетсва полученных данных, прикинуть то, насколько частую проблему беремся исправлять и т д
  • Пользование http и db клиентами. Очень тупо, едва ли реальный навык, но использую постоянно. Их использование позволяет быстро, наглядно и всегда воспроизводимо сделать то, что легко потеряется в консоли
  • Скриптинг на питоне. Нужен редко, но метко. Питон терпеть не могу, но со своей задачей он справляется отлично. В 20-30 строк можно порешать рутинные задачки
  Развернуть 1 комментарий
Alexander Shepelin, Фронтенд-разработчик 5 июля в 15:55

Фронтенд. Не маст-хэв, но полезные навыки:

  1. Минимальное использование curl (получить ответ с кодом и заголовками, засетить хедеры, передать жсон постом). Полезно при общении с бэкендерами ("вижу вот тут 500-ю, вот запрос").

  2. Баш-скриптинг. Тут и возможность написать длинную команду с пайпами (grep ... | sed ... - чтобы что-нибудь из логов достать, например), и какой-нибудь скриптик (запуск проекта одной командой). Всё с гуглом, нет необходимости помнить опции sed или синтаксис if-ов, чтобы уметь писать это сразу из головы, не так часто надо. Принципиально просто знание "вот так можно, ща уточню как это сделать" + https://tldr.sh/

  3. Представление о возможностях CI - что можно запускать тесты и прогонять линтер на пуллреквесты, прикрутить дополнительные штуки типа Danger JS, запускать отдельные джобы только на пуллреквесты, отдельные на мёрдж. Как сделать установку и сборку быстрее, как кэшировать зависимости, чтобы не ставить их каждый раз. Навык не ежедневный и системы везде разные, но можно потренироваться на каком-нибудь github actions, чтобы сформировать представление.

  Развернуть 1 комментарий
Victor Login, fullstack (ui->back->ops) 1 июля в 22:37
  • Git (GitFlow) - нужен не зависимо от стека, платформы. В перспективе поможет и в дебаге и в организации работы сольно/команды. И темы блокчейн/event-source/бекапов станут понятней
  • MVP (User Story) - не делать сразу на года; меньше кода, больше профита; ориентироваться на результат; 5 вопросов почему, а зачем, а может не нужно ;-)
  • блоксхемы (UML/что-то свое не важно) - видеть картину в общем; сперва понять в общем виде что нужно, что не нужно (смотри пункт выше про MVP); с чего начать, и как это вообще должно работать; Бонусом хоть какой то старт для документации

P.S. Еще бы вынес отдельно - независимость - на каком то уровне делать вещи за пределами своего стека

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

Остальное во время работы как-то само приходит

  Развернуть 1 комментарий
Alexey Surikov, Компьютерщик 5 июля в 14:59

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

  1. Уметь прыгать между уровнями абстракций.

Мне чаще прихоидтся спускаться на более низкие уровни: запустить strace/perf для высокоуровневой программы, заглянуть в кишки компилятора/интепретатора и т.д.
Иногда надо и наоборот. Если после условного часа изучения логов или смотрения в дебаггер все равно ничего не понятно, полезно будет отступить назад и попробовать нарисовать диаграммку, проследить путь запроса/данных через весь стек и т.п.
Мне кажется, что у меня этот навык развит неплохо, но предел есть всегда. В какой–то момент я спущусь/поднимусь туда, где разобраться будет долго и/или сложно. В такие моменты я ищу людей, которые разбираются лучше меня.

Примеров из жизни слишком много чтобы выбрать что–то конкретное.

  1. Знать инструменты для отладки.

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

Пример из жизни: недавно нужно было отладить проблему с валидацией TLS сертификатов. Библиотека TLS выдает какую–то невнятную ошибку. Из логов ничего не ясно, даже непонятно, сервер несогласен с клиентом или наоборот. Зарядил openssl s_client, почитал вывод, стало понятнее. Отыскал нужное место среди тысяч строк в TLS библиотеке, добавил логов. Бум, готово.

  Развернуть 1 комментарий
Дима Табакеров, художник-программист 5 июля в 22:07
  1. Понимание, что в компьютерах нет магии, и если что-то происходит, значит на то есть причина (да, порой причина крайне неочевидна, дурацкая или даже уровня "космический луч флипнул бит" - но причина есть).
  2. ...а остальное как-то получается производным из п.1
  Развернуть 1 комментарий

Но такие вещи зависят от конкретного стека же. Я не думаю, что те, кто пишут на плюсах, например, пишут постоянно тесты. А пхпшникам нечасто нужно погружаться в дебри оптимизации с помощью битовых операций ) В шапке точно релевантный вопрос? Получится ли так собрать статистику, какие навыки являются более практическими?

  Развернуть 1 комментарий

@Cls, можно и указать свой стек

  Развернуть 1 комментарий

Добавил в шапку

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб