тезисы мифа о накрутках: 1. статьи накручиваются...2. ...чтобы попасть в топ‑20 за сутки…3. ...где их увидит значительное количество читателей.
Топ-20 за сутки мало что даст, вы правы.
Многие читатели используют фильтр по рейтингу +10, +25, +50. Сам так делаю. Статьи ниже +25 почти не читаю. Поэтому достижение этих значений рейтинга резко повышает приток читателей.
Под спойлером можно увидеть пример, как +10, +25 или +50 сильно меняют тенденцию к просмотрам.
Пример графика просмотров
Видно, что падение просмотров по замедлилось на +10, потом на +25 просмотры со временем стали только расти. Рост был остановлен наступлением ночи. Утром рост продолжился. А потом на +50 статья получила вообще взрывной рост популярности. Который потом после пика пошел на спад.
Это частный пример, могу ошибаться.
Но уверен, многие разделяют мнение: дорос до +25 в течении суток - статья удалась. Дальше она будет раскручивать сама себя.
Поэтому у некоторых не особо честных авторов может возникнуть искушение накрутить статью на старте. Понятно, что плохую статью невозможно вывести накруткой в топ. Её все равно утопят. Но забустить годную статью, вероятно, возможно. Только вот понять, что статью забустили - тяжело, в этом я с вами согласен.
Я понимаю, что на старте всегда проще собрать минусы, чем поддержку
Понимаю, выглядит так, что на новичков слетелась стая и заклевала. Но это не так. Тут прилетает всем, невзирая на личности.
Не могу говорить за сообщество. Но могу показать, что резануло лично меня.
Общий посыл "щас я вам расскажу как надо качать бренд и какие у меня крутые клиенты"
Еще раз, это мое личное впечатление. Оно субъективное, но почему-то кажется. но не только я так чувствую.
После этого включается механизм критики. И хочется пройтись катком, и под микроскопом рассмотреть каждое несоответствие.
1) "Но когда ты уже senior, CTO или фаундер — код больше не говорит за тебя. "
а) Так сеньор или фаундер? Это две большие разницы. Звучит как "это когда ты уже оператор ЧПУ, директор или космонавт". Вызывает вопросы, а насколько вы изучили, что делают синьоры или фаундеры? Выглядит как "публикация черновика мысли"
б) Как раз за синьора говорит код, архитектура и многое другое.
2) "Если вы твердо решили всю карьеру тихо пилить код, не интересуясь ростом зарплаты"
Текст принижает тех, кто реальный профи в пилении кода. А если хоть немного отследить тренды зп в отрасли, то видно, что разрабы все чаще получают больше PM/PO.
3) "уйти от сарафана и начать брать клиентов с открытого рынка"
а) Зачем уходить от сарафана? большинство работу ищут либо по сарафану, либо тупо с улицы.
б) Каких клиентов? Люди работу работают на работе. Ищут работодателей а не клиентов.
4) "Тимлида или CTO часто нанимают за счёт репутации"
а) Так тимлида или CTO? Это вообще разное! Опять кажется, что не проведено качественное исследование.
б) Я вот тимлид, и меня почти всегда нанимали с улицы. Прокаченный аккаунт на Хабре никого не интересовал, пока я не проходил собес. То есть тезис явно спорный.
5) "Не бойтесь публиковать черновики мысли — это не LinkedIn".
а) Призыв тащить черновики сразу выводит людей из себя. И так есть масса проблем (тот же пресловутый ЖПТ), а вы призываете все усугубить. Публиковать надо четко выверенные, тщательно проверенные тексты.
б) Противопоставлять занятие рисковое, тем более таким способом. Представьте что вы противопоставляете айфон и андроид. Вас запинают адепты и того, и другого.
6) Подход следующей клиентки к личному бренду звучал так: «помоги мне хотя бы лежать в направлении него». Девушка — топ-менеджер в крупной IT-компании в США
Может быть, это так и есть. Но звучит как инфо-цыганство. Мол, том-менеджеры (и не простые, а американские) упрашивают меня хотя о консультации.
Такая, знаете, серьезная претензия. как в этом, так и в других кейсах. Уши рекламы "купи-купи у меня продвижение бренда" так и торчат из каждого абзаца.
Но вы правы, это не LinkedIn, тут такая реклама не катит.
Через токи утечки блока питания (они малые, но они есть) у корпуса компа появляется потенциал.
Через токи утечки прибора на его корпусе тоже появляется потенциал.
Когда прибор подключается к компу – их корпуса соединяются через провод заземления, который может идти внутри кабеля, или может быть соединен с защитной оплеткой кабеля.
Между корпусами начинает течь ток, и этот ток частично может пойти на материнскую и другие плат внутри компа. Этого может хватить чтобы сжечь платы.
PS. Смысл такой. Кто разбирается в схемотехнике, поправьте, если я ошибся.
а то у меня в доме розетки от 3х фаз и ничего не горит
Постарайтесь не подключать в эти розетки связанные приборы, например системный блок и монитор.
Даже если приборы не связаны, нельзя одновременно к ним прикасаться. Иначе проводом, выравнивающим потенциалы их корпусов, станете вы.
А как исправить эту ошибку? Как потратить ещё меньше денег на производство статьи?
У меня есть два ответа. Хороший и плохой. Начну с плохого:
Извините, конечно, а почему меня как читателя должно волновать желание компании экономить на статьях? Нет денег - не пишите. Другие напишут.
Теперь хороший.
А вы заинтересуйте своих сотрудников нематериально, чтобы они добровольно и с песней писали статьи. Я вот (не хвастаюсь, просто излагаю факты) пишу совершенно бесплатно, потому что мне по кайфу.
Человек, которого наймут на эту должность, будет каждую неделю выпускать 8 газетных полос с текстами нейтросетки
Лучше одна добротная статья чем 8 никудышных. В том числе и экономически.
Был такой забавный мультик, когда жадный богач захотел семь шапок из одного куска
На практике работодатель зарабатывает все то, что не доплатил работнику. Поэтому в ход идет все что угодно, чтобы увеличить разницу между прибылью и затратами.
А еще на практике работодатель это не человек, это организация с своими не всегда логичными правилами. Например, бюджет на найм - один, а на повышения - другой, и сильно ограниченный. И начальнику бывает проще не дать повышения, человек уйдет, а потом нанять на еще бОльшие деньги с рынка. Потому что повышение сотрудника ему не согласуют. А найм по причине замены - другая история.
10 разработчиков, несколько проектов, 20% времени на управление, остальное — код, пресейлы, обучение и личные цели. Звучит как типичный день teamlead’а, правда?
Нет, не звучит.
Извините, но так просто не бывает. С 10-ю разработчиками времени писать код не будет. Максимум- ревью, и то не всего. Времени на обучение людей тоже не хватит. Учитывая что вам еще пресейлами надо заниматься.
20% на управление? На пообщаться с разрабами, со стейками, чего-то там запланировать, задачек там нарезать, поставить, проконтролировать выполнение. Так не бывает. 70% на управление - норм. 50% - ну.... если у вас есть пара синьоров на которых вы делегируете половину своей работы. И скорее всего это не ваш случай, т.к. вы описываете себя как единую входную точку.
Мне нравится принцип "ты мне, я - тебе". Пришлось переработать - ок. Но потом если днем надо куда-то отойти - то я так и делаю. И ни у кого никаких вопросов.
Обычно мне удается договориться. Хотя не всегда.
Была у меня недавно одна продакт, которая закатила истерику по поводу того, что в 12-30 я не был на рабочем месте. Я эскалировал выше, и сказал: хотите формализма? ОК. Буду работать строго 9-18 с перерывом в 13. Но учтите, что теперь продукт не будет обновляться в принципе, потому что в релизное окно (которое согласовано только для нерабочих часов) я работать не буду. Ну или откатываем ситуацию, забываем этот скандал, и все будет как раньше, неформально, с гибкими рабочими часами.
Однажды он даже отчитал меня за «слишком долгий» обеденный перерыв, который длился 62 минуты вместо положенных 60
При малейшем опоздании (даже на 2 минуты) он писал мне сообщение: «Где ты? Почему не на работе?»
Может существовать в одной вселенной с этим:
Я всё чаще стал задерживаться допоздна, работать по выходным, но результат всё равно не устраивал Александра
Если у нас гибкий график, и приходится сидеть по вечерам, то та же логика касается, скажем, обедов.
Если обед четко 60 минут и ни минутой больше, значит, 18:01 комп гастится, на рабочие телефонные звонки и на сообщения в мессенджере ответ будет завтра не ранее 09:00
Если уж решил колоться но продолжать есть кактус, то в эту корпоративную игру можно играть вдвоем.
Обновил статью, приведя конкретный пример из жизни.
Мой позиция в том, что массовое АйТи - это не про соцсети. В соцсетях все очень классно работает с микро-сервисами и микро-фронтами. Классно, но абсолютно бесполезно для 99%+ разработчиков. Потому что 99% разработчиков в РФ в аджайл-командах такими вещами не занимаются. Хорошо это или плохо, они пишут что-то под локальные потребности бизнеса. И это что-то выполняет конкретную бизнес-задачу. Оно является либо частью системы, либо очень маленькой системой. В обоих случаях еще мельче дробить это "что-то" редко бывает целесообразно. Нагрузка на это "что-то" маленькая, людей выделяют мало.
А канонические примеры (тот же Амазон, или запрещенный Фейсбук) - это десятки тыщ инженеров. Там только над управлением профиля работают такие толпы, что их приходится делить на отделы и выдавать им крохотный кусочек функционала.
Прощу прощения, возможно, у меня плохо получается выразить простую мысль:
Многие смотрят на подходы тех же соцсетей или Нетфликса, и пытаются применить у себя на работе. Например, пытаются сделать какой-то генератор отчетов в виде десятка сервисов. Задача была на три месяца на одного разработчика и половину тестировщика, а превращается на три месяца на двух разработчиков, тестировщика и девопса.
Я так и не понял, где в статье описывается что всё-таки такое нано сервис
Исправляюсь!
Дано: написать сервис, который берет из бэк-офиса данные о продажах и отправляет операторам электронных касс. Операторы печатают электронные чеки. Пример оператора: Атол (не реклама)
Из-за очень настойчивого мнения руководителя (на прошлой работе) принято решение писать на "микро-сервисах". Микро-сервис "Ядра", преобразующий данные бэк-офиса в нужный формат и балансирующий нагрузку между микро-сервисами адаптеров к операторам.
Теория:
Модно и молодежно. Это же "микро-сервисы"
Максимальная гибкость: можно подключать и отключать операторов без даунтайма ядра.
Масштабируемость
Разные сервисы можно раскидать по разным разрабам
Практика:
Х2 трудозатрат на реализацию. Потому что оверхед на взаимодействие между сервисами, трейсинг и т.д.
Х3 затрат на поддержку. Потому что вместо одного "монолита" получили ряд нано-сервисов. С алертингом, мониторингом, трейсингом, логами. И разбором инцидентов от бухгалтерии вида: "вы опять чек пролюбили"
Полное отсутствие необходимости горизонтального масштабирования. В пике оно кушало пару сотен мб оперативки и 10% ядра процессора. Узкое место - скорость онлайн касс, а не сервисов.
Все заняло у меня 5 недель на разработку и 2 недели на ОПЭ. Привлекать команду для такого микро-проекта избыточно. Более того, в виде одного сервиса реализация была бы в 1.5 раза быстрее.
Вывод: получились нано-сервисы с завышенной стоимостью владения.
Не надо так делать.
Правильно было бы сделать в виде одного микро-сервиса, со своим доменом: печать чеков.
Из-за таких вот определений мир наполнили нано-сервисы: рой сильно-связанных сервисов, которые никак не ложатся ни на домен, ни на орг. структуру.
Приходишь в компанию, а там 30 команд пилят 1500 сервисов. Да еще гордятся этим. Чтобы хоть как-то начать в этом ориентироваться, надо потратить полгода и километр нервов.
Топ-20 за сутки мало что даст, вы правы.
Многие читатели используют фильтр по рейтингу +10, +25, +50. Сам так делаю. Статьи ниже +25 почти не читаю. Поэтому достижение этих значений рейтинга резко повышает приток читателей.
Под спойлером можно увидеть пример, как +10, +25 или +50 сильно меняют тенденцию к просмотрам.
Пример графика просмотров
Видно, что падение просмотров по замедлилось на +10, потом на +25 просмотры со временем стали только расти. Рост был остановлен наступлением ночи. Утром рост продолжился. А потом на +50 статья получила вообще взрывной рост популярности. Который потом после пика пошел на спад.
Это частный пример, могу ошибаться.
Но уверен, многие разделяют мнение: дорос до +25 в течении суток - статья удалась. Дальше она будет раскручивать сама себя.
Поэтому у некоторых не особо честных авторов может возникнуть искушение накрутить статью на старте. Понятно, что плохую статью невозможно вывести накруткой в топ. Её все равно утопят. Но забустить годную статью, вероятно, возможно. Только вот понять, что статью забустили - тяжело, в этом я с вами согласен.
Понимаю, выглядит так, что на новичков слетелась стая и заклевала. Но это не так. Тут прилетает всем, невзирая на личности.
Не могу говорить за сообщество. Но могу показать, что резануло лично меня.
Общий посыл "щас я вам расскажу как надо качать бренд и какие у меня крутые клиенты"
Еще раз, это мое личное впечатление. Оно субъективное, но почему-то кажется. но не только я так чувствую.
После этого включается механизм критики. И хочется пройтись катком, и под микроскопом рассмотреть каждое несоответствие.
1) "Но когда ты уже senior, CTO или фаундер — код больше не говорит за тебя. "
а) Так сеньор или фаундер? Это две большие разницы. Звучит как "это когда ты уже оператор ЧПУ, директор или космонавт". Вызывает вопросы, а насколько вы изучили, что делают синьоры или фаундеры? Выглядит как "публикация черновика мысли"
б) Как раз за синьора говорит код, архитектура и многое другое.
2) "Если вы твердо решили всю карьеру тихо пилить код, не интересуясь ростом зарплаты"
Текст принижает тех, кто реальный профи в пилении кода. А если хоть немного отследить тренды зп в отрасли, то видно, что разрабы все чаще получают больше PM/PO.
3) "уйти от сарафана и начать брать клиентов с открытого рынка"
а) Зачем уходить от сарафана? большинство работу ищут либо по сарафану, либо тупо с улицы.
б) Каких клиентов? Люди работу работают на работе. Ищут работодателей а не клиентов.
4) "Тимлида или CTO часто нанимают за счёт репутации"
а) Так тимлида или CTO? Это вообще разное! Опять кажется, что не проведено качественное исследование.
б) Я вот тимлид, и меня почти всегда нанимали с улицы. Прокаченный аккаунт на Хабре никого не интересовал, пока я не проходил собес. То есть тезис явно спорный.
5) "Не бойтесь публиковать черновики мысли — это не LinkedIn".
а) Призыв тащить черновики сразу выводит людей из себя. И так есть масса проблем (тот же пресловутый ЖПТ), а вы призываете все усугубить. Публиковать надо четко выверенные, тщательно проверенные тексты.
б) Противопоставлять занятие рисковое, тем более таким способом. Представьте что вы противопоставляете айфон и андроид. Вас запинают адепты и того, и другого.
6) Подход следующей клиентки к личному бренду звучал так: «помоги мне хотя бы лежать в направлении него». Девушка — топ-менеджер в крупной IT-компании в США
Может быть, это так и есть. Но звучит как инфо-цыганство. Мол, том-менеджеры (и не простые, а американские) упрашивают меня хотя о консультации.
Такая, знаете, серьезная претензия. как в этом, так и в других кейсах. Уши рекламы "купи-купи у меня продвижение бренда" так и торчат из каждого абзаца.
Но вы правы, это не LinkedIn, тут такая реклама не катит.
Вы в первой же статье всерьез даете советы что и как писать на Хабр, не имея в этом никакого опыта.
С личным брендом на Хабре у вас не задалось, сами видите. А если вы не можете построить свой бренд, как вы можете давать советы другим?
Без обид, но вся статья звучит как "Fake it till you make it"
Через токи утечки блока питания (они малые, но они есть) у корпуса компа появляется потенциал.
Через токи утечки прибора на его корпусе тоже появляется потенциал.
Когда прибор подключается к компу – их корпуса соединяются через провод заземления, который может идти внутри кабеля, или может быть соединен с защитной оплеткой кабеля.
Между корпусами начинает течь ток, и этот ток частично может пойти на материнскую и другие плат внутри компа. Этого может хватить чтобы сжечь платы.
PS. Смысл такой. Кто разбирается в схемотехнике, поправьте, если я ошибся.
Постарайтесь не подключать в эти розетки связанные приборы, например системный блок и монитор.
Даже если приборы не связаны, нельзя одновременно к ним прикасаться. Иначе проводом, выравнивающим потенциалы их корпусов, станете вы.
У меня есть два ответа. Хороший и плохой. Начну с плохого:
Извините, конечно, а почему меня как читателя должно волновать желание компании экономить на статьях? Нет денег - не пишите. Другие напишут.
Теперь хороший.
А вы заинтересуйте своих сотрудников нематериально, чтобы они добровольно и с песней писали статьи. Я вот (не хвастаюсь, просто излагаю факты) пишу совершенно бесплатно, потому что мне по кайфу.
Лучше одна добротная статья чем 8 никудышных. В том числе и экономически.
Был такой забавный мультик, когда жадный богач захотел семь шапок из одного куска
Пора НЛО добавить еще один пункт "Сгенерировано нейросетью" в окошко
"Укажите причину минуса, чтобы автор поработал над ошибками"
В теории все очень красиво.
На практике работодатель зарабатывает все то, что не доплатил работнику. Поэтому в ход идет все что угодно, чтобы увеличить разницу между прибылью и затратами.
А еще на практике работодатель это не человек, это организация с своими не всегда логичными правилами. Например, бюджет на найм - один, а на повышения - другой, и сильно ограниченный. И начальнику бывает проще не дать повышения, человек уйдет, а потом нанять на еще бОльшие деньги с рынка. Потому что повышение сотрудника ему не согласуют. А найм по причине замены - другая история.
А чем вас эта не устраивает: "Cracking the coding interview"?
Очевидно же! Будет другой интервьюер.
Нет, не звучит.
Извините, но так просто не бывает. С 10-ю разработчиками времени писать код не будет. Максимум- ревью, и то не всего. Времени на обучение людей тоже не хватит. Учитывая что вам еще пресейлами надо заниматься.
20% на управление? На пообщаться с разрабами, со стейками, чего-то там запланировать, задачек там нарезать, поставить, проконтролировать выполнение. Так не бывает. 70% на управление - норм. 50% - ну.... если у вас есть пара синьоров на которых вы делегируете половину своей работы. И скорее всего это не ваш случай, т.к. вы описываете себя как единую входную точку.
А вот если взглянуть на восточную рекламу (корейская, японская , китайская) - там все наоборот.
Так что эти выводы неверны как минимум для половины населения Земли
Аналогично, коллега )
Нас развели по классике:
Ну вот, кто везет - на том и едут.
Мне нравится принцип "ты мне, я - тебе". Пришлось переработать - ок. Но потом если днем надо куда-то отойти - то я так и делаю. И ни у кого никаких вопросов.
Обычно мне удается договориться. Хотя не всегда.
Была у меня недавно одна продакт, которая закатила истерику по поводу того, что в 12-30 я не был на рабочем месте. Я эскалировал выше, и сказал: хотите формализма? ОК. Буду работать строго 9-18 с перерывом в 13. Но учтите, что теперь продукт не будет обновляться в принципе, потому что в релизное окно (которое согласовано только для нерабочих часов) я работать не буду. Ну или откатываем ситуацию, забываем этот скандал, и все будет как раньше, неформально, с гибкими рабочими часами.
Начальство выбрало второй вариант ))
Непонятно, как вот это:
Может существовать в одной вселенной с этим:
Если у нас гибкий график, и приходится сидеть по вечерам, то та же логика касается, скажем, обедов.
Если обед четко 60 минут и ни минутой больше, значит, 18:01 комп гастится, на рабочие телефонные звонки и на сообщения в мессенджере ответ будет завтра не ранее 09:00
Если уж решил колоться но продолжать есть кактус, то в эту корпоративную игру можно играть вдвоем.
Кажется, в начале статьи нет определения кто же такой тех лид и чем он конкретно занимается.
А раз нет границ зон ответственности, то и возникают казусы вроде прибегающих дизайнеров.
Ничего кроме правды - это тоже может быть сильный ход.
Вот как я первый раз устроился тимлидом:
На обесе рассказал, что работал синьором, ставил задачи двум коллегам, контролировал, собирал результаты их труда вместе, релизил.
Интервьюер спосил: а, так ты управлял?
Я говорю не, у них же другой начальник. Я просто синьор, я отвечал за кусок системы.
Интервьюер: а, так ты еще и скромный. А у нас тут позиция лида тоже имеется. Хочешь?
Обновил статью, приведя конкретный пример из жизни.
Мой позиция в том, что массовое АйТи - это не про соцсети. В соцсетях все очень классно работает с микро-сервисами и микро-фронтами. Классно, но абсолютно бесполезно для 99%+ разработчиков. Потому что 99% разработчиков в РФ в аджайл-командах такими вещами не занимаются. Хорошо это или плохо, они пишут что-то под локальные потребности бизнеса. И это что-то выполняет конкретную бизнес-задачу. Оно является либо частью системы, либо очень маленькой системой. В обоих случаях еще мельче дробить это "что-то" редко бывает целесообразно. Нагрузка на это "что-то" маленькая, людей выделяют мало.
А канонические примеры (тот же Амазон, или запрещенный Фейсбук) - это десятки тыщ инженеров. Там только над управлением профиля работают такие толпы, что их приходится делить на отделы и выдавать им крохотный кусочек функционала.
Прощу прощения, возможно, у меня плохо получается выразить простую мысль:
Многие смотрят на подходы тех же соцсетей или Нетфликса, и пытаются применить у себя на работе. Например, пытаются сделать какой-то генератор отчетов в виде десятка сервисов. Задача была на три месяца на одного разработчика и половину тестировщика, а превращается на три месяца на двух разработчиков, тестировщика и девопса.
Исправляюсь!
Дано: написать сервис, который берет из бэк-офиса данные о продажах и отправляет операторам электронных касс. Операторы печатают электронные чеки. Пример оператора: Атол (не реклама)
Из-за очень настойчивого мнения руководителя (на прошлой работе) принято решение писать на "микро-сервисах". Микро-сервис "Ядра", преобразующий данные бэк-офиса в нужный формат и балансирующий нагрузку между микро-сервисами адаптеров к операторам.
Теория:
Модно и молодежно. Это же "микро-сервисы"
Максимальная гибкость: можно подключать и отключать операторов без даунтайма ядра.
Масштабируемость
Разные сервисы можно раскидать по разным разрабам
Практика:
Х2 трудозатрат на реализацию. Потому что оверхед на взаимодействие между сервисами, трейсинг и т.д.
Х3 затрат на поддержку. Потому что вместо одного "монолита" получили ряд нано-сервисов. С алертингом, мониторингом, трейсингом, логами. И разбором инцидентов от бухгалтерии вида: "вы опять чек пролюбили"
Полное отсутствие необходимости горизонтального масштабирования. В пике оно кушало пару сотен мб оперативки и 10% ядра процессора. Узкое место - скорость онлайн касс, а не сервисов.
Все заняло у меня 5 недель на разработку и 2 недели на ОПЭ. Привлекать команду для такого микро-проекта избыточно. Более того, в виде одного сервиса реализация была бы в 1.5 раза быстрее.
Вывод: получились нано-сервисы с завышенной стоимостью владения.
Не надо так делать.
Правильно было бы сделать в виде одного микро-сервиса, со своим доменом: печать чеков.
Мне этот жанр тоже нравится.
Дальше обычно следует: "что вы знаете про нашу компанию?", "кем вы себя видите [в нашей компании] через 5 лет?"
Из-за таких вот определений мир наполнили нано-сервисы: рой сильно-связанных сервисов, которые никак не ложатся ни на домен, ни на орг. структуру.
Приходишь в компанию, а там 30 команд пилят 1500 сервисов. Да еще гордятся этим. Чтобы хоть как-то начать в этом ориентироваться, надо потратить полгода и километр нервов.