Просто выяснилось, что мы долго обсуждали разное — я «инсайт», а он «профессионализм». Вроде близкие понятия и результат на выходе один и тот же — решение, а вот его получение совсем разное. Инсайт полностью непредсказуем и применять его в процессе промышленной разработки противопоказано! Сначала надо построить бизнеспроцесс с конечным результатом на выходе. Тут ещё есть место и время и для размышления и для инсайта. Но когда процесс пошёл, то любая завязка на инсайт грозит бизнесу провалом.
Если не понимаешь, то надо разобраться, понять и снова же — зачем уже смелость?
Сидите вы час разбираетесь, два. Не разбирается. День, два. Не разбирается. Вы абстракцию и так покрутили и этак. Монолит. Неприступная крепость. И все вокруг пишут — это не решается. И тут вас осиняет. Вы пока только чувствуете брешь. И вы делаете маленькое допущение — если бы ослабить влияние одного/двух параметров на систему (например, некую «гравитационную константу» к которой все так привыкли и считают её неизменной), то решение вполне может и получится. А теперь подумайте, что может быть вы действительно первый, который не только смог понять где можно пробить дыру, но и придумал как это сделать. Вокруг в комнате сидят профи с орденами-сертификатами, но придумали вы, а не они. Как говорят евреи — цимес ситуации в том, что они даже не видели проблемы.
Повторюсь. Речь только об инсайте. Не о бизнесе.
Я всего лишь сказал, что подход «я не знаю, как я придумываю решения» непрофессионален.
А вы знаете как вы придумываете решения к задачам, к которым решения ещё не придуманы? Наверняка у вас есть хоть одна, но такая задачка, решением которой вы внутри гордитесь и что ни у кого нет её решения? Есть такое понятие как инсайт. Я полагал, что мы эту тему обсуждаем, хоть и не называл её. Скажите что-то лучше в этом направлении, а не «обещал за неделю». Обещать инсайт за неделю — сильно. У меня некоторые такие инсайты висят в фоне по несколько лет и их я заказчикам не обещаю в принципе.
Я вас услышал. Мне кажется забавным, что вы так долго ходите вокруг того, что решение может быть придумано не профессионалом. Я так и не увидел в нашем с вами диалоге какой-либо сильной корреляции между способностью найти решение нестандартной задачи и профессионализмом.
Пока решение не найдено — профессионализм побоку.
Ну то есть вместо одного профессионала, нужен непрофессионал, чтобы придумать, и профессионал, чтобы подтвердить.
Ну, такую парочку легко найти в любой средней конторе — аналитик и разработчик. Угадайте, кто из них непрофессионал? (Это риторический вопрос)
что решение будет на этой неделе, то оно будет на этой неделе
Простите, у меня встречный вопрос. Как вы разговариваете с заказчиком, когда не можете найти решения за неделю? Давайте примем утверждение, что речь не об однотипных задачах? Ну, не знаете вы, сколько времени займёт решение, но не хотите отказываться. В вас начинает говорить гордость или бизнесмен? Ведь есть вероятность и провала.
Нет, я просто хочу дополнить, что в ваших высказываниях (с моей точки зрения) недостаёт важного звена. Есть между задачей и найденным решением тонкая «прослойка». Маленькое качество разработчика. Называется «смелость». Смелость применить найденное решение. С моей стороны это недостающее звено о котором не говорится ни в каком учебнике по эволюции разработчиков.
Вот! Главное, когда заказчик остаётся доволен. Ему же не важно, кто придумал решение? Главное, что оно должно быть проверено. А придумано оно может быть и не профессионалом. Задача профессионала — подтвердить, что найденное решение является качественным и оно удовлетворяет требованиям заказчика.
А как по вашему, насколько умным должен быть человек, который применяет найденное решение? Решение же не скачет как осёл из Шрека «Возьми меня, возьми меня!»
Поэтому человек, правильно применивший решение ничуть не глупее того, кто это решение придумал.
А ведь решение может быть ещё неверно описанным. И если человек, который его нашёл ещё и поправил? Ну как, ставки возросли?
Решение, которое случайным образом считает сумму заказа…
Всегда можно придумать где такое может пригодиться. Например, для проверки правильного решения подсовывать ему неверные данные и смотреть как оно на них реагирует. Правда тут есть одна проблема — когда сумма всё-таки совпадёт и вы будете удивляться, что такого быть не должно.
Поэтому говорить, что что-то неверно можно только в определённом контексте, а не как решение само по себе.
Не так уж и трудно задачки решать
Проблема даёт вдохновенье.
Искусство же в том, чтоб суметь отыскать
Задачу, когда есть решенье.
Лучше плохое решение, чем его полное отсутствие, не так ли? И если профессионал не хочет принимать такой вариант, то дело плохо.
Вас в этом что-то удивляет?
Да. Удивление — основа всего. Даже профессионализма.
Совершенно ужасно. Просто непереносимо. Не будьте профессионалом.
(Осторожнее переходите на личности) Вы противоречия не заметили. Ужасно быть ограниченным профессионалом. (Профессионализм ведь не гарантирует отсутствие ограниченности)
1. А если его работа не предсказуема, то он уже не профессионал?
2. А если решение оказалось непредсказуемым, то тоже не профессионал?
3. Да, предсказуема, но только на определённом круге задач в которых он крутится. Вышел за область задач и профессионализм предсказуемо закончился. Тут нужны другие навыки. (Кстати, вы не подскажите — какие?)
4. Только настоящий профессионал может объяснить почему что-то нельзя сделать. ;)
Видите, сколько ограничений у профессионала? Это же так ужасно — быть профессионалом!
P.S. галоши у него тоже профессиональные. «Баги были такими хитрыми и трудными, что было сразу видно, что их писали настоящие профи!»
Вообще-то обучение на медицинских специальностях сильно отличается от обучения тому же программированию. После окончания 4-5 летнего обучения «на медицину» получаются общие специалисты, как и выпускаемые «программисты» того же уровня. Но потом в «медицине» начинается разделение и новое обучение, интернатура и ординатура, без чего медработников не допустят до чего-то серьезного, типа хирургии (но можно остаться в поликлинике). А программист может начать фигачить в продакшен с первого курса и даже раньше. Можно ли считать это недостатком — очень спорный вопрос. Все равно когда-то приходится начинать нести самостоятельную ответственность за свои действия. В этом случае программирование выгоднее отличается от медицины, т.к. нести ответственность в программировании начинают значительно раньше, ну и не тошнит, если вы понимаете о чем я )))
что многие так называемые самоучки на самом деле не горят желанием изучать все необходимое для работы
Позвольте поправить. Не только самоучки, но и вполне уважаемые доны, отучившиеся во всяких универах и много лет практикующих. Давайте без дискриминации. )))
Как понять, что тебе нужна многопоточность, если ты не знаешь о ее существовании?
Для меня самого секрет как я выбираю «ингредиенты». Для меня важнее «угадать» конфигурацию данных при передаче из одной системы в другую. Вполне возможно, что секрет кроется в том, что я пишу одну и туже программу, просто в разных модификациях. По аналогии — есть ДНК и из неё можно вырастить жука или кита. Я просто создаю условия, чтобы получались разные экземпляры. )))
я не спорю, что нужно знать, что есть алгоритмы. Я пытался расширить ваш комментарий. Просто думать только об алгоритмах мало. Очень много бизнес-задач не связаны ни с математикой, ни с алгоритмами от слова «никак» и несколько сортировок в программе на фоне общего объёма программирования — это ничтожная работа. В 99% случаев в бизнес-логике достаточно просто каких-то простых словарей и списков.
Вообще, знать надо такую кучу вещей, что прямо офигеваешь
Есть такое выражение «хвост виляет собакой». По аналогии это когда фреймворки и языки управляют программистом. Должно быть наоборот. Именно вы должны управлять процессом программирования, а не процесс программирования управлять вами. Не многопоточность всплыла в какой-то момент, а вы решаете «Так, мне тут нужна многопоточность» и подключаете её. Или «Для этих данных нужна реляционная модель» и подключаете MsSQL/MySQL/PostgreSQL. А тут у меня данные денормализированы. Тут мне нужен JSON/XML. На этом уровне модели мне нужно преобразование XML-JSON… какие тут у нас популярные библиотеки, протестируем… Эй, NuGet, maven, bower — по порядку рассчитайсь!
Сидите вы час разбираетесь, два. Не разбирается. День, два. Не разбирается. Вы абстракцию и так покрутили и этак. Монолит. Неприступная крепость. И все вокруг пишут — это не решается. И тут вас осиняет. Вы пока только чувствуете брешь. И вы делаете маленькое допущение — если бы ослабить влияние одного/двух параметров на систему (например, некую «гравитационную константу» к которой все так привыкли и считают её неизменной), то решение вполне может и получится. А теперь подумайте, что может быть вы действительно первый, который не только смог понять где можно пробить дыру, но и придумал как это сделать. Вокруг в комнате сидят профи с орденами-сертификатами, но придумали вы, а не они. Как говорят евреи — цимес ситуации в том, что они даже не видели проблемы.
Повторюсь. Речь только об инсайте. Не о бизнесе.
А вы знаете как вы придумываете решения к задачам, к которым решения ещё не придуманы? Наверняка у вас есть хоть одна, но такая задачка, решением которой вы внутри гордитесь и что ни у кого нет её решения? Есть такое понятие как инсайт. Я полагал, что мы эту тему обсуждаем, хоть и не называл её. Скажите что-то лучше в этом направлении, а не «обещал за неделю». Обещать инсайт за неделю — сильно. У меня некоторые такие инсайты висят в фоне по несколько лет и их я заказчикам не обещаю в принципе.
Пока решение не найдено — профессионализм побоку.
А если рассуждать без дедлайна? Ведь есть задачи, которые требуют решения, неважно, есть дедлайн или нет.
Простите, у меня встречный вопрос. Как вы разговариваете с заказчиком, когда не можете найти решения за неделю? Давайте примем утверждение, что речь не об однотипных задачах? Ну, не знаете вы, сколько времени займёт решение, но не хотите отказываться. В вас начинает говорить гордость или бизнесмен? Ведь есть вероятность и провала.
Нет, я просто хочу дополнить, что в ваших высказываниях (с моей точки зрения) недостаёт важного звена. Есть между задачей и найденным решением тонкая «прослойка». Маленькое качество разработчика. Называется «смелость». Смелость применить найденное решение. С моей стороны это недостающее звено о котором не говорится ни в каком учебнике по эволюции разработчиков.
Вот! Главное, когда заказчик остаётся доволен. Ему же не важно, кто придумал решение? Главное, что оно должно быть проверено. А придумано оно может быть и не профессионалом. Задача профессионала — подтвердить, что найденное решение является качественным и оно удовлетворяет требованиям заказчика.
Поэтому человек, правильно применивший решение ничуть не глупее того, кто это решение придумал.
А ведь решение может быть ещё неверно описанным. И если человек, который его нашёл ещё и поправил? Ну как, ставки возросли?
Всегда можно придумать где такое может пригодиться. Например, для проверки правильного решения подсовывать ему неверные данные и смотреть как оно на них реагирует. Правда тут есть одна проблема — когда сумма всё-таки совпадёт и вы будете удивляться, что такого быть не должно.
Поэтому говорить, что что-то неверно можно только в определённом контексте, а не как решение само по себе.
Не так уж и трудно задачки решать
Проблема даёт вдохновенье.
Искусство же в том, чтоб суметь отыскать
Задачу, когда есть решенье.
Хотите поговорить об этом?
А чтобы про это когда-то прочитать нужно это когда-то написать. Дилемма.
Где же про это прочитал тот человек, который про это написал?
Лучше плохое решение, чем его полное отсутствие, не так ли? И если профессионал не хочет принимать такой вариант, то дело плохо.
Да. Удивление — основа всего. Даже профессионализма.
(Осторожнее переходите на личности) Вы противоречия не заметили. Ужасно быть ограниченным профессионалом. (Профессионализм ведь не гарантирует отсутствие ограниченности)
1. А если его работа не предсказуема, то он уже не профессионал?
2. А если решение оказалось непредсказуемым, то тоже не профессионал?
3. Да, предсказуема, но только на определённом круге задач в которых он крутится. Вышел за область задач и профессионализм предсказуемо закончился. Тут нужны другие навыки. (Кстати, вы не подскажите — какие?)
4. Только настоящий профессионал может объяснить почему что-то нельзя сделать. ;)
Видите, сколько ограничений у профессионала? Это же так ужасно — быть профессионалом!
P.S. галоши у него тоже профессиональные. «Баги были такими хитрыми и трудными, что было сразу видно, что их писали настоящие профи!»
Вы же понимаете, что найти хорошее решение может даже и не профессионал?
Позвольте поправить. Не только самоучки, но и вполне уважаемые доны, отучившиеся во всяких универах и много лет практикующих. Давайте без дискриминации. )))
Для меня самого секрет как я выбираю «ингредиенты». Для меня важнее «угадать» конфигурацию данных при передаче из одной системы в другую. Вполне возможно, что секрет кроется в том, что я пишу одну и туже программу, просто в разных модификациях. По аналогии — есть ДНК и из неё можно вырастить жука или кита. Я просто создаю условия, чтобы получались разные экземпляры. )))
Есть такое выражение «хвост виляет собакой». По аналогии это когда фреймворки и языки управляют программистом. Должно быть наоборот. Именно вы должны управлять процессом программирования, а не процесс программирования управлять вами. Не многопоточность всплыла в какой-то момент, а вы решаете «Так, мне тут нужна многопоточность» и подключаете её. Или «Для этих данных нужна реляционная модель» и подключаете MsSQL/MySQL/PostgreSQL. А тут у меня данные денормализированы. Тут мне нужен JSON/XML. На этом уровне модели мне нужно преобразование XML-JSON… какие тут у нас популярные библиотеки, протестируем… Эй, NuGet, maven, bower — по порядку рассчитайсь!
«Ничто не ново — только мы»
Меня опыт научил двум вещам
— декомпозиция задачи
И
— как не надо делать