Джоэл Спольски. И снова о программировании

Ссылка на OZON.
Джоэл о программировании — первая книга.
http://joelonsoftware.com/ — блог автора

Джоэл Спольски — известный блоггер. Его посты о программировании набирают тысячи просмотров. Перед чтением первой книги я долго сомневалась. Все-таки это не книга, а просто набор блог-постов. И даже не о тестировании, а в целом о разработке ПО... Но начала... И понравилось! Мне очень приятен слог Джоэла, интересно читать. После первой книги с удовольствием утащила из рабочей библиотеки вторую.

Автор —разработчик с большим опытом, работал когда-то над Excel, а сейчас у него своя фирма, делают баг-трекер. И вот он делится опытом по самым разным плоскостям работы:

1. Как управлять людьми.
2. Советы будущим и настоящим программистам.
3. Значение проектирования.
4. Управление большими проектами.
5. Как начать свой бизнес в программировании.
6. Как управлять своим бизнесом.

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

• Свой офис — это не мелочь, это очень важно, на это есть отдельная глава у Джоэла. Там он рассказывает, как он дал задачу арзитектору сделать офис месты. И как в простом здании появились офисы с отдельными кабинетами с кучей окон. А снаружи здание как здание. Очень вдохновляюще звучит! Правда, еще важно куда окна выходят, у нас на солнечную сторону и они постоянно закрыты =(
• Удобные кресла — вы думаете, что знаменитый Aeron это дыра в бюджете? А вот и нет, они клевые и практичные, и через 10 лет выглядят как будто новенькие. Поэтому лучше вложить 500 долларов на 10 лет, чем купить дешевую хреноту, которая развалится за пару месяцев.
• Игрушки — «нет никаких причин не купить разработчику лучшие модели компьютеров, больших дисплеев итд». Кстати, да, это правда круто! Когда у меня сдох жесткий диск, мне поставили SSD, я довольна 
• Читайте книгу, чтобы узнать больше =)

Ну разве что еще хочется упомянуть, что привлекает (или, наоборот, сильно отталкивает, если этого нет):

• Независимость.
• Никакой политики.

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

А недавно как раз на форуме Software Testing почитала обсуждения в теме про, казалось бы, выпадающее меню. А там увели в сторону «Я вот знал тестировщика, которого уволили за то, что он написал в баге, как должно быть. Это не его работа». Так грустно становится. Не хочу быть таким бесзмолвным и бесправным созданием, которое стремится к вертикальному росту просто для того, чтобы начать принимать решения. Горизонтальные структуры мне нравятся гораздно больше. Это, кстати, уже в тему бирюзовых организаций (тут будет ссылка на то, что это такое)

Понравились рассуждения о юзабилити. Знаете ли вы, что выбор — это тоже проблема? И когда у компьютера 100500 кнопок выключения (выключить, заснуть, ребутнуть, прикорнуть...) — это плохо! Пользователи пугаются, начинают думать, что им выбирать... То ли дело Apple и ее минималистичные дизайны! И выключать ничего не надо, само в спячку уходит...

Ну и, конечно, юзабилити — не самое главное в продукте. Это как реклама. Любая реклама будет продавать ваш продукт. Классный текст или нет, интересный лендинг или отстой, покупатели все равно найдутся. Также и в программах. Может быть страшненькая и неудобная, но полезная. В итоге все равно ею будут пользоваться (ненавидеть, но пользоваться). А вот если бизнес-идеи нет, то и никакие инвестиции в дизайн уже не помогут.

Джоэл рассказывает и о том, как планировать время на следующую итерацию. Планировать будущее, используя прошлое. В начале главы он пишет о том, что любой разработчик не любит планировать время на выполнение и старается этого избежать, а потом дает советы, как это все подсчитать. О наивный =) Слишком сложные формулы )))) Хотя он там какую-то готовую программу рекламирует, которая типа все сделает за вас. Но вот с чем я согласна — так это с тем, что нужно ввести учет затраченного времени и использовать знание «на что уходит время» для планирования будущих релизов.

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

PS - Добавила книгу в общий список прочитанных мною книг.