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

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

Правда, есть одно "но". Главное - не засиживаться на такой работе. Малый бизенс и стартапы - это максимум 2 (хорошо, 3) года вашей карьеры, чтобы получить строчку в трудовой и резюме. Потом уже ищите вакансии в более крутых компаниях. Это не значит, что работать в маленькой компании не интересно. Просто, не сможет бизнес с оборотом 50 млн./год платить 500-600к в месяц. Как говорится "ничего личного".

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

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

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


https://www.youtube.com/watch?v=KrHWHTKmMHg

От сего момента и примерно до 20:30 я и Ден на большой конюшенной 14 бар охулиганс (это Питер, напоминаю). Если вы где-то рядом, то подходите можем пообщаться. Всем пришедшим от меня в подарок наклейка канала.

+1

Нас становится больше

Вишенка на торте - все пиво за сегоднящний вечер за счёт Дена. Как говорится "надо было приходить"

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

Архитектурный подход к построению вашего продукта не означает "долго". Он означает "учитывая вектор развития".
Вы должны определиться со своими целями, прежде чем начнёте куда либо двигаться, а далее на каждом шаге проверять придерживаетесь курса или нет. Для этого нужно выработать принципы построения проекта и научиться отвечать на вопрос "зачем?". Например, зачем я использую СУБД, а не пишу данные в файл. Если не можете ответить на вопрос "зачем", то вероятно у вас нет необходимости в СУБД.
На уровне принципов архитектурный подход определяет и правила ведения документации, и уровень детализации проекта и т.д.
Делая стартап вы можете сильно упростить требования к ведению проекта, а разрабатывая космический аппарат, наоборот усложнить.
Есть разные техники, помогающие выработать нужные привычки, например "проговаривание" - "я делаю этот класс потому что ..."
В целом архитектурный подход ничуть не "дольше", чем "делаем как получится". Наоборот, он призван уменьшить энтропию вашего проекта и увеличить синергию команды.
Проблема лишь одна - нужно учиться, но это сложно, куда проще сказать "нам и так сойдет", а потом убедить себя, что все так работают и ничего.

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

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

Microsoft - тут все просто, Билл вообще не заморачивался на создание продукта, он купил готовую OS, которая работала и поставлялась на ПК от IBM. Тоже пример когда изначально было нормальное готовое решение.

Facebook - один из "близких" к обсуждаемой задаче примеров. Но опять же, до Facebook был Facemash, при создании самого Facebook Цукерберг работал над прототипом братьев Уинклвосс, идея которого и легла в основу Facebook. Правда, остается вопрос был ли прототип или все же была только идея. Насколько я читал. прототип таки был, потому что Цукерберг в суде доказывал, что ни строчки кода он не взял. Но взял ли он архитектурные идеи и насколько вообще заимствовал из этого проекта - неизвестно. Одно точно, опыт создания аналогичных проектов у Марка был и очевидно, что он его использовал для запуска Facebook.

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

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

https://s0er.ru/documents/article/3741

#книга #ссылки

В 2000-ом году Джоэл Спольки сформулировал 12 вопросов, которые показывают зрелость вашей команды. Это очень хороший список того, чего у плохих команд никогда нет.
Минимальный "проходной бал" - 6. Если ваша команда набирает меньше 6, то вам надо срочно с этим что-то делать.
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

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

Изложил свои мысли по поводу переписывания с нуля. Получился лонгрид, который я вынес на SOER MEDIA - https://s0er.ru/documents/article/3751

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

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

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

Постепенно отказываюсь от гугловых сервисов, сейчас перевожу документы на Yandex Документы. Не ожидал, но решение Яндекса мне нравится в разы больше. Ребятам разрабам большой респект! Очень круто сделали.

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

По поводу Яндекс.Документов надо сделать уточнение, вроде как они используют Р7-офис, который в свою очередь много чего взял от OnlyOffice. Т.е. это сила OpenSource опять дала о себе знать. Так что получается, что в большей мере молодцы не столько Яндекс-разработчики, а ребята из OnlyOffice и Р7, но в целом это не отменяет того, что у Яндекса много классных сервисов. Пишу это потому что "публичные персоны должны быть правдивы и не предвзяты".

Возобновил приём новых участников в ITUBETEAM позвал Рому Сакутина, пока жду его ответа.
Вопрос такой - кого из русскоговорящих ютуберов вы считаете профи своего дела?

Пример того как не особо напрягаясь за полтора часа можно собрать инфраструктуру на докере, которая покроет абсолютно все потребности начинающего стартапа как в росте, так и в архитектуре. Плюс уже настроенный рабочий workflow через gitlab.
Конечно, можно костылить через LAMP и PHP и по старинке все вручную устанавливать, но я не понимаю зачем, если с нуля до "ready to go" занимает жалкие 90 минут?
https://www.youtube.com/watch?v=o91Dnq24sEQ

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

Я снова оживил формат S0ER TALKS и теперь он стал по-настоящему "TALKS", вообще не редактируя, сразу с записи и в прод. Да я обленился или хочу просто почесать языком, это уже вам виднее - https://www.youtube.com/watch?v=nCPTiUdTgn0