Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Писать код уже не достаточно: обязанности современных back-end разработчиков

[Об авторе: Дмитрий Соколов — Independent Java Trainer и Ментор, имеет более семи лет опыта написания Java приложений как Java Tech Lead и full-stack разработчик. Регулярно проводит тренинги и мастер-классы, делится знаниями о том, как писать и поддерживать развивающиеся проекты]

Мне радостно на сердце от того, что все больше молодежи идет работать в IT. Ребята начинают читать профильные сайты. Эта статья посвящается тем, кто сейчас на пути становления разработчиком ПО, а именно — серверной части (back-end).

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

Так действительно было 10-15 лет назад. Сегодня программистов как таковых почти нет, этот термин уже неуместен. Для обозначения этой профессии больше подойдут определения «разработчик» или «инженер».

Почему так? Ответ ниже.

Обязанности современного разработчика

Давайте рассмотрим типичный день разработчика на Java. Его работа сводится к таким задачам:
— Зайти на удаленный сервер через консоль и настроить одну из компонент, подправить скрипт, сконфигуровровать один из вспомогательных сервисов.
— Проверить почту, систему ведения проектов; общаться с коллегами на предмет наличия задач, которые необходимо сейчас решить.
— Почитать инструкцию к недавно введённому фреймворку, разобраться и выполнить с его помощью одну из задач.
— Исправить ошибку, недавно найденную тестировщиками.
— Ответить на серию писем или сообщений в переписке с заказчиком. Разумеется, на английском. При необходимости созвониться и обговорить вопросы устно.
— Обсудить с коллегами дальнейшие планы на проекте, проблемы и идеи. Помимо запланированных встреч это может происходить во время обеда или в небольшом перерыве, когда вы все свободны.
— Пообщаться с новичками, которые еще вникают в проект (если вы — ведущий разработчик). Оказать свою помощь, если требуется.
— Общаться с другими командами, если над проектом работает больше одной команды. Время от времени может возникать необходимость обсудить вопросы, например, с front-end разработчиками или «ораклистами», инженерами баз данных. Возможно, понадобиться обращаться к ним за советом.
— Следить за состоянием серверов: контроля версий, непрерывной интеграции, базой данных, тестового, рабочего и боевого серверов. Это минимум, а возможно, их будет намного больше, это зависит от сложности проекта.
— Посидеть самому или в паре и подумать над архитектурой системы или какой-то одной компонентой.

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

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

Программист VS Инженер

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

Итого программист — это тот, кто только пишет код.

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

Именно это особенно тщательно проверяют при собеседовании на позицию Senior и выше (Technical и Team Lead, Архитектор).

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

Конструировать, а не программировать

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

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

То же самое происходит и с программированием. Виток развития, через который мы проходим сейчас, дошел до уровня, когда чистый «нативный» код уже почти не используется. Написано огромное количество готовых решений (фреймворков) почти для любой задачи. Используя их, ты собираешь конструктор. Не пишешь код с нуля, а соединяешь части между собой через простое конфигурирование.

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

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

Как держать руку на пульсе

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

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

И тот, кто не успевает, — либо остаётся на месте и не развивается, либо вообще выпадает из обоймы.

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Лише додам, що для тих, хто хоче пробувати все по-троху варто йти в маленькі компанії. Там приходиться багато різних функцій виконувати.

Якщо ж більше кайфу від заглиблення в одну технологію, тоді у великі проекти і компанії. Там більше шансів отримати якісну вузьку спеціалізацію.

«Лучше знать одно ремесло хорошо, чем сто-плохо.» (китайская пословица)

То, что вы описали не является нормой, это проявлении экономии в аутсорсе стран 3-го мира. Теперь это пытаются преподнести как норму. Да, мы именно так работаем и пишем код аж 1-2% времени. Но за счет того, что кто-то решил сэкономить на automation qa, ba, dev-ops и нормальной команде front-end-а, scrum-master-е, а также иногда на услугах дизайнера. Не будем забывать, что senior/лид должен еще менеджить людей, что само по себе очень нехилый скилл.

Давайте спросим чистых UI-девелоперов, а смогут ли они полезть в мой бэкэнд, продебажить и пофиксить что-то даже простое? В ответ скорее всего будет палец у виска: «нафиг мне сдалась твоя Java ?, у меня с JS работы хватает». И он будет прав. Тем не менее от бэкэнд разработчика это ожидается аж бегом — разобраться в сложном JS, SPA и еще черти-чем.

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

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

94 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

«Лучше знать одно ремесло хорошо, чем сто-плохо.» (китайская пословица)

То, что вы описали не является нормой, это проявлении экономии в аутсорсе стран 3-го мира. Теперь это пытаются преподнести как норму. Да, мы именно так работаем и пишем код аж 1-2% времени. Но за счет того, что кто-то решил сэкономить на automation qa, ba, dev-ops и нормальной команде front-end-а, scrum-master-е, а также иногда на услугах дизайнера. Не будем забывать, что senior/лид должен еще менеджить людей, что само по себе очень нехилый скилл.

Давайте спросим чистых UI-девелоперов, а смогут ли они полезть в мой бэкэнд, продебажить и пофиксить что-то даже простое? В ответ скорее всего будет палец у виска: «нафиг мне сдалась твоя Java ?, у меня с JS работы хватает». И он будет прав. Тем не менее от бэкэнд разработчика это ожидается аж бегом — разобраться в сложном JS, SPA и еще черти-чем.

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

Все верно, поэтому надо называть вещь своими именами: «нам нужны дорогие бракоделы-ассенизаторы», а не «индустрия пошла по такому пути....(статья)»

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

Просто некоторые говнофирмы экономят на всем, в том числе и на проджектах и в итоге придумали новую фишку чтобы разработчик общался с клиентами и сам обсуждал с ними задачи... Они это преподносят как возможность лучше вникнуть в задачу без «испорченного телефона» но на самом деле обычное жлобство кампаний... Проджект на то и нужен чтобы понять тот бред который в 90% несет заказчик и истолковать его прогеру в нормальном виде а если этот бред будет на прямую и без фильтрации через проджекта идти к разработчику то и результат будет соответствующий... Больше всего смешат фирмы которые в своих достоинствах пишут «возможность общаться с клиентом» (facepalm) ... Сразу идут нахер.
Но с другой стороны — это позволяет отличить фирму с налаженными бизнес процессами от очередного IT-притона.

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

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

Примерно лет 10 назад, Джоєль Спольски писал подобные опусы. 2+2 действительно 4.

Так действительно было 10-15 лет назад. Сегодня программистов как таковых почти нет, этот термин уже неуместен. Для обозначения этой профессии больше подойдут определения “разработчик” или “инженер”.

Ще рік подібних міркувань і автор (безперечно розумна людина, якщо сама дійшла до подібних висновків) придумає велосипед, тобто методологію розробки, яка вже років 5 називається DevOps.

На всякий випадок нагадаю, що DevOps це не типу сисадмін, який налаштовує CI, automated deployment і логи з блекджеком, а саме методологія розробки.

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

Ще рік подібних міркувань і автор (безперечно розумна людина, якщо сама дійшла до подібних висновків) придумає велосипед, тобто методологію розробки, яка вже років 5 називається DevOps
Могу предположить вы прочитали статью по диагонали. Даже уверен в этом.
Под инженером подразумевалось в первую очередь умение владение фреймворками:
Виток развития, через который мы проходим сейчас, дошел до уровня, когда чистый “нативный” код уже почти не используется. Написано огромное количество готовых решений (фреймворков) почти для любой задачи. Используя их, ты собираешь конструктор. Не пишешь код с нуля, а соединяешь части между собой через простое конфигурирование.

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

Ну и напоследок, в моем окружении DevOp, почему-то как секс у подростков. Вы меня поняли.
Да и чо то я не припомню что бы хотя бы в одной компании была такая вакансия даже. Я про реалии украинского аутсорса.

Да и чо то я не припомню что бы хотя бы в одной компании была такая вакансия даже.
На всякий випадок нагадаю, що DevOps це не типу сисадмін, який налаштовує CI, automated deployment і логи з блекджеком, а саме методологія розробки.
sethvargo.com/the-ten-myths-of-devops
Вы как местный Юра. Абсолютно не знаете о чем говорите.
PS: вы не поверите как часто приходят приглашения на интервью, стоило сменить в линкедине “правильное” SE на “неправильное” но понятное рекрутерам DevOps. jobs.dou.ua/vacancies/?search=devops

У нас в компании, даже более того, в моей команде, есть DevOps (компания VertaMedia)

Сори, если обидел DevOps, на самом деле одна из занимательных должностей, как по мне.
Говоря про слабое присутствие DevOps вакансий, имел в виду топ 25 компании . Среди открытых вакансий только у Ciklum есть.
В остальном это или продуктовые или небольшие компании.

Глобал не в топе?
В третий раз повторяю, DevOps это методология, а не должность. Большинство компаний таки понимают разницу и ищут, например, Ruby разработчика для Chef’a или Java/Groovy для Jenkins.
А за подавляющим большинством вакансий с пометкой DevOps (впрочем, справедливо и для соискателей) таки скрывается обыкновенный Ops.
В течении последних пол года только на моем проекте было 5 вакансий (не текучка а именно вакансии), кроме одной все успешно закрыты и люди работают.

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

К вопросу отсутствия DevOps вакансий: jobs.dou.ua/vacancies/?search=devops

Лише додам, що для тих, хто хоче пробувати все по-троху варто йти в маленькі компанії. Там приходиться багато різних функцій виконувати.

Якщо ж більше кайфу від заглиблення в одну технологію, тоді у великі проекти і компанії. Там більше шансів отримати якісну вузьку спеціалізацію.

При устройстве на работу разработчиком, имеет ли какой-то вес опыт в автоматизации тестирования?

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

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

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

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

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

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

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

А еще он должен уметь побелить и покрасить :)
В статье описан: не до программист, не до qa, не до devops, не до аналитик? Готов работать за 3 коп? Потому что один человек все знать хорошо не может. Вот и получается не до настроенные сервера с дырами, не до тестрованное приложение. В стартап может и нужен такой человек, но в остальных случаях лучше делать что то одно, но хорошо.

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

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

за пол года многие знания устаревают. Так имеет ли смысл их так углублять?
в корне не верно. Не самое лучшее напутственное слово для джунов.
в корне не верно. Не самое лучшее напутственное слово для джунов.
Вы ошиблись, когда посчитали что это прямое руководство к действию. Не зря оно стоит в вопросительной форме. Программист должен сам задать себе вопрос и дать на него ответ — «А как глубоко мне нужно ЭТО изучать?». Если это Java Core — то тут без вариантов, копать и копать. Если это, скажем кой нить Redis или Apache Solr, то в большинстве случае хватит базового функционал. И так далее, думаю мысль вы уловили.

Вы правы, неправильно поняла.

некоторый смысл можно уловить

но недо-кодер и недо-куа и.т.д. никакого отношения не к футл-стек девелоперу, и тем более к синьору не имеет...

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

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

странное дело узкая специализация

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

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

Потому что один человек все знать хорошо не может.
Я пожалуй начну тут спор.
Я конечно не гожусь как пример, но вот мои оба деда — очень даже.
Один был инженером, заводы проектировал. Построил сам себе сначала дачу, птм 3этажный дом. Сам. Хороший, продуманный дом. И плюс к этому по любому вопросу может тебе ответить, пусть то биология, география и так далее.
Второй дед шахтер, дачу построил, хорошо играет в шахматы. У этого энциклопедии дома стоят. Про наш мир, что угодно расскажет.
Им не нужны ни сантехники, ни электрики, ни строители — они могут все сделать сами.
Раньше, когда трава была зеленее ;-) , люди знали все. Да, каких-то тонкостей строения тела и названий определенных молекул оба деда не назовут, но объяснить, что и почему болит, и что с этим делать надо, смогут оба.
Про работу.
Первый знал до мельчайших подробностей, что делает завод, как, почему, зачем и для кого. А второй мог рассказать, как устроенна шахта и почему именно так. У обоих знаний больше, чем у профильных министров. И, я думаю, у многих такие старики, умные и образованные.
А еще он должен уметь побелить и покрасить
Ну и в довершение, никто никому ничего не должен. Кроме, налогов гос-ву.
В статье описан: не до программист, не до qa, не до devops, не до аналитик? Готов работать за 3 коп?
В статье описан (по крайней мере, то как прочитал статью я) человек, который знает как работает система, как ее поддерживать и улучшать. В статье описан программист, qa, devops и аналитик в одном лице. Все в порядке. Такие люди есть. Но они не работают в бодишопах. Там такие не нужны.

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

Им не нужны ни сантехники, ни электрики, ни строители — они могут все сделать сами.
та это любой человек может, у которого что-то сломалось, а денег нет

В том, что вы описали особых мозгов не надо, это факт.

Вы путаете хобби, любовь к чтению и профессиональные навыки.
Теория без практики (особенно в программировании) — как капля в море.
Человек оркестр — знает все и толком ничего!

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

Ну так и в чем проблема освоить

qa, devops, аналитик
? Как по мне, так
куча побочных занятий, которые может освоить абсолютно любой человек
qa, devops, аналитик
ну если по-твоему это неполноценные серьезные профессии, то у меня для тебя плохие новости — ты никогда не работал с нормальными представителями этих профессий или просто презираешь коллег по работе

Ну є просто такий варіант — що мені це може не подобатись. Програмісти переважно погано тестують вій код. І тратити часть програміста на щось більше, ніж смоук тестування — просто не доцільно, адже рейт QA набагато нижчий.
Я з набагато більшим задоволенням щось поковиряю в авто ніж буду QA — але це не робить мене автомеханіком =))

и один раз вишен на компот нарвал
Лол, тянет на местный мем )))
Им не нужны ни сантехники, ни электрики, ни строители — они могут все сделать сами.
Раньше, когда трава была зеленее ;-) , люди знали все. Да, каких-то тонкостей строения тела и названий определенных молекул оба деда не назовут, но объяснить, что и почему болит, и что с этим делать надо, смогут оба.

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

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

Если я умею паять, это не значит, что сейчас легко сделаю IPhone. Вы не поверите, что не так просто припаять радиоэлементы и устройство будет работать. Даже правильное расположение, выбор флюса, припоя и материалов печатной платы влияет на работу устройства. Это знания!
Извините, но вы описали примитивные бытовые умения.

Статья устарела лет так на 30 я б сказал ) Разве 30 лет назад било не так?

про 30 не знаю, а исходя из тех 20+ - не было так.
писать приходилось много. фреймворков не было, были только библиотеки. и их было мало, и умели они обычно — мало.

ну конешно не было, они назывались библиотеками, их было вообще достаточно, и умели они все

были тонны прерываний которые надо было знать

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

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

размер боди оф нолидж вырос, сложность выросла, новые подходы появились — в процессе отличий не вижу

Обязанности современного разработчика, 1985 год
Давайте рассмотрим типичный день разработчика на С. Его работа сводится к таким задачам:
— Зайти на удаленный сервер через консоль и настроить одну из компонент, подправить скрипт, сконфигуровровать один из вспомогательных сервисов.
— Проверить почту и настольные бумаги, общаться с коллегами на предмет наличия задач, которые необходимо сейчас решить.
— Почитать инструкцию к недавно введённой библиотеке, разобраться и выполнить с ее помощью одну из задач.
— Исправить ошибку, недавно найденную тестировщиками.
— Ответить на серию писем или сообщений в переписке с заказчиком. Разумеется, на английском. При необходимости созвониться и обговорить вопросы устно.
— Обсудить с коллегами дальнейшие планы на проекте, проблемы и идеи. Помимо запланированных встреч это может происходить во время обеда или в небольшом перерыве, когда вы все свободны.
— Пообщаться с новичками, которые еще вникают в проект (если вы — ведущий разработчик). Оказать свою помощь, если требуется.
— Общаться с другими командами, если над проектом работает больше одной команды. Время от времени может возникать необходимость обсудить вопросы, например, с железячниками, разработчиками драйверов или «ораклистами», инженерами баз данных. Возможно, понадобиться обращаться к ним за советом.
— Следить за тем чтоб проект собирался без предупреждений компилятора. Это минимум, а возможно проверок будет намного больше, это зависит от сложности проекта.
— Посидеть самому или в паре и подумать над архитектурой системы или какой-то одной компонентой.

И где новинка?

В 1985 году не было серверов и локальные сети были редкостью, а основной сетью был незабвенный NetWare. Бал правили цельносодранные ухудшенные копии 360/370 от IBM и аналоги PDP (DEC) по имени СМ и Электроника. Были еще управляющие машины СМ-1/2 содранные с НР.
Касательно технологии разработки софта — похоже , но не было таких заумных терминов и слов и была одна квалификация — инженер-системотехник.

Фреймворк который как минимум могу сразу назвать — turbo vision, появился 25 лет назад

второй — виндоус да будет он проклят

en.wikipedia.org/wiki/Windows_1.0

Фреймворк который как минимум могу сразу назвать — turbo vision, появился 25 лет назад
а вы еще с десяток назовите, а не «как минимум» ;)
второй — виндоус да будет он проклят
en.wikipedia.org/wiki/Windows_1.0
а до 3ей всерьез ее никто и не воспринимал.

«знаток» реалий 30 лет тому ;)

И где новинка?
в том посте просто пустопорожние слова.
и дата 1985 год прилепленная к сегодняшним реалиям.

даже о знании прерываний — вы ни бум-бум.

зюыю
обозвать библиотеку Turbo Vision и графическую обвеску над MS-DOS фреймвокрами это да...

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

Под какую-то раннюю Винду была похожая штука от Борланда же под названием OWL

TurboVision-таки был фреймворком, поскольку навязывал свою архитектуру приложения.
если более полно изложить что я имел ввиду:
TurboVision был практически единственным в то время фреймворком. Ну, или в пятерке первенцев, в отличие от сегодня.
И то, его навязывание дизайна было много мягче чем у нынешних фреймворков.
Архитектуру он не навязывал, можно было использовать только отдельные его части, без особых мук их «выгрызания».
Инструментов о которых можно однозначно сказать это библиотека ИЛИ фреймворк — в действительности не существует.
В одном из проектов в ту пору мы использовали сишную GUI библиотеку Tegl (или Tagl...) — Тэгл произносили. так она кроме GUI предоставляла еще и возможность «виртуализации памяти», то есть ее компоненты с пользовательскими данными умели себя выгружать и загружать в свой своп. Что ессно накладывало на их использование и расширение определенные требования. Считать ее фреймворком? можно. Но по совокупности — она все же скорей библиотека.
Под какую-то раннюю Винду была похожая штука от Борланда же под названием OWL
да, именно. Успех GUI от Apple и тогда не давал покоя :)

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

может еще поговорим чем фреймворк от библиотек отличается в довесок?

майкрософт и борланд по вашему мнению воспринимали свои продукты не всерьез?

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

товарищ Вы не предоставили аргументов, хотя это никого здесь не волнует )
скажите спасибо Sergiy Skynin что он подсказал вам что-то, а то так и дальше думали-бы что все было написано еще в 80х )
помню дос и турбовижен паскалевый, правда тогда еще написал ))) да где-то прото фреймворки но потолок 20 лет

Молодой человек, я там был. Я начал профессионально, то есть за деньги, программировать в начале 90ых.
По тому как именно вы высасываете из пальца аргументы — вы явно там не были. Но знаете лучше меня какое было программирование тогда. Ничем не могу помочь таким знатокам

Статья актуальна только для украинского рынка труда.
Статья актуальна только для тех, кто работает в outsorcing/outstaffing компании.

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

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

Так статья как раз об этом. Многорукость и многогранность разработчика. И автотест написать и настроить Linux сервер. Не часто на проекте есть автотестре и DevOps или админ.

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

Виток развития, через который мы проходим сейчас, дошел до уровня, когда чистый «нативный» код уже почти не используется.
Я бы не стал стричь всех под одну гребенку.
можно с головой уйти в конфигурирование серверов и фреймворков и месяцами не писать код
Конструировать, а не программировать
Писать код уже не достаточно
Не писать код уже недостаточно: пишикодблять
Согласен, современный программист это человек-оркестр.
наоборот.

с ростом специализации — не нужно быть человеком-оркестром.

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

в продуктовой компании на программиста обычно не навешивается работа по саппорту кучи всякого легаси
Ха-ха-ха. Это кто тебе такую глупость сказал? Гугл вон до сих пор свой легаси поиск поддерживает прямиком из 2001. Чем не легаси, проект которому 14 лет?

В иностранном аутсорсинге то же самое если это не продуктовая контора

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

Этот процесс можно сильно ускорить, если попасть в правильную ИТ-компанию.
На какую это компанию Вы намекаете? ;)

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

На какую это компанию Вы намекаете? ;)

Если конкретно — то это крупная аутсорс компания. В мелких конторах все медленнее будет происходить.
Если говорить про Java, то рынок делиться на 2 части:
— крупные игроки, которые диктуют стандарты и держат уровень.
— мелкие компании (до 100 чел), у которых может быть совсем своя кухня и стандарты.

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

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

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

тенденция чем-то схожа на описанную в рассказе Азимова «Профессия».
С той разницей что знания в голову пока не научились копировать, а потому нужно самому изучать и то куда и почему вписывать пару десятков строчечек в день.

Не нужно уже вот так колбасить:
Dr. Joseph M. Newcomer: За пять дней, предшествующих написанию этого эссе, я написал 4470 строк кода. Оплачиваемое время составило 31 час. Получается 144 строки в час (Японский Стандарт Продуктивности), не учитывая 28-страничное руководство, написанное в то же время. Японский Стандарт Продуктивности разрешает мне включать строки кода из существующих библиотек, которые можно использовать. Если я вычту 1038 строк существующей библиотеки, которая была использована, получится 3432 строки или 110 строк в час действительной продуктивности. Это меньше чем мой обычный стандарт, потому что это был действительно красивый «эталонный код», который должен был компилироваться как минимум на трех различных платформах, и я попотел над ним. Плюс был выполнен один нетривиальный пересмотр кода, повлекший за собой вычищение нескольких сотен строк для упрощения задачи в связи с корректировкой модели. В то же время, индустриальный стандарт продуктивности — это 5 строк в час, а для «супер-программистов» — 20 строк в час. И это не включая полное тестирование и документацию.
Специальность — каменщик rsdn.ru/...e/career/BrickScience.xml

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

Я бы сказал, эта тенденция характерна только для тех областей, к которым применимы принципы «массового производства». В электронике этот этап уже давно прошли, наверное еще в 70-80х годах прошлого века, когда создавали чипы для наиболее типовых задач со стандартными схемами включения. Вот за современную электронику не скажу (хотя, понятие «заказная микросхема», по-моему, никуда не делось и поныне), а в программировании еще остались области, для которых нет типовых решений или их нужно сильно допиливать напильником.

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

Ключевое слово здесь — «массовое программирование». Хотя и в нём еще есть ряд «детских болезней», связанных с shared state, которые хорошо решаются переходом к функциональной парадигме.

И затем — готовые для использования алгоритмы кто-то же создаёт? :)

и даже к бОльшей части американского.

ОК, а в опен-сорц только Америка контрибьютит?

И затем — готовые для использования алгоритмы кто-то же создаёт? :)
этим вопросом и задался главный герой Азимова.
Прочтите на досуге :)
а в программировании еще остались области, для которых нет типовых решений или их нужно сильно допиливать напильником.
и будут. и в любой деятельности будут такие области.
И?
Ключевое слово здесь — «массовое программирование».
да. не судить же от тенденциях по «маргинальному программированию»
или «элитарному», «богемному», если слово маргинальное неприятно.
Я бы сказал, эта тенденция характерна только для тех областей, к которым применимы принципы «массового производства».
...и потому поправка эта звучит примерно как

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

Контрпример какбе:
www.facebook.com/...3/609508305852627/?type=1

Правда, не аутсорс

P.S. Никакого отношения к этому проекту не имею

Решение задач машинного зрения и инерциальной навигации тем способом, который описан по ссылке — это «при помощи рта и правой ноги»? Ну ОК, я не спец в этой теме, может, вы тогда сделаете доброе дело и просветите ребят, какие штатные решения можно использовать?

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

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

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

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

какой процент художников НЕ использует рук при создании картин?

и т.д.

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

то есть вы что, не врубаетесь в статистические понятия,
что когда говорят:

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

водители авто бла-бла-бла, это означает — подавляющее большинство водителей авто бла-бла-бла

и т.д.

что суете какие-то маргинальные случаи в качестве «контпримеров»???

то есть вы что, не врубаетесь в статистические понятия

Есть ложь, есть большая ложь, а есть статистика :)

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

Хотя вот, рождаются же в Украине Augmented Pixels и т.п. стартапы, неужели все — из вот этих «маргинальных случаев»?

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

процент миллиардеров много меньше процента миллинеров.
пилотов много меньше авиамехаников.
докторов наук много меньше числа их ассистентов.

это специфика именно современного украинского аутсорса.
а также индийского.

а также специфика айти департментов в непрограммиских компаниях.

откуда например в Tiobe — Visual Basic?
да оттуда, с огромного количества кода только в макросах MS Office.
которые тоже нужно поддерживать.

Можно конечно снобиски сказать что это не программисты.

ну типа — владельцы авто не водители! и маршрутчики с дальнобойщиками не водители! Водители это призеры Дакара и Формулы 1!

рождаются же в Украине Augmented Pixels и т.п. стартапы, неужели все — из вот этих «маргинальных случаев»?
конечно.

В Украине даже миллиардеры есть. ну там ахметовы, пинчуки, — неужели это маргинальные случаи?

Везде есть исключения, согласен. Критика только приветствуется. Я больше по Java, там такая ситуация.

С джунами все интересно. Проводил несколько десятков собеседований, джуны были тоже.
У них спрашиваю ничего кроме сортировок и базы, по причине что они де факто не могут знать большего.
Если Junior сам начнет рассказывать что такое Agile, как он будет работать в Scrum команде, как будет вести задачи в Jira, комитить в Git репозиторий и деплоить свое приложение — поверь, у него нет шансов не получить работу)
Но откуда он это может знать? Вот я и предлагаю способы для этого, стажировка, менторинг опытных, самостоятельная работа и интерес к тому, чем будешь заниматься.

Тобто, я зі своїми 6 роками повноцінного досвіду можу в будь-який момент йти до вас джуном на java? Чисто теоретично, в даний момент я взагалі рубі вчу для чергового свого pet project.

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

Підписатись на коментарі