Судя по тому, как многим не в то горло попал мой комментарий, складывается, а точнее подтверждается, впечатление, что у программистов в принципе нет и не может быть авторитетов. Т.е это и есть проявление обратной стороны одной из тех трех добродетелей, о которых говорил Ларр Уолл.
Для меня ориентироваться на лучших - норма. Поэтому я всегда стараюсь искать среди хороших лучших, а среди лучших самых лучших.
Интересно, что когда лучших из лучших ищет работодатель, и для этого заставляет писать код на бумажке, или делать еще какую нибудь гиманстику, потому что не в состоянии по разговору определить профессиональный уровень собеседника - то это тупо, но ладно.
Предлагаю всем на следующем техническом собеседовании сказать:
- Знаете, уважаемый, судя по заданию у Вас есть желание поделить людей на две категории. - Эмм-м...ну-у-у... э-э-э.., как бы да. Одни будут у нас работать а другие нет!
Начинающие художники и музыканты зачастую берут пример с работ мастеров, музыканты, поэты и писатели берут пример с работ мастеров. А с кого берут примеры программисты? Вам удастся назвать имена тех, с кого Вы брали пример в своем профессиональном становлении? Любопытно, что сделать это не так то и просто. Интересно, почему? (Тут не надо путать "учился у" и "брал пример с". Все учились у Дядюшки Боба, Дональда Кнута или Джефа Сазерленда, но с них никто не берет пример)
P.S.: Как мало люди склонны к рефлексии, а ведь это интересно, понять, что делает нас такими какие мы есть.
P.P.S: И да я понимаю, чем задел мой комментарий людей и прошу прощения за неудачную формулировку. Но по смыслу все еще считаю, что в разработке есть задачи требующие высшей, а может и наивысшей квалификации, а есть работа таковой не требующая. Квалификация определяется по большей части объемом понимания системы, и навыками пригодными для решения задач.
Это способ платформонезависимо определять стили элементов? А потом из этих определений типа генерировать платформозависимый код, если для вебстраницы то css/sass, если android - то style resource file (xml) и т.п?
Я тоже ушел со своего первого проекта где я поддерживал автоматизацию для 5 разделов системы и 40-а человек команды. 5 разделов это пять совершенно разных контекстов приложения, где нужно соответственно понимать бизнес-логику, а для этого общаться со всеми командами. В общей сложности около 350 тестовых сценариев помноженых на 8 основных вариантов продукта выполялось каждый день . Сборка и выполнение тестирования проводились у другого подрядчика. Команды только код сдавали. Кастомный скриптовый инструмент тестирования, со своими "прибамбасами". Особенности интеграции тоже свои. Чтобы понять куда и когда сдавать, дабы твой код попал в нужный вариант продукта иногда даже опытным разработчикам приходилось чесать тыковку. Ну и стандартный набор задач: отчетность, планирование, наращивание покрытия. Порой автоматизация тестирования превращалась в "драматизацию тестирования". Это я таким каламбуром называю синдром, когда заказчику периодически резко стукает жидкость в голову, что нужно лучше, больше, быстрее автоматизировать, и вообще-то еще вчера. Вот зарисовка из жизни:
Приходит ко мне руководитель и спрашивает:
- Заказчик мол хочет знать сколько нужно времени, чтобы все состояния покрыть тестами. - Ну это смотря сколько багов будет в системе, у нас постоянно идет разработка, всплывают новые баги, на их документацию и трекинг уходит наибольшая часть времени. - Ну предположим система будет готова и не будет больше меняться. - Если система не будет меняться то и автоматизация не нужна. - ... Вопрос был закрыт.
А проработал я на нем не много ни мало почти 7 лет. Просто в какой-то момент понял, что с моим опытом могу продолжать жонглировать своими задачами с закрытыми глазами и дальше. И это лестно быть единственным экспертом в узкой области. Но это не то, как это должно быть организовано. Не может автоматизация держаться на одном человеке. Да это выгодно работодателю. Но совершенно неправильно. Никто больше не знает как это все поддерживать, никто не знает как это работает, и чем вообще я занимаюсь. И соответственно, это карьерный тупик. Зарплату добавлять не станут, твои задачи ведь не меняются. И вобщем я понял что я обязан уйти, чтобы проект начал относиться к автоматизации правильно. Передал знания командам и ушел. Ушел, так сказать, во благо проекту и себе. Расставание в стиле: "Нам от этого обоим будет лучше".
P.S.:
Люблю вспоминать цитату Джима из нетленной философской мульт-эпопеи о Губке Бобе:
"Парень неплохой повар, но великолепным поваром он станет лишь тогда, когда наберется мужества, чтобы уволиться из этой дыры." - вторая серия, пятый сезон (текстовая транскрипция оригинала)
Есть цитата Вольфа Шнайдера, ставшая в Германии уже пословицей: "Одному из них придется мучиться. Либо читателю, либо автору." И хотя эти слова изначально подразумевали произведения литературы, это фразу часто цитируют в среде айтишников на докладах по чистому коду и т.п.
Там в статье есть кат с описанием первых трех вариантов
Я прочитал этот отрывок но не заострил на нем внимания потому что не увидел взаимосвязи в прогрессии. (Кстати там материал по ссылке на srns закрыт для посторонних) Больше похоже на эксперименты без наличия четкого видения цели. А потом прям принципиальный скачок получился. А теперь я понимаю как это произошло. Это вы с правильными людми поговорили, и они вас "на нужную частоту настроили" :)
Еще такой вопрос, если можно: система подразумевает возможность полностью удаленной работы. Что вы делаете если прошивка запарывает устройство, есть какой-то способ экстренного восстановления работоспособности устройства, без личного присутствия? Или архитектурно сделано так, что прошивкой нельзя запороть устройство до такой степени, чтобы оно перестало принимать прошивки? И вы тогда, например, просто откатываете на базовый образ.
Класс! Больше ничего сказать не могу. Очень все изящно и красиво сделано.
Вы все десять лет шли к этому решению или сколько времени вы работали именно над этим вариантом? Немножко историю эволюции тестирования в этом проекте можете рассказать?
P.S. A и еще, это я так понимаю гос. учереждение. А финансируется проект частниками или из бюджета? Я к чему веду. Просто в коммерческой среде на создание нормальных решений как правило нет времени, нет времени чтобы спокойно все обдумать а потом спокойно все реализовать. В коммерческом секторе нередко все начинается с того что хотят быстро накидать тестовое покрытие, и только потом понимают, что тесты есть - толку нет.
«народная любовь» держится только на безлимитной халяве
Это Ваше видение. Я такого не утверждал ни одним словом.
Любовь произрастает из человеческого, демократичного, отношения к пользователю.
А что касается бизнес-моделей с "бесплатным" продуктом - таких масса. Как правило садят пользователя на свой продукт. Так например делает Майкрософт: Visual Code, NPM, GitHub - всем тепло и уютно. Но потихоньку через GitHub продвигаются облачные сервисы корпорации. Плохо это? Нет. Главное при выстраивании мегаполиса вокруг тех трущоб с которых это все начиналось - не сносить трущобы. А так делают некоторые. Типа: "так все мы теперь закрываем лавочку, теперь все платное". На мой взгляд это довольно ограниченая и недальновидная модель.
Поэтому ТГ делает комплементарную модель. Что само по себе не плохо и не хорошо. Вопрос в балансе, будут при этом душить работяг - получат тонны говна на вентилятор. Будут строить тихонько рядом платный набор функций - никто не против. Обычно с такого развития и простым пользователям перепадает. Плохо когда на разработку коммерческого направления начинают оттягиваться ресурсы и общедоступная ветка начинает страдать, например задерживаются нужные багфиксы ради новых иконок для платных подписчиков. Такое народ не приветствует как правило. Но, вопрос баланса, как я и сказал.
Но в таком случае, они под оберткой просьбы о финансовой поддержке от сообщества, назовем это так, скрывают банальную ничем не прикрытую монетизацию. Но они же должны понимать, что телега держится не столько за счет алгоритмов шифрования, сколько за счет всенародной любви, а разбазарить эту всенародную любовь можно в два счета.
Нехило. Про поиск названия фильма по описанию полезный юзкейс. Осталось еще научиться распознавать песни по текстовым напевам. - Что это за песня: "тум-турум-тум-тум-турум, эцы-бэцы, шау-ва-а-а, умц"? - Такой песни не существует, но я могу создать похожую песню. Создать?
Написать под бекенд типа LLVM или QBE (который собственно и будет в конце концов выполять перевод в машинный код) действительно не самая сложная задача. Я ведь не имею ввиду, я имею ввиду все полностью, с нуля, без ничего, вот у тебя язык программирования на операционке, и пиши на нем. А после компиляции, компилированый исполняемый код должен работать под этой операционной системой. Там уже не все так просто.
Если бы это были "stretch goals" на кикстартере я уверен люди бы накинули сверху чеканных монет. Но на бизнес-функции этот набор как-то не тянет. Больше похоже, что прикинули что можно сравнительно легко прикрутить, чтобы создать UVP (unique value proposition). Но UVP получилось вцелом хоть и "прикольным", но не очень внятным.
А позиционируется оно по факту скорее как возможность пользователя поддержать разработку. Но тогда надо было и называть это не "премиум", от которого у всех сразу возникают противные ассоциации, а например Telegram Supporter Pack.
T.e. если ты обращаешься к "работягам" то и говори на их языке. Такие "наборы плюшек для энтузиастов" давным давно уже существуют везде. И все сразу бы правильно сориентировались. А так получилось, что маркетинг сбил людей с толку.
Я где-то читал в комментарии на Quora что операционки, виртуальные машины, компиляторы и игровые движки считаются сложными в разработке системами. И я чисто интуитивно согласен с таким мнением, хотя сам не пробовал писать ничего из вышеперечисленного.
А как на Ваш взгляд? Какие программные системы самые сложные в разработке? Уклончивый ответ типа "Те к которым плохо прописаны требования" не принимается :)
Вообще интересно если так по интернету шарить, то впечатление, что профессии как системный программист нету вовсе, что макоси, виндоусы и линуксы растут сами по себе, и размножаются почкованием, а новые компьютеры попадают к нам из торговой площадки. Где весь айтишный хардкор тусуется?
Мне на работе однажды попался человек он работал когда-то в антивирусе доктора веба. Вот он мог тебе про винду рассказать всё. Т.е. по сегодняшним меркам таких людей бы причислили к специалистам. Высококвалифицированный разработчик узкой направленности. Но это как-то оскорбительно сказать, что такой спец - узкой направленности. Ведь он справится с любой программистской задачей, просто в его области он обладает преимуществом опыта.
А, ну вот, я сам тоже пришел к этому определению. Это экспертность. Он эксперт в своей области. И да если ему дать программировать фронтенд, он скорее всего довольно быстро полезет в дебри смотреть как там node.js плохо устроена внутри. А это совсем не нужно заказчику. Т.е получается уровень экспертности это не то, что обязательно нужно повышать. Для некоторых видов задач, она может оставаться низкой.
Но тогда мне не совсем понятно как можно, например, за восемь лет не повысить свой уровень экспертности? Вот коллега мой с бывшего проекта: работа и система одна и та же, он сетует на то ему не дают курсы повышения квалификации до архитектора, Но при этом получается, если бы он хотел быть архитектором он бы им стал у себя в команде. Значит ему каких-то софт-скиллов не хватает? Так-то он весьма умен, аккуратен и работящ, а вырваться из колеи не может. И это не единичный случай. Были еще такие работники без амбиций. ЗП вовремя приходит и нормально. Я за это время успел три команды поменять и зарплату почти утроить. Мне жалко времени сидеть и делать линейные задачи. Мне с них опыт не капает. Время утекает слишком быстро, я это чувствую. Поэтому суечусь как-то, хочется сделать больше, использовать свой ресурс эффективнее. Помочь еще одному проекту настроить автоматизацию, чем написать тридцать новых тестов в существующей системе. А вот на одном проекте со мной работал молодой специалист, он сказал что ему нравится "не пыльно" клепать тестики по шаблону. И остался клепать тестики дальше. Видимо от человека зависит.
Не обьяснить как работает, а написать. И не интерпретатор, а компилятор. Он должен ведь не только прочитать и распарсить, а самое главное что, перевести инструкции в машинный код который бы соответствовал бинарному протоколу операционной системы. Т.е. нужны знания из нескольких дисциплин информатики, чтобы охватить эту задачу с начала и до конца. А до уровня операционной системы большинству программистов сегодня вообще не приходится опускаться. Многие программисты на Javа могут даже не знать как работает JVM, которая выполняет их код.
Я думаю если распределить всех айтишников по глубине знаний то получится вафельный рожок, перевернутая пирамида, где 80% болтаются где-то в верхнем слое системных абстракций. Т.е. на уровне языка программирования и никогда не спускались ниже. И это нормально. Я на каком-то довольно свежем докладе слышал, что по оценкам специалистов для того чтобы угнаться за будущими потребностями индустрии (в частности в автомобильном секторе) нужно ускорить темп разработки ПО в три раза. В три. Поэтому прикладных програмистов должно быть сравнительно много. Этот тот слой который первым принимает на себя удар. И только если им не удается впитать задачи приходят системные интеграторы, а за ними системные программисты и развивают системы под новые потребности индустрии. Вот например потребности криптомайнинга пробили всю пирамиду насквозь аж до железа.
Нет, не осилю. Я уже ответил в другом комментарии что для меня это потолок практического осмысления. Но я и не пытался, так в общих чертах, "чего-то там абстрактное синтаксическое дерево" помню и все. Хотя те кто это делал говорят, что это не самая сложная задача.
Я и рекурсию написать не смогу сходу. И вообще я себя программистом не считаю. Так, скриптики односложные пишу.
Ну и вопрос — литературой можно пользоваться или
Ну так в этом и дело. По учебнику любой напишет. Если ты понимаешь задачу и способ ее решения сам разворачивается у тебя в голове, то тебе не понадобится учебник. И никакого ограничения по времени нет, это только на собеседованиях нужно.
Если можно, то напишут процентов 95. Если нет, то наверное теже 95, но уже получится говнокомпилятор.
Странно оценивать успех даже не спросив о технических требованиях к задаче. Я думаю что процент сильно ниже, если брать срез всего народа в IT.
Судя по тому, как многим не в то горло попал мой комментарий, складывается, а точнее подтверждается, впечатление, что у программистов в принципе нет и не может быть авторитетов. Т.е это и есть проявление обратной стороны одной из тех трех добродетелей, о которых говорил Ларр Уолл.
Для меня ориентироваться на лучших - норма. Поэтому я всегда стараюсь искать среди хороших лучших, а среди лучших самых лучших.
Интересно, что когда лучших из лучших ищет работодатель, и для этого заставляет писать код на бумажке, или делать еще какую нибудь гиманстику, потому что не в состоянии по разговору определить профессиональный уровень собеседника - то это тупо, но ладно.
Предлагаю всем на следующем техническом собеседовании сказать:
Начинающие художники и музыканты зачастую берут пример с работ мастеров, музыканты, поэты и писатели берут пример с работ мастеров. А с кого берут примеры программисты? Вам удастся назвать имена тех, с кого Вы брали пример в своем профессиональном становлении? Любопытно, что сделать это не так то и просто. Интересно, почему?
(Тут не надо путать "учился у" и "брал пример с". Все учились у Дядюшки Боба, Дональда Кнута или Джефа Сазерленда, но с них никто не берет пример)
P.S.: Как мало люди склонны к рефлексии, а ведь это интересно, понять, что делает нас такими какие мы есть.
P.P.S: И да я понимаю, чем задел мой комментарий людей и прошу прощения за неудачную формулировку. Но по смыслу все еще считаю, что в разработке есть задачи требующие высшей, а может и наивысшей квалификации, а есть работа таковой не требующая. Квалификация определяется по большей части объемом понимания системы, и навыками пригодными для решения задач.
Это способ платформонезависимо определять стили элементов? А потом из этих определений типа генерировать платформозависимый код, если для вебстраницы то css/sass, если android - то style resource file (xml) и т.п?
Как говорил один мой знакомый:
- Много счастья и тазик!
- А тазик зачем?
- Чтобы счастье туда складывать.
Я тоже ушел со своего первого проекта где я поддерживал автоматизацию для 5 разделов системы и 40-а человек команды. 5 разделов это пять совершенно разных контекстов приложения, где нужно соответственно понимать бизнес-логику, а для этого общаться со всеми командами. В общей сложности около 350 тестовых сценариев помноженых на 8 основных вариантов продукта выполялось каждый день . Сборка и выполнение тестирования проводились у другого подрядчика. Команды только код сдавали. Кастомный скриптовый инструмент тестирования, со своими "прибамбасами". Особенности интеграции тоже свои. Чтобы понять куда и когда сдавать, дабы твой код попал в нужный вариант продукта иногда даже опытным разработчикам приходилось чесать тыковку. Ну и стандартный набор задач: отчетность, планирование, наращивание покрытия. Порой автоматизация тестирования превращалась в "драматизацию тестирования". Это я таким каламбуром называю синдром, когда заказчику периодически резко стукает жидкость в голову, что нужно лучше, больше, быстрее автоматизировать, и вообще-то еще вчера. Вот зарисовка из жизни:
А проработал я на нем не много ни мало почти 7 лет. Просто в какой-то момент понял, что с моим опытом могу продолжать жонглировать своими задачами с закрытыми глазами и дальше. И это лестно быть единственным экспертом в узкой области. Но это не то, как это должно быть организовано. Не может автоматизация держаться на одном человеке. Да это выгодно работодателю. Но совершенно неправильно. Никто больше не знает как это все поддерживать, никто не знает как это работает, и чем вообще я занимаюсь. И соответственно, это карьерный тупик. Зарплату добавлять не станут, твои задачи ведь не меняются. И вобщем я понял что я обязан уйти, чтобы проект начал относиться к автоматизации правильно. Передал знания командам и ушел. Ушел, так сказать, во благо проекту и себе. Расставание в стиле: "Нам от этого обоим будет лучше".
P.S.:
Люблю вспоминать цитату Джима из нетленной философской мульт-эпопеи о Губке Бобе:
Есть цитата Вольфа Шнайдера, ставшая в Германии уже пословицей: "Одному из них придется мучиться. Либо читателю, либо автору." И хотя эти слова изначально подразумевали произведения литературы, это фразу часто цитируют в среде айтишников на докладах по чистому коду и т.п.
Я прочитал этот отрывок но не заострил на нем внимания потому что не увидел взаимосвязи в прогрессии. (Кстати там материал по ссылке на srns закрыт для посторонних) Больше похоже на эксперименты без наличия четкого видения цели. А потом прям принципиальный скачок получился. А теперь я понимаю как это произошло. Это вы с правильными людми поговорили, и они вас "на нужную частоту настроили" :)
Еще такой вопрос, если можно: система подразумевает возможность полностью удаленной работы. Что вы делаете если прошивка запарывает устройство, есть какой-то способ экстренного восстановления работоспособности устройства, без личного присутствия? Или архитектурно сделано так, что прошивкой нельзя запороть устройство до такой степени, чтобы оно перестало принимать прошивки? И вы тогда, например, просто откатываете на базовый образ.
Класс! Больше ничего сказать не могу. Очень все изящно и красиво сделано.
Вы все десять лет шли к этому решению или сколько времени вы работали именно над этим вариантом? Немножко историю эволюции тестирования в этом проекте можете рассказать?
P.S. A и еще, это я так понимаю гос. учереждение. А финансируется проект частниками или из бюджета? Я к чему веду. Просто в коммерческой среде на создание нормальных решений как правило нет времени, нет времени чтобы спокойно все обдумать а потом спокойно все реализовать. В коммерческом секторе нередко все начинается с того что хотят быстро накидать тестовое покрытие, и только потом понимают, что тесты есть - толку нет.
Я сперва подумал, что фанерозой это шуточное название потому что жизнь пролетает мимо нас как фанера над Парижем :)
Это Ваше видение. Я такого не утверждал ни одним словом.
Любовь произрастает из человеческого, демократичного, отношения к пользователю.
А что касается бизнес-моделей с "бесплатным" продуктом - таких масса. Как правило садят пользователя на свой продукт. Так например делает Майкрософт: Visual Code, NPM, GitHub - всем тепло и уютно. Но потихоньку через GitHub продвигаются облачные сервисы корпорации. Плохо это? Нет. Главное при выстраивании мегаполиса вокруг тех трущоб с которых это все начиналось - не сносить трущобы. А так делают некоторые. Типа: "так все мы теперь закрываем лавочку, теперь все платное". На мой взгляд это довольно ограниченая и недальновидная модель.
Поэтому ТГ делает комплементарную модель. Что само по себе не плохо и не хорошо. Вопрос в балансе, будут при этом душить работяг - получат тонны говна на вентилятор. Будут строить тихонько рядом платный набор функций - никто не против. Обычно с такого развития и простым пользователям перепадает. Плохо когда на разработку коммерческого направления начинают оттягиваться ресурсы и общедоступная ветка начинает страдать, например задерживаются нужные багфиксы ради новых иконок для платных подписчиков. Такое народ не приветствует как правило. Но, вопрос баланса, как я и сказал.
Но в таком случае, они под оберткой просьбы о финансовой поддержке от сообщества, назовем это так, скрывают банальную ничем не прикрытую монетизацию. Но они же должны понимать, что телега держится не столько за счет алгоритмов шифрования, сколько за счет всенародной любви, а разбазарить эту всенародную любовь можно в два счета.
А что за и на чем написана была система в которую понадобился DSL?
P.S.:Глянул ваши проекты - круть.
Нехило. Про поиск названия фильма по описанию полезный юзкейс. Осталось еще научиться распознавать песни по текстовым напевам.
- Что это за песня: "тум-турум-тум-тум-турум, эцы-бэцы, шау-ва-а-а, умц"?
- Такой песни не существует, но я могу создать похожую песню. Создать?
Написать под бекенд типа LLVM или QBE (который собственно и будет в конце концов выполять перевод в машинный код) действительно не самая сложная задача. Я ведь не имею ввиду, я имею ввиду все полностью, с нуля, без ничего, вот у тебя язык программирования на операционке, и пиши на нем. А после компиляции, компилированый исполняемый код должен работать под этой операционной системой. Там уже не все так просто.
Если бы это были "stretch goals" на кикстартере я уверен люди бы накинули сверху чеканных монет. Но на бизнес-функции этот набор как-то не тянет. Больше похоже, что прикинули что можно сравнительно легко прикрутить, чтобы создать UVP (unique value proposition). Но UVP получилось вцелом хоть и "прикольным", но не очень внятным.
А позиционируется оно по факту скорее как возможность пользователя поддержать разработку. Но тогда надо было и называть это не "премиум", от которого у всех сразу возникают противные ассоциации, а например Telegram Supporter Pack.
T.e. если ты обращаешься к "работягам" то и говори на их языке. Такие "наборы плюшек для энтузиастов" давным давно уже существуют везде. И все сразу бы правильно сориентировались. А так получилось, что маркетинг сбил людей с толку.
То чем человек занимается для заработка не имеет значения. Может хоть рыбой на рынке торговать.
Я где-то читал в комментарии на Quora что операционки, виртуальные машины, компиляторы и игровые движки считаются сложными в разработке системами. И я чисто интуитивно согласен с таким мнением, хотя сам не пробовал писать ничего из вышеперечисленного.
А как на Ваш взгляд? Какие программные системы самые сложные в разработке? Уклончивый ответ типа "Те к которым плохо прописаны требования" не принимается :)
Вообще интересно если так по интернету шарить, то впечатление, что профессии как системный программист нету вовсе, что макоси, виндоусы и линуксы растут сами по себе, и размножаются почкованием, а новые компьютеры попадают к нам из торговой площадки. Где весь айтишный хардкор тусуется?
Мне на работе однажды попался человек он работал когда-то в антивирусе доктора веба. Вот он мог тебе про винду рассказать всё.
Т.е. по сегодняшним меркам таких людей бы причислили к специалистам. Высококвалифицированный разработчик узкой направленности. Но это как-то оскорбительно сказать, что такой спец - узкой направленности. Ведь он справится с любой программистской задачей, просто в его области он обладает преимуществом опыта.
А, ну вот, я сам тоже пришел к этому определению. Это экспертность. Он эксперт в своей области. И да если ему дать программировать фронтенд, он скорее всего довольно быстро полезет в дебри смотреть как там node.js плохо устроена внутри. А это совсем не нужно заказчику. Т.е получается уровень экспертности это не то, что обязательно нужно повышать. Для некоторых видов задач, она может оставаться низкой.
Но тогда мне не совсем понятно как можно, например, за восемь лет не повысить свой уровень экспертности? Вот коллега мой с бывшего проекта: работа и система одна и та же, он сетует на то ему не дают курсы повышения квалификации до архитектора, Но при этом получается, если бы он хотел быть архитектором он бы им стал у себя в команде. Значит ему каких-то софт-скиллов не хватает? Так-то он весьма умен, аккуратен и работящ, а вырваться из колеи не может. И это не единичный случай. Были еще такие работники без амбиций. ЗП вовремя приходит и нормально. Я за это время успел три команды поменять и зарплату почти утроить. Мне жалко времени сидеть и делать линейные задачи. Мне с них опыт не капает. Время утекает слишком быстро, я это чувствую. Поэтому суечусь как-то, хочется сделать больше, использовать свой ресурс эффективнее. Помочь еще одному проекту настроить автоматизацию, чем написать тридцать новых тестов в существующей системе. А вот на одном проекте со мной работал молодой специалист, он сказал что ему нравится "не пыльно" клепать тестики по шаблону. И остался клепать тестики дальше. Видимо от человека зависит.
Не обьяснить как работает, а написать. И не интерпретатор, а компилятор. Он должен ведь не только прочитать и распарсить, а самое главное что, перевести инструкции в машинный код который бы соответствовал бинарному протоколу операционной системы. Т.е. нужны знания из нескольких дисциплин информатики, чтобы охватить эту задачу с начала и до конца. А до уровня операционной системы большинству программистов сегодня вообще не приходится опускаться. Многие программисты на Javа могут даже не знать как работает JVM, которая выполняет их код.
Я думаю если распределить всех айтишников по глубине знаний то получится вафельный рожок, перевернутая пирамида, где 80% болтаются где-то в верхнем слое системных абстракций. Т.е. на уровне языка программирования и никогда не спускались ниже. И это нормально. Я на каком-то довольно свежем докладе слышал, что по оценкам специалистов для того чтобы угнаться за будущими потребностями индустрии (в частности в автомобильном секторе) нужно ускорить темп разработки ПО в три раза. В три. Поэтому прикладных програмистов должно быть сравнительно много. Этот тот слой который первым принимает на себя удар. И только если им не удается впитать задачи приходят системные интеграторы, а за ними системные программисты и развивают системы под новые потребности индустрии. Вот например потребности криптомайнинга пробили всю пирамиду насквозь аж до железа.
Спасибо за отсылку! Мне эта книга еще не попадалась.
Нет, не осилю. Я уже ответил в другом комментарии что для меня это потолок практического осмысления. Но я и не пытался, так в общих чертах, "чего-то там абстрактное синтаксическое дерево" помню и все. Хотя те кто это делал говорят, что это не самая сложная задача.
Я и рекурсию написать не смогу сходу. И вообще я себя программистом не считаю. Так, скриптики односложные пишу.
Ну так в этом и дело. По учебнику любой напишет. Если ты понимаешь задачу и способ ее решения сам разворачивается у тебя в голове, то тебе не понадобится учебник. И никакого ограничения по времени нет, это только на собеседованиях нужно.
Странно оценивать успех даже не спросив о технических требованиях к задаче. Я думаю что процент сильно ниже, если брать срез всего народа в IT.