Существует три популярных варианта трудоустройства: работа в офисе, фриланс и удаленная работа. В этой статье я хочу поговорить о достоинствах и недостатках каждого из них.
https://s0er.ru/documents/article/3588

У меня на руках билеты в Питер на 9-ое число. Должна была быть большая конфа, но не случилось. Билеты остались, ехать или нет - вот в чем вопрос? Можно просто сгонять потусить, Питер - это всегда хорошо. Что скажете?

Стрим на часок https://youtu.be/8hrcdNOMRGA

Вчера на стриме были вопросы про чистую архитектуру и Angular. Мол Angular создавался с использованием чистой архитектуры, это написано не где-нибудь, а на самом Хабре! У меня встречный вопрос: "где ваше критическое мышление, господа?". Роберт Мартин написал свою книгу "Чистая архитектура" в 2017 году, а ангуляр вышел в 2012. Ничего не смущает?

Вчера на стриме ляпнул, что не встречал действующих программистов старше 40. Сегодня подошел к зеркалу:
- мне 40+
- я действующий программист...
можно ли сказать, что я встретил действующего программиста которому за 40?

Ограничения - это добро для любого развития. Например, когда-то в Твиттере было ограничение на 140 символов на сообщение (правда его потом подняли, но не суть). Казалось бы, что можно сказать в 140 символов? Оказалось, что многое. Более того, если вы ничего не можете сказать, используя только 140 символов, то и большего количества символов точно не хватит. Тут можно вспомнить про "краткость сестра таланта", "семь раз отмерь, один раз отрежь" и т.д.

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

Было бы здорово, если интернете срачи тоже имели ограничение на "один ответ", а то сейчас можно объяснять что такое рекурсия на примере этого алгоритма:
1. кто-то в интернете сказал что-то с чем несогласен некто
2. некто выпускает опровержение, на слова кого-то
3. кто-то видит опровержение и выпускает свое опровержение
4. некто переходит к п.2 и выпускает опровержение на опровержение

Так и живем.

Выпустил видео про архитектурные основы приложения, использующего JWT
https://www.youtube.com/watch?v=mWNN8hpXS-A

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

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

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

Правда, есть одно "но". Главное - не засиживаться на такой работе. Малый бизенс и стартапы - это максимум 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