По моему опыту работы с Upwork (около трёх лет активно работал там, потом перешёл на фулл-тайм удалёнку с прямым контрактом): фриланс меньше приносит дохода при этом больше головной боли общения с разными заказчиками и значительно больше рисков. Но есть и положительная сторона — возможность выбирать задачи на свой вкус. Я бы рекомендовал фриланс для разработчиков уровня Junior+\Middle для того, чтобы набраться опыта и ощутить полную ответственность за результат своей работы.

Из моего опыта Laravel не уступает Symfony по уровню компенсации, а может даже и чуть повыше. А если ещё и есть опыт одного из фреймворков фронта (Vue.js довольно часто в связке с Laravel идёт), так и ещё на дополнительную прибавку можно рассчитывать.

Крок 7. Забудьте про PHP

«Let the War Begin» ©

Так, середня ЗП для PHP трохи нижче деяких інших мов програмування, але прям «забудьте», серйозно? Ринок PHP все ще величезний, нових проектів не супер багато, але вони є, а також є дуже багато проектів, які потребують підтримки\розвитку.
«Забудьте про PHP» — це підтримка фальшивих стереотипів, які не базуються на об’єктивних даних, не треба так :)

І, до речі, щось немає згадки про прямі контракти. ІМХО перехід на прямий контракт дозволить значно більше виграти по оплаті, ніж зміна мови програмування з PHP на іншу. При цьому «світчерам» треба бути готовим, що оплата суттєво просяде спочатку, та лише потім дещо зросте.

P.S. Ну, а взагалі мені ж тільки краще, чим більше таких заяв, тим менша конкуренція серед PHP розробників — отже вища середня ЗП))

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

Прям конкретно в цифрах не считал к сожалению. Из 20 задач не попал в оценку навскидку задачах в 11-12, больше половины в общем. Из них 5-6 задач процентов на 30, что по идее не сильно критично, но были задачи где и на 50 и больше, до 100. Проблема ещё и в том, что точность оценки зависит от сложности и объёма задачи, чем сложнее задача, тем больше разброс в оценке и тем чаще ошибаюсь с эстимейтами. То есть выходит что на более важных (сложных и больших) задачах я как раз чаще ошибаюсь.
Решением вижу не давать оценок «навскидку», а брать дополнительное время для оценки времени и не экономить на нём: вникать во все детали задачи, разбивать задачу на небольшие части и оценивать уже их (собственно, как в данной статье и предлагается). Сюда же по поводу «заморачиваться» — насколько я могу судить, я не сильно заморачиваюсь, возможно даже нужно наоборот ответственнее подходить к оценке и не давать быстрых оценок, как этого возможно ждут от меня.
На счёт смены менеджмента: не уверен, что это решение. Проблемы с оценкой задач у меня наблюдалась на нескольких местах работы, то есть или мне подряд не везло с менеджментом или всё-таки проблема во мне :)

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

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

Статистика DOU — это текущие зарплаты разработчиков, многие работают с ЗП ниже рынка и не имеют мотивации менять компанию. Поэтому при условии довольно перегретого рынка (для мидлов\сеньоров) ЗП при переходе в новую компанию выше средней по статистике. Плюс на том же Djinni попадаются предложения с прямыми контрактами, там ещё выше ЗП. И кстати судя по этим предложениям (и по личному опыту тоже) Украина по рейтам уже в целом довольно близко к Европе (процентов 20-30 примерно разница навскидку), но до штатов ещё далековато конечно, это да.

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

Дякую що поділилися досвідом, корисно.
На поточному місці роботи спілкувався з колегою, який проводив співбесіду зі мною: він поділився враженням, що за результатами співбесіди я був гірше, ніж інший мій колега, але за результатами роботи в команді ситуація зворотна.
Думаю, що така ситуація нерідко виникає, все-таки буває, що проходження співбесіди — це окремий навик, який можна «прокачати» і не завжди він корелює з практичними результатами роботи у команді.
Чи дозволяє ваш підхід виключити такі ситуації або все ж таки помилки трапляються? Якщо так, то як часто? Дякую :)

Да, по части форматирования, согласен. Но в Clean code там же не столько о форматировании, сколько о структуре кода, нейминге и т.д.

Да, критика по существу, Мартин излишне категоричный и это наверное может сбивать с толку, особенно разработчиков на начальном уровне. Но ИМХО я бы не выбирал между Мартином и Макконелом, а читал и то, и то. Просто не воспринимать написанное как истину высшей инстанции, а принимать к сведению так сказать :)

А что никто про Clean code (by Robert Martin) не пишет? Или это рекомендация по умолчанию и не стоит упоминания? :)

Всё ещё довольно часто работают как минимум несколько человек над одним проектом из одного офиса, даже если на разных, но с одним стеком — всегда полезно за чашечкой кофе обсудить какие-то вопросы/проблемы проекта коллеги.

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

Спасибо за статью, хорошее сравнение.
Интересно было бы узнать есть ли какие-то закономерности статистики использования Vue.js\React в привязке к бэкенду (PHP, .Net, Java, Node.js и т.д.).

Многие работают удалённо а живут в Украине. В этом случае их компаний, насколько я понимаю, нет в списке, и они не смогут участвовать в рейтинге?

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

Быстро и эффективно — это лучше с репетитором, но часто бывает, что срочности нет и вполне себе можно учить язык онлайн + дополнительно смотреть нравящийся контент на английском. Почему нет? Получается двойная польза — и посмотрел что-то интересное\полезное и английский потренировал.
Лично я так учил язык:
— базовая школьная программа
— несколько месяцев курсов несколько раз в неделю
— потом перерыв в несколько лет и дальше онлайн обучение и просмотр видео с субтитрами, плюс периодическое чтение мануалов и доков по работе
— после этого начал общаться по работе в чате на английском
— следующий шаг: созвоны на английском, вначале корявенько, дальше — лучше
сейчас довольно свободно могу обсуждать рабочие вопросы, но конечно нет предела совершенству

www.facebook.com/kharkovgoengclub
вот ещё несколько раз в неделю собираются ребята
нейтивы тоже бывают, насколько я понимаю

хотелось бы конечно надеяться, что не «by design»)

Ладно «Дима», а что, если им попался «Слава»? Кто это — «Вячеслав», «Святослав», «Надіcлав»?

Как обладатель сего чудесного имени периодически сталкиваюсь с T9 в виде чего-нибудь вроде такого:
«slave, could you please add this feature?» %)
Хорошо, что я не обидчивый)