К основному контенту

Сообщения

Сообщения за 2019

Про качество, тестирование и консерватизм

Мне тут недавно "прилетело", что я "склонен использовать консервативные подходы в работе с ожидаемым результатом в итоге." Да, чего уж там, похоже на правду. Именно потому, что мне нравится"ожидаемый результат". Ну а раз консерватор, то можно и побрюзжать... "Новшества и инновации" - это, чаще всего, то что благополучно забыли или даже не пытались узнать, и переизобрели заново. Мой брошенный английский блог так и назывался "Все новое - это хорошо забытое старое". В этом плане, из всех "новшеств" касающихся тестирования, меня больше всего волнует ( да-да, все еще волнует ) эта магическая комбинация "QA". Я помню те времена, когда тестировщиков в вакансиях "обзывали" инженерами по тестированию, потом появились QC, сейчас все сплошь QA. Расшифровку теперь все знают, но результат работы при этом не поменялся. Успокаивает, что я не один такой: " Is “QA” too narrow? " А ведь еще в 2010 пис

В гостях у SDCast

Сходил в гости к Константину в его подкаст " SDCast ". Вроде интересная получилась беседа , душевная. Чуть меньше 1.5ч возможностей узнать чуть больше про меня, SEMrush и моем отношении к процессу разработки с точки зрения качества. Ссылки для послушать: Основная  https://sdcast.ksdaemon.ru/2019/07/sdcast-106/ Twitter  https://twitter.com/SDCast_podcast/status/1156646125232885760 VK  https://vk.com/ksdaemon?w=wall6753715_549 FB  https://www.facebook.com/ksdaemon/posts/2462401727171916

Spotify Engineering Culture (Henrik Kniberg 2014)

Просто в закладки, рассказ про внутренние процессы разработки в Spotify на момент 2014 года. Интересно, поменялось у них что-нибудь?  А вот и  ответ 1 , ответ 2 ,   ответ 3 :) 

5 за 5 (история 11) It's all about technical management

1.    Sharing Our Engineering Ladder "Creating an engineering ladder (that is, the job descriptions and levels of an engineering organization) is a daunting task. If you do a half-hearted job, you're likely to cause more problems than you solve." "In addition to the ladder causing problems inside of my team, we were having a hard time evaluating candidates during interviews and determining what level to hire them into. Particularly at the more senior levels, it wasn't clear what the criteria for success really looked like. So, together with my tech leads and engineering managers, we rewrote the ladder to be more specific. It has been very helpful both for the process of reviews and promotion committees as well as for the process of hiring." Я уверен, приведенные в ссылках характеристики коими должен обладать разработчик и менеджер на разных позициях в своей карьере, будут полезными многим. 2.   If Your Boss Could Do Your Job, You’re More Likely to

5 за 5 (история 10)

Давно ничего не писал себе и вам в полезные заметки. А их накопилось. Продолжим цикл, хотя он теперь и не "5 за 5 (дней)". 1.  Статья из 1995 . Сколько времени прошло, а ничего не меняется. Но именно такие мысли я называю классикой и философией промышленной программной разработки: "Задачи условно делятся на три категории — соответственно квалификации. Низшая — ты можешь запрограммировать предложенный кем-то алгоритм. Средняя — по предложенной спецификации функции или программы ты можешь предложить алгоритм ее реализации и запрограммировать его. Высшая — ты можешь предложить способ решения задачи, написать спецификацию программы, ее решающей, и запрограммировать ее." Нет моей самой любимой квалификации: Высочайшая - ты умеешь решить задачу, не написав при этом код. А если еще удается и удалить часть кода - это еще лучше. 2. " Chaos Engineering: the history, principles, and practice " - отличное введение в тему от компании, которая занимается