mishafurman: (Default)
Когда-то покойный Джон Макарти пошутил - помню (в Москве в ~197x) его спросили, что он думает о недавнопоявившемся языке PL-1 (или я путаю и это было чуть позже про ADA?). Он в ответ рассказал анекдот:
"Что такое верблюд? Это лошадь спроектированная комитетом".

Только гораздо позже, в США я почувствовал суть этого "антидемократического" высказывания. Уже не в первый раз я
наблюдаю как американского стиля менеджеры управляющие разработкой программного обеспечения каждый раз, когда имеются разногласии, как что-то нужно сделать, решают их на основании большинства (и громкости) голосов.
С первого взгляда - почему бы и нет, "демократия" определенного вида.
Но в реальности, если в группе нет очевидного технического лидера, то фактически принятые решения часто принимаются каждый раз другим человеком. И - каждое, и не так уж плохо, но они начинают друг с другом противоречить. Или по крайней мере следующее решение закрывает то, что было преимуществами предидущего.
И, в особенности, когда это сочетается с микро-менеджментом, результаты бывают грустные...

(Кстати, я довольно высокого мнения ог PL1 - особенно учитывая, что он был первопроходцем - вместа с IBM-вским внутренним языком PL-S. Про ADA сказать ничего не могу).
mishafurman: (Default)

 Вторая и последняя часть - занятие это меня утомило...

Первое.

Уметь читать. Если Вы читаете на русском языке менее 200 страниц в час, Вы не умеете читать. Этому можно и нужно научиться. А английский нужно довести не менее чем до 100 страниц в час (лучше до уровня русского!).

 

Совершенно ужасно: быстро читать, может, еще вреднее, чем быстро писать – потому что что-то написанное тобой плохо гораздо естественноее осознать и переписать. А вот прочитанное плохо обычно так и остается. Но, главное в обоих случаях – не остается времени думать!

 

 

Второе.

Интересоваться всем вокруг, даже тем, что кажется пока что ненужным. Лишь бы это было интересным и будило мысль. Никто не знает, откуда Вам прилетит следующая проблема.

 

Это полезно всегда – и вне зависимости от проблем. Люди любопытные и любящие учиться всегда имеют преимущества перед ленивыми или слишком практичными – вероятно, во всех творческих областях. Вот только, к сожалению, управлять этим в себе трудно, если вообще возможно.

 

Третье.

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

 

Это на мой взгляд пустые слова. Это часто называют «талантом» - и я сомневаюсь, что это можно приобрести после рождения.

 

Четвертое.

Помнить, что здесь остановиться значит деградировать. Чтобы стоять на месте, придется всю жизнь бежать, а чтобы попасть в другое место --- бежать вдвое быстрее. Зато жизнь будет жизнью, а не существованием.

 

Абсолютная чушь. Точнее – есть такой взгляд на жизнь – нахватать как можно больше пока жив. Он мне персонально несимпатичен, но по видимому это никак не корелирует ни с талантом, ни с успехами. И уж точно, к программированию отношения не имеет.

 

Наступает черед второго выбора.

 

Да нет здесь никакого выбора.

Идти приходится на работу туду, куда возьмут; выбор часто невелик – особенно в начале карьеры.

 

Вы хотите, чтобы вами руководили.

В этом ничего плохого нет. 95% людей на самом деле теряются, когда вынуждены руководить сами собой, сами принимать решения. Тогда идите в фирму. Но выбор фирмы согласуйте со своими ответами на два других вопроса.

Вы хотите сами принимать решения.

Идите в свободный софт. Для чистого программиста это практически единственный шанс набрать такую квалификацию, которая позволит ему оставаться полезным до конца жизни. На фирме вы очень быстро деградируете, если вы просто программист, даже старший. Или же опять-таки становитесь аналитиками, а потом будьте независимыми консультантами. Или создавайте собственную команду (все равно, фирму или объединение фрилансеров).

 

Что это такое – свободный софт? Занятие для богатых, которые не нуждаются в зарплате?

«Создайте собственную команду» - чтобы быть успешным нужно сочетание таланта данного от Бога и массы случайных обстоятельств. И при этом в 99% слусаев это значит заниматься неинтересными, но хорошо продаваемыми на рынке вещами.

Такого выбора практически нет, а если бы он был, я бы от него людей предостерегал.

 

Все – дальше не так подробно – про советы, что учить.

 

1.      Общая культура – я бы тоже советывал: люблю культурных людей, да и сам от недостатка общего образования нередко страдаю. Но к программированию это никакого отношения не имеет.

2.      Скорочтение и скорописание – очень вредно.

3.      Математика. Очень нужно некоторое представление о математике – скажем классический курс матанализа с доказательствами (часть из которых сделаны самим студентом) невероятно ценен. Пожалуй, логика. Причем по всей вероятности, непостредственно для будущей работы не нужен.
И – некоторые разделы, скорее всего нужные или полезные непосредственно – скажем, теория графов.

4.      Иностранный язык – нужен, но просто для жизни – для программирования достаточно очень примитивного английского.

 

 

Насчет рассуждения об удаче или ловушке – это опять детский сад. Что является для человека удачей, а что ловушкой – вопрос выходящий далеко за пределы обсуждения. Да и нередко меняется это в течении жизни не раз...

 

 


mishafurman: (Default)
Сама статья здесь http://files.mail.ru/BSAT81

Первая часть замечаний: (Текст статьи - черным, мои комментарии красным)

Программирование и вообще информатика сейчас являются мощными аттракторами – такими же, как атомный проект и физика полвека назад. Я устроился работать в банке программистом – хорошо это или плохо? Денег платят больше чем за измерения мезонов, но, по большому счету (а мы будем рассуждать в этом режиме), я учу там банкиров кликать мышкой. Тогда стоит подумать над такими вопросами всем, кто занимается информатикой и не только:

1.      Что я хочу – программировать или решать задачи?

2.      Хочу я быть в подчинении у других или быть независимым?

3.      Что я буду делать через 10 лет, когда уже не смогу так быстро кодировать, придут ребята помоложе и пошустрее, а жизнь еще вся впереди?

 

Вопросы, на мой взгляд, совершенно детские. №1 вообще не понятен – что такое программирование не связанное с решением задач? Аналогия – просто пересыпать песочек или строить замки... Что-то «взрослых» примеров я придумать не могу.

Конечно бывает просто удовольствие «играться» с компьютером – как скажем бывает удовольствие водить машину или возиться с животными... Но, если говорить о профессии (то есть, чтобы зарплату платили) – набо все-же быть или таксистом или ветеринаром...

№2 - вообще не о профессии, а о роде деятельности, что ли. Вопрос быть ли наемным работником или вольным контрактором-бизнесменом стоит независимо от профессии. Но "независимых" программистов мало: на что-то жить надо, а придумывать программы, чтобы потом их можно было успешно продавать почти невозможно...

№3 - ниже. 

 


Ребята, которых учат по стандартным программам, радуются, что могут быстро кодировать. Особенно это развито у их элиты: олимпиадников ACM. Само по себе такое умение очень хорошо.

 

Умение – вернее привычка - быстро писать программный код, на мой взгляд, плохо (и – объективно – почти никогда не полезно). Плохо – потому, что:

- остается мало времени подумать

- создаются длинные программы, что плохо по многим параметрам.

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

 

Но любое умение может вести либо к развитию в жизни, либо в жизненный тупик. Авторы встречали немало умных парней, которые примерно в 30 лет понимали вдруг, что как кодеры они уступают молодому поколению, которое и пишет быстрее, и новыми инструментальными средствами владеет. И многие из них, те, кто заранее не позаботился о широте своего образования и своей квалификации, начинали просто опускаться и спиваться.

Конечно, есть кодеры высочайшего класса, которые востребованы даже в 63 года. Например, Михаил Фурман, будучи уволен из Yahoo, немедленно был взят в Майкрософт.

 

Уже упоминал, что персонально про меня это неправда (про Yahoo и Microsoft).

Но еще важнее – даже если оставить скорость (которая важна только в спорте, да и то не любом), соображения про возраст относятся к любым творческим профессиям, да и не только творческим.

И, действительно, постоянно учиться – это единственный радикальный выход. Или – менять профессию – как правило это значит, становиться начальником. Или учителем.

И снова мне не нравится слово кодер. Это как скажем рассуждая о профессии писаталя (любого вида) придавать значение скорости писания или печатания. Кстати, аналогия весьма точная.

 

Но он умеет писать системы на голой машине, у него за спиной легендарная школа команды Кронрода и Арлазарова.

 

Не писал на голой машине уже лет пятнадцать. Хотя скажу, некоторая прелесть в этом есть. Также не водил автомобиля без автоматической трансмиссии лет 20. Аналогия, может, в данном случае не так и полна, но есть.

 


mishafurman: (Default)

Утверждение “premature optimization is the root of all evil in programming” цитируемое Кнутом и приписываемое Хоару пример того, что было сформулировано Тютчевым «Мысль изреченная есть ложь».

 

Понятно что имелось в виду: может и ненадо вовсе оптимизировать? Или и без этого все хорошо, или, может, тот врагмент кода, с которам мы сейчас работаем занимает, скажем, всего 1% оптимизируемого ресурса (обычно времени или памяти) – в этом случае улучшив его в 10 раз мы все равно выиграем менише одного процента. А на оптимизацию уходит время, да и код, возможно, становится сложнее и менне понятным, что, понятно, грозит потерям в будущем.

 

Все это так, конечно. И не так. Не раз я был свидетелем принятия решения использовать заведомо не лучший алгоротм/дезайн/стуктуру данных, ссылаясь на это правило! Редкостный бред.

 

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

 

Так что, правило должно быть таким: на каждом этапе создания нужно тратить некоторые (разумные) время и усилия на исследование возьщжных решений. И выбирать неоптимальное нужно лишь тогда, когда к тому есть веские причины. Скажем:

-        Это позволит получить работающий прототип всего или части проекта значительно быстрее.

-        Более простой выриант может быть потом сравнительно легко заменен оптимальным.

 

И уж конечно бывают задачи, когда мы уверены, что простейший вариант достаточно хорош и никакая оптимизация вообще не понадобится.

 

Под конец, курьезный случай по теме – в пользу Хоарова утверждения: был у меня начальник, который верил (его так научили), что чтобы программа работала быстро, ее надо писать на ассемблере. И написал он когда-то такую ассемблерную функцию – кажется это было вычесление автокорреляции или что-то вроде. А я – мне тогда уже надоели его поучения – ради издевательства ускорил ее раз в 10, переписав с ассемблера на С! Он обиделся (хотя я специално ничего не акцентировал). Это, кстати иллюстрация вредности другого правила, про ассемблер...


 


 


 

Profile

mishafurman: (Default)
misha furman

December 2016

S M T W T F S
    123
45678910
111213141516 17
1819202122 2324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 22nd, 2017 06:41 pm
Powered by Dreamwidth Studios