Comments 53
Вообще-то design — это больше про проектирование, а не про внешний вид и то, что под дизайном подразумевается у нас. Читая статью — так и не поняла, какой смысл в это слово вкладывает автор.
а у меня сложилось впечатление, что графическая-визуальная часть входит в markup and styling :-/
в итоге это и есть проектирование. иначе он бы, наверное, или прямо написал graphic design или не указывал отдельно про markup & styling
Фулстеком называли человека, который мог и в фотошопе щаблон задизайнить, и потом сверстать его с html+css (да, была отдельная профа — верстальщик, который брал хаотичный psd от дизайнера и пытался все перделки перевести в «тогдашний» веб 2.0), а потом еще и запилить какой либо небольшой движек на простеньком js+php+mysql.
Дизайн обычно не входил всё же.
Типичный случай — Java-разработчик посещает конференции не только по Java, но и по тестированию или DevOps. А ещё может посмотреть видеозапись доклада про GraphQL с JS-конференции или про архитектуру с .NET-мероприятия.
Этот человек не занимается фронтендом, но лезет сразу в разные стороны, чтобы лучше понимать всё вокруг, расширять доступный скоуп задач и находить общий язык с окружающими (тестировщиками, фронтендерами, инфраструктурщиками).
Вот это и удручает в сложившейся ситуации. Разработчик смотрит по сторонам, чтобы лучше понимать обстоятельства своей работы. Но не тестировщик/инфраструктурщик/фронтендер ищет пути избежать копипасты или просто именовать константы явно.
Получается некий тренд — назвался груздем, полезай в короб. Тестировщик — никто от тебя не ждет элегантный код на Питоне для автоматизированного тестирования. Разработчик — ну ты там тестерам помоги автоматизацию написать.
Я встречался со случаями, где к этим 4 добавляли разработку под смарты
Я новенький на хабре и как раз учусь на верстальщика (фронтенд в будущем)
«Теперь в мире IT вообще нет четких понятий и определений»Да куда ж они делись, слово «компилятор» как было, так и есть. Предыдущий пост в нашем блоге озаглавлен «Уязвимости в реализации межпроцессного взаимодействия в Android-приложениях» — по-моему, и «уязвимость», и «межпроцессное взаимодействие», и «Android-приложения» довольно конкретные понятия.
«Какому-то естественному процессу, который существует уже сотни лет, решают дать название, не имея никакого четкого определения, потому что это в принципе невозможно»Тут какая штука: если естественный процесс существует уже сотни лет, вероятно, это довольно значимый процесс. А значит, может быть необходимо учитывать его в работе и обсуждать в рабочих диалогах. А для этого нужны какие-то слова, даже если абсолютно чёткие невозможны и приходится использовать какие есть.
И не знаю, чем для вас провинились «омериканцы», но хочу отметить, что слово «scrum» в IT-мир принесли японцы, а слово «devops» — бельгиец. Вот более конкретное «compiler» — американское, да.
А для этого нужны какие-то слова,
а можно имеющееся назвать новыми словами, скажем платформа и конфигурация и уже можно окормлять выделенную паству.
Насчёт компиляторов на 100% не уверен, то вот многие популярные интерпретаторы весьма далеки от классических. Тут и промежуточная компиляция в байт-код, и компиляция этого байт-кода в машинный в процессе его интерпретации ака JIT.
Но если подходить настолько строго, то получится не «теперь в мире IT нет чётких понятий», а «в мире IT никогда и не было чётких понятий» :) Прямо с того момента, как впервые было использовано слово «баг», можно было спорить о том, где заканчивается баг и начинается фича.
Принципиальное отличие от оригинального определения, как мне кажется, именно в этом «design». Потому что после первых трех языков подтянуть еще десять — это вопрос исключительно желания. А нарисовать иконку — которая не вызывала бы рвотных рефлексов — я, к примеру, не сумею никогда.
Поэтому в оригинальном варианте «full stack» —было вопросом отчасти дарования, ну вот как full stack поэт: автор стихов, если захочет, может стать бардом — но тогда, и только тогда, когда ему по рождению достался музыкальный слух. А в нынешнем понимании — «full stack» — это вопрос исключительно желания. Мне просто не нравится, например, javascript — ну вот я и избегаю всего, что с ним связано. Но когда потребовались расширения для браузера, которых не было — ну, сел, да написал, чего уж там. С дизайном так не прокатит.
Я, кстати, по схожим причинам никогда не читаю дальше заголовка резюме, в автореферате которых гвоздями прибит язык программирования («разработчик дотнет», «программист java»). Если ты не джуниор — на каком именно языке писать должно быть делом предпочтений, а не приговором.
Говорят, что музыкальный слух можно развивать. Если это правда, то и приемлимую иконку можно, наверное, научиться рисовать, если несколько (ближе к 10 чем к 1) лет тратить по часу в день на это под руководством опытного учителя.
Это так, говорю, как человек, развивший и музыкальный слух, и навык рисования иконок :)
Но все равно предел — это вот что-то типа такого:
— для библиотеки Agency
или
— для Telemetria
или
— для Tempus
Оно всегда вторично и немного неуклюже. Хотя я приложил некоторые усилия, без балды.
Если ты не джуниор — на каком именно языке писать должно быть делом предпочтений, а не приговором.
Ну если я предпочитаю писать на C#, мне кажется вполне логичным указывать в резюме, что я C# Developer — при чем тут "приговор", если я этот язык по собственному желанию выбрал? Или вы имеете в виду "должно быть делом предпочтений работодателя"?
Скорее "должно быть делом договоренностей работника с работодателем".
Мне кажется логичным в резюме писать так:
— разработчик
— люблю: C#
— могу: Rust, F#
— могу, но не буду: C++, Java, Go, Haskell
У меня (когда у меня было резюме) — именно так и было написано (только языков побольше).
В любом случае, позиция обычно обозначает список услуг, которые компания норовит получить от разработчика.
Я стараюсь быть максимально конкретным, чтобы не приходилось продираться через горы мусора в ответах. Сейчас у меня вообще написано "Backend C# Developer", а прилетает и фуллстек, и джава, и бог весть еще что — чего даже в списке "могу, но не буду" нет.
Ну, то есть ваша конкретность вам помогает не особо :)
Потому что мусор прилетает от эйчаров, которые как свидетели Иеговы же: стоит щель приоткрыть — тут же ботинок всунут и заведут речитативную шарманку.
У меня закрыта страница в Linkedin; во всех местах, где можно наткнуться на мое существование ажурным капслоком набрано «я не ищу работу, и отправляю рекрутеров в бан немедленно». И да, особо инициативные просачиваются и зовут на позицию «Java Junior» в США (хотя про мое отношение к США в целом написано там же, в еще более обсценной форме).
Но, как представитель другой стороны, я не ищу специалистов — сами приходят. Я говорил про ситуацию, когда я получаю резюме от соискателя. Я ожидаю увидеть там чуть больше навыков, чем один язык.
А для бизнеса fullstack == тыж программист.
<:o)
Такому бизнесу и Stackoverflow — разработчик подойдет.
Да на чём сэкономить-то? Если нужно для фичи 100 часов фронта и 100 часов бэка, то сэкономить с фуллстэком получится хорошо если процентов 15-20 суммарного времени при одинаковой квалификации за счёт отсутствия потерь на коммуникации. Но в деньгах эти проценты аннулируются, скорее всего, более высоким рейтом, а фича будет готова через 160 часов, а не через 100.
На мой взгляд, безопасное использование концепции «фулл-стэк» ограничивается совместным дизайном (способность понять проблемы и ограничения друг друга снижает нагрузку на архитекторов и техдиров) и возможностью «поправить» что-то друг у друга в коде в случае каких-то срочных и критических проблем. А в остальном — каждый должен быть специалистом в своем деле.
Все-таки разделение функций заставляет вводить какие-то более-менее понятные интерфейсы и конвенции.
С одной стороны, куча примеров когда не заставляло: подошёл фронт к бэку, обсудили вдвоём и родили какой-то API по фиче с понятной только им двоим логикой.
На мой взгляд, безопасное использование концепции «фулл-стэк» ограничивается совместным дизайном… и возможностью «поправить» что-то друг у друга в коде в случае каких-то срочных и критических проблем.
Проблема в таком походе на мой взгляд в том, что специализируясь на, например, бэкенде со временем перестаёшь понимать современные фронтенд технологии, их проблемы и ограничения. Вот банальный Реакт 2015-го года и 2020-го года — две большие разницы. Да даже 2018-го и 2020-го.
Вполне может быть там, где клиент-северная архитектура, особенно с GUI клиентами. Пускай один и тот же стэк (C++ например), но одни могут специализироваться на сервере, другие на клиентах, а третьи и то, и другое писать.
Насчёт конкретно 1С не уверен, есть ли там заметная специфика разделения.
Иногда задумываюсь о том, чтобы пойти на курсы UI/UX дизайна, чтобы закрыть весь стэк компетенций, нужных для создания типичного веб-приложения. Потом вспоминаю, что сюда уже и мобайл суют, и СКЗИ и вообще безопасность надо подтянуть. Сети опять же (BGP что такое, стыдно признаться, не знаю, AS какие-то ещё). Хотя бы пару облаков, Amazon и Google надо освоить нормально. Terraform какой-то. Навыки продаж, в прямом и переносном смысле, технических и организационных решений отточить. И английский хотя бы до Upper intermediate подтянуть. И Макось освоить хоть немного, чтобы больше не позориться, на собесах и посмотреть куда винда ушла со времён XP. И курсы по руководству… И Кнута дочитать… И DDD, который DataDrivenDesign И BigData c ML. NoSQL, хотя бы монгу…
И возвращаюсь в свою уютную зону комфорта из, навскидку:
Linux + простыни Ansible для разворачивания
Docker (+ k8s когда bash+docker-compose/swarm не хватает)
БД (MySQL, Postgresql)
Сервера (PHP, JS/TS), монолит и выделяемые микросервисы
Веб-клиенты (Html, немного CSS, ванильный JS/TS или React+MobX)
CI/CD пайплайнов
Selenium или pupiter для тестов
Руководство небольшой командой
Возвращаюсь с мыслями, что создать от А до Я современный проект я уже не смогу, и последние лет 10 я 100% самозванец, когда пишу в резюме Full Stack Web Developer. Но только так могу претендовать на вакансии, где востребована хотя бы половина моих навыков. Правда вот ещё с некоторыми вакансиями DevOps инженеров, чтобы это не значило, пересекается сильно.
собственно, full ты stack или не full зависит от самого́ стэка — какие технологии использует или хочет/готов использовать наниматель. Вот надо ему сайты делать, чтоб блэкджек и мадамы были — один стэк. Надо какие-то сервисы с аналитикой и автоматикой — другой стэк. ятакщетаю.
Что вообще значит «full stack»?