All streams
Search
Write a publication
Pull to refresh
20
0
Send message
m1rko увидел ваш ник под статьей, и понял, что он мне знаком.
Посмотрел ваш профиль — 150 публикаций. Чуть больше чем за 1 год. Публикация раз в 3-4 дня. Переводы, переводы, переводы. Многие переводы набирают десятки тысяч, некоторые больше сотни тысяч. Многие из них я читал.

Кто вы? Откуда такие ресурсы для переводов? Как вы подбираете статьи? Какие у вас цели? И почему вы не участвуете в рейтинге на Хабре?
Полезные идеи на случай, если он испытывает отчаяние, работая программистом.

Если работая программистом кто-то испытывает отчаяние — пора перестать быть программистом). Я еще понимаю, как можно испытывать отчаяние, работая учителем, врачом в поликлинике, и или еще кем-то, где низкие зарплаты, но вы любите свою работу. Но вот работая программистом и испытывать отчаяние можно только, если вы не любите программировать, а тут ради денег. Но вы кажется научились справляться с этой трудностью) +50% к окладу добавляет на полгода мотивации)

Мне кажется вы обожаете свою работу только за размер оклада. Высокий оклад, никаких переработок, возможность получить +50% к окладу просто сменив место работы и т.д. А вот сама работа программиста вам кажется не сильно интересна)

Но найдите баланс, чтобы выглядеть профессионалом, а не нахальным типом с завышенным самомнением.
А вариант быть профессионалом, а не нахальным типом вы не рассматриваете? Только выглядеть, потому что может подвернуться выгодная возможность? Не завидую я тем, кто берет вас на работу)
Мне одному кажется, что тут забыли рассмотреть один ну совсем маленький, и вовсе не достойный внимания этап — написание SOFTа с этой штуковине? И чтобы эта штука работала — нужен очень квалифицированный разработчик, который полгода будет её писать как минимум?

… на ПК устанавливать ПО для обработки данных. Но теперь понадобилось управлять шаговым двигателем и вместо еще одно USB устройства (контроллер типа Ардуина), было решено внедрить в устройство Raspberry. Написать для него софт и подключать устройство к Ethernet, что позволяет (при написания плагина)


Я тоже так могу по ТРИЗ сказать, что у меня есть самоуправляемый автомобиль на 5GHz датчиках + RFID метках, и цена его в 500 раз меньше чем, то, что делает Yandex, Uber, Google и прочие) Там же Raspberry + пара плагинов и все)
Было такое как минимум в банковской среде в Москве в 90-x.
Тогда банки слушали своих сотрудников, и знаю случаи, когда отменяли уже сделанный оффер «по звонку». Что-то вроде соглашения Microsoft, Google, Apple — не переманивать сотрудников друг у друга.

Но сейчас на рынке IT, где сотрудники более востребованы, чем работодатели, считаю, что если такое случится, то оба начальника достойны того, чтобы их послать) Конечно если вы хороший разработчик/админ/тестировщик/devops/… и вам найти работу не проблема)

Я бы даже сказал: «Вам повезло», вы узнали правду о будущем начальнике до найма)
Был у меня однажды случай. Я работал backend разработчиком, но меня не устраивала производительность команды, и моя производительность, как части этой команды, в частности. Я был уверен, что можно делать тот же самый функционал на в 3-5 раз быстрее. (сменив впоследствии место работы, я понял, что был прав)

Сходил на собеседование, получил оффер, где-то на 35% больше текущей ЗП, понял, что спрос есть, оффер принимать не стал (по ряду причин). Примерно в это время команду покинуло 2 разработчика. Руководитель решил поговорить со всеми тет-а-тет, и попросил предупредить, если я соберусь уходить). Ну я и сказал, что если через 3 месяца ряд очевидных проблем не будет решено, то я покину команду.

Ну, а когда я пришел через 3 месяца, и сказал, что всё, я увольняюсь — все были очень злы и недовольны. Но я чувствовал себя отлично, потому что я был честный, и никого не обманывал.

Так что мне кажется, что как руководитель может быть честен, со своими подчиненными, так и сотрудник может быть честен, и честно говорить, так и так, это не шантаж, но ситуация вот такая.
Любимый, Хабр! С новым годом! Спасибо что ты есть!

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

P.S. Дедушка мороз, подари мне, пожалуйста, в 2018-м году сворачивание веток комментариев)
Согласен с вами. Блокчейн не нужен везде и порой его пихают туда, где ему не место.

Но я думаю, что блокчейн для paypal, amazon, apple pay, appstore повысит доверие пользователей. Применяя блокчейн компаниям будет сложнее втихаря «списывать старые бонусы», блокировать аккаунты и забить их бонусы, пересчитывать бонусы задним числом, устроить конкурс, где призовой фонд 1 млн условных фишек, а 700 000 достались одного аккаунту, и т.д. и т.п. Да в конце концов мы будем уверены, что условный Google/PayPal не заблокирует наш аккаунт, потому что ему так захотелось. А значит такая валюта и компания вызывает больше доверия. Я думаю лет через 20 мы придем к тому, что компания с закрытой бухгалтерией будет вызывать у нас оооочень много недоверия.

Стоит вспомнить пенсионный фонд РФ, который просто взял и деньги заменил баллами, и теперь регулярно откладывает выплаты накопительной части пенсии))
И никто не может посмотреть, что же там происходит. Сколько же денег всего. Сколько было перечислено и т.д. Какой процент денег уходит на обслуживание пенсионного фонда, какой процент уходит на зарплаты.

Я бы хотел, что у ЖКХ были прозрачные финансы, у ритейлеров были свои прозрачные финансы. И тут блокчейн во-первых обладает публичностью, а во вторых неизменяемостью.
Поэтому и хорошо бы студенту объяснять ООП на примере какого-то простого языка.
А может быть даже фреймворка. Берешь Ruby on Rails, создаешь модельку, у нее 5-10 методов.
Ну и просто в консоли делается
post1 = Post.new(title: '123')
post1.save
post2 = Post.new(title: '234')
post2.save
puts post1.title
puts post2.title
И не важно, что на этом этапе студент не понимает, где тут инстанс, где тут класс, и то же, Post — это тоже инстанс, но другого класса, да еще унаследованный от десятка других.

Дальше дается задание — создать 10-20-30 таких моделек + методов.

Потом спускаемся ниже, на уровень Ruby.
Где уже ручками надо задать initialize, ручками прописать attr_reader, attr_writer.
Даем примеры на усвоение. Вот тут можно заикнуться, кто тут инстанс, и пару слов про наследование. Опять же примеры.

Потом рассказываем про ООП и наследование классов в том же Ruby. И поясняем как работало то, что мы на прошлом уроке уже использовали. Опять практика.

И уже потом, после написанного мини приложения, аля блог, с правами доступа и комментариями, после понимание логики, что тут вообще к чему — начинать объяснять абстрактный ООП не применительно к конкретному языку.
Проверил запуск на MacBook
MS Word — 1.83s
Pages — 0.75s

Данные усреднены по 3-м попыткам.
Время засекалось кустарно, секундомером на iPhone. Стоп нажимал после того как увидел открывшееся приложение.

К сравнению, самое быстрое двойное нажатие, которое я смог сделать на секундомере это 0.08 секунд. 0,10 получилось сделать раза два, остально 0,12 +

Уж не знаю, где там Word открывается 9 секунд.

А вот то, что меня расстроило, так это то, что новая вкладка в терминале с ZSH открывается 1.15 секунды. Открывал новую вкладку как только видел строку ввода, 20 раз, получил 23 секунды. Закрыл 40 штук за 11 секунд, или 0,28 на вкладку. Значит думает комп как минимум 0,87c. Над новой вкладкой. Карл!

За это время мое приложение успевает сбегать 2 раза в базу, выгрузить 2000 сущностей, посчитать рейтинг, и все это 145 раз! (6ms на итерацию). Хммммммммм… интересно
Logomachine Отличная статья. Спасибо. Для меня самое интересное в этом, это то, как определить толщину разных этапов. С трубой все понятно — есть измеримый показатель в см, и этот показатель одинаков на всех участках.

Но возьмем ту же воронку продаж.
Например у нас показатели:

10 000 посетителей/мес на сайте
100 лидов
30 продаж
90 000 маржи в месяц.

Как понять где тут узкое место?
10 000 посетителей?
Или конверсия в 1%?
Или конверсия в продажу 30%?
Или средняя маржа на один заказ 3000?

Есть что-то об этом в книге Голдратта? Или может по своему опыту?
А я согласен и с теми и с другими.
100 лет назад 70% населения тех же США были заняты в сельском хозяйстве. Все протесты луддитов ничто, потому что никогда на фабриках не работало 70% населения. Сейчас в сельском хозяйстве занято 3% населения. То есть комбайны, трактора, косилки, автоматический дойки коров и т.д. сократили 95% рабочих мест в сельском хозяйстве и 67% а абсолютном значении. И ничего! Никто не умер. Об этом писал еще Ремарк 100 лет назад. Та же молодежь, все так же не знает, чем же ей заняться.

Но ничего, за эти 100 лет выросли авиационная, автомобильная, космическая, ТВ, радио, игровая, кино, IT индустрии. Крайне развилась торговля, логистика, туризм, сфера услуг и т.д.

Чтобы понимать разницу стоит посмотреть на интересный фотографии из шахтерских городов благополучной Англии и Франции в 70-х годах. aloban75.livejournal.com/893618.html

Я был в шоке, когда их нашел. У них не было горячей воды. Советские хрущевки по сравнению с этим — райское место. Просто потому что там есть горячая вода, центральной отопление и свет.

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

Но в то же время я понимаю, что эти 6 млн дальнобойщиков США очень скоро могут потерять работу. В США я проехал 100 км на круизконтроле не касаясь педалей! В таком потоке беспилотный грузовик очень легко справится с долгой дорогой по трассе. И кстати он может ехать по трассе все 30 часов подряд, без отдыха, сна, перекусов. А это более эффективное использование грузовика, и более быстрая доставка груза.

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

Конечно это утопия, конечно не будет никакого равенства. И будет у людей страх потерять что-то, не найти работу, и т.д. И мы не знаем, хотят ли люди не работать. И к чему это приведет. И кризис смысла жизни тоже будет. Но то же пособие по безработице в Калифорнии в размере более $1000 позволяет снимать какое-то жилье и покупать продукты этим безработным. И это то, о чем 100 лет назад не мог мечтать никто из рабочего класса. А сейчас это есть и считается «плохо и мало».

Главное, что мне кажется, рост производительности не должен всегда приводить к росту производства, а местами должен приводит к снижению цены. Потому что США и Европе уже не нужно БОЛЬШЕ одежды и обуви. Хорошо бы наоборот уменьшить это количество и снизить нагрузку на природу и экологию.

Но в той же Индии, Бангладеше рост производительности в строительстве приведет к тому, что люди начнут жить в нормальных условиях. Потому что убитая однушка в пятиэтажке в г. Шаховская в Тверской области гораздо лучше, чем то, как жили еще 50 лет назад промышленные районы «благополучной Англии и Франции». Мы быстро привыкли к хорошему)

Так что будет еще лучше)
Ограничение, что нельзя обменять на деньги — фиктивное. Рокетрублями можно компенсировать любую покупку от 3000р и эти деньги вернуться настоящими рублями на ваш счет. Да, сначала надо заплатить рублями, а потом «компенсировать». Но по факту это те же рубли. Баллами спасибо от сбербанка можно заплатить в сотнях магазинов. Не всегда всю сумму, но тем не менее — если мне сейчас выдадут 100 000 баллов спасибо, я буду относиться к ним как с деньгам. И если Amazon выдаст премию сотрудникам в виде баллов, которые можно потратить только в Amazon — это неплохая экономия денег на налогах и комиссиях банков.

Я знаю в РФ не одну крупную компанию, которая выдает премии и подарки в виде подарочных карт своих магазинов.

Ну и почему Зимбабве с ВВП в $16млрд/год может иметь свою валюту, а Apple у которых $250 млрд в оффшорах нет? Или Alibaba которая сделала оборот $25 млрд за сутки на своей распродаже?

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

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

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

Вот тогда была бы интересная статья, а необоснованная критика.
А если ты разраб, то уточнять детали, чтобы потом не переделывать)
4 года я был аналитиком и руководителем проектов.
И я считал свои ТЗ отличными и понятными. Я правда над этим много работал. Например, мне однажды попадалась подробная анкета на верстку от топового фрилансера на fl.ru, с 500+ положительными отзывами. Анкета состояла из 30+ пунктов поверх очень хороших макетов. Я из нее взял пунктов 10, и стал использовать на всех этапах, от ТЗ до приемки.

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

Например в ТЗ есть форма регистрации на 5 полей
99% ТЗ содержат перечень полей:
*Имя
*Email
День рождения
Телефон
Комментарий
Город

И поставив звездочки около имени и email заказчик, считает, что уже достаточно описал форму. И если есть moqups или дизайн формы — то вообще какие тут могут быть еще вопросы. А так как в его «сайте/портале/CRM/ERP...» таких форм десятки, а страниц десятки типов, то ТЗ уже и так на 50-100 страниц. А значит достаточно подробное)

Что же мы забыли
  • Валидации полей на типы
  • Валидации полей на лимиты (вряд ли 1800 год рождения — нормально)
  • Валидации полей на уникальность (ну это же очевидно)
  • Где проходит эта самая валидация(на сервере, или в браузере; понятно, что уникальность email мы не можем проверить в браузере, а вот желание проверять валидность и обязательность полей в браузере хорошо бы указать)
  • Ошибки валидации (и даже если попросить их указать, вряд ли вы увидите две разные ошибки на невалидный email и уже существующий)
  • А еще мы забыли уведомления на email, подтверждения телефона, восстановление пароля, авторизацию через соцсети и т.д. И каждый из этих пунктов — это формы, валидации, проверки, тексты ошибок, редиректы после успеха и неуспеха
  • А еще самый коварный вопрос: при авторизации через соцсети, если пользователя с таким email нет, то отказывать в авторизации или создавать нового пользователя? А письмо ему на email в этом случае надо отправлять или нет?


99% заказчиков и 95% аналитиков неспособны на таком уровне проработать ТЗ
Заказчики не могут, потому что не понимают уровень детализации, и у них нет времени, а аналитики, потому что чаще всего это просто вчерашние секретари/секретарши, помощники/помощницы. Которые внезапно для себя делают сайт/портал и теперь пишут к нему ТЗ. Как умеют.

Какие из всего этого я сделал выводы для себя?
Неважно какую роль я играю: аналитик, заказчик, программист, руководитель проекта — если я вижу, что ТЗ содержит тонны подводных камней, я сажусь и вместе в диалоге его прорабатываю. Как с тем, кто является для меня заказчиком, так и с тем, кто является для меня исполнителем.
Нет никакого смысла отправлять заказчика доделывать ТЗ, со словами «ТЗ мутное». Он не будет его доделывать, а просто найдет того, кто будет с таким работать. Наступит на все грабли, и справедливо будет считать всех программистов козлами. А ведь у него был шанс, поработать с хорошим программистом, который поможет сделать ТЗ не мутным.
Также нет никакого смысла отдавать все на откуп разработчикам с мыслями: «Форма регистрации, табличка отзывов, страница профиля — это же так стандартно. Что тут может быть непонятно.» Разработчик в 99% сделает как он делал в прошлом проекте, или как принято в его стеке технологий, или как ему проще и нравится. Его «нравится» редко когда совпадает с чувством прекрасного у заказчика.
И нет никакого смысла вылизать сразу все ТЗ на 3ё500 страниц.

Мой рецепт:
  • Разбить проекты на части
  • Выбрать 1 часть. В начале желательно важную для проекта
  • Детально описать
  • Сделать 50%. Задать появившиеся вопросы
  • Доделать, показать, получить правки, доделать
  • Взять следующую часть

А еще очень важен постоянный диалог в стиле:
«Мы разбили проект/задачу на 7 частей. Первая часть займет неделю. Мы подготовили вопросы по ней. Сейчас проговорим детали.… (после того, как проговорили детали) Дня через три мы придем с новой порцией вопросов по первой части. А в начале следующей недели так же будем прорабатывать часть 2, подготовьте свои соображения, мы подготовим наши вопросы». И опять же это касается любого участника процесса: как заказчика, так и руководителя проекта, и тимлида, и разработчика, и дизайнера, и даже верстальщика.

Известно, что энтропия (в данном случае мера бардака в проекте) сама увеличивается, если не прикладывать осознанных усилий к её уменьшению. Так что помогают только осознанные усилия, диалоги, контроль, согласования, умелое отстаивание уже утвержденного, выкидывание лишнего. И только, если все это для уменьшения энтропии, а не снятия отвественности и оставления для себя свободы деталий и вариантов «нагнуть другую сторону»
А reconomica взяла эти данные moscow.gks.ru/wps/wcm/connect/rosstat_ts/moscow/ru/statistics/standards_of_life и просто предоставила часть данных в более удобном виде для чтения в браузере.

Да, это просто новостной сайт с десятком тысяч посетителей в месяц, но удобно представивший данные с Мосгорстат. Так что ни Яндекс, ни reconomica.ru, ни я не вводили никого в заблуждение) А вот зачем вам надо плохо отзываться об этом сайте — не понятно.
Хорошая статья, единственное, что смутило:
Мерой успеха собеседования была нижняя планка заработной платы 60 тыс. р. — как удвоенная средняя зарплата по Москве.

По запросу средняя зарплата в москве в 2017 году Яндекс выдает 67899.

Поэтому получилась не «удвоенная средняя зарплата по Москве», а «88% от средней зарплаты по Москве». Две средние ЗП по Москве — это 135 000р, и это совсем другие условия и требования.
Cогласен на все 100%. Похоже такая адекватность появляется благодаря опыту «с обоих сторон баррикад».
digore — на моей практике сотрудники, которые уходят из компании, при наличии нормальной ЗП — идут на новые задачи и технологии, с повышением ЗП, но одного повышения ЗП мало. И молчат не потому, что боятся, или не знают как попросить больше денег, а потому что понимают, что их стек/требования и стек/возможноти текущей компании расходится.

Примеры из практики:
— Программист был backend разрабом, прокачался во фронте, хочет быть fullstack разработчиком, решать более широкие задачи. А в текущей компании нет для него должности. Отдельно backend, отдельно frontend и руководство + teamlead отстаивает такое решение. Программист уходит. В сервис с нагрузкой в 50 раз больше текущего. С повышением ЗП.

— Другой программист отлично работал backend разрабом на Ruby, заботал Go, хочет идти в системное программирование. В текущей компании нет ни GO, ни таких нагрузок, ни компетенций. Уходит. В компанию в разы больше по количеству сотрудников, и в тысячи раз больше по нагрузке. С повышением ЗП.

— Другой PHP программист работал в интернет-магазине. Отлично пилил сайт на Битриксе. Вырос из Битрикса. Понял, что хочет использовать MVC-frameworks или делать REST-API, или юзать на фронте что-то из React/Angular/VueJS. Уходит из интернет-магазина в студию, занимающуюся заказной разработкой. С повышением ЗП.

Таких историй на моей практике десятки. Что объединяет эти истории — так это то, что разработчик развивается. Развивается, как в плане нагрузок, так и в плане технологий.
Вырастает из компании и уходит дальше. Приходит в таком случае к менеджеру — мне кажется глупо. Менеджер хочет расширить «зону отвественности», а разработчик хочет расширить/изменить стек технологий и повысить нагрузку своих проектов.

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

P.S. все выше-сказанное не касается компаний вроде Яндекс, Google, Facebook, Booking, VK, Avito и подобных по размеру и нагрузкам.

Information

Rating
6,251-st
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity