Приятную тему закрыли. Жаль. Основное качество программиста, я думаю, спорить никто не станет - склад ума, который позволяет ему решать задачи декомпозиции и алгоритмизации. А дальше? Вопрос, затронутый в теме "Есть вакансии?", заключается в том, чему отдать предпочтение при выборе специалиста и подготовке: опыту, знаниям, командности?
вообще-то это верно для любого специалиста. особенно с точки зрения работодателя/заказчика. только я повторюсь и добавлю, что он должен это сделать качественно и в срок.
Получается, что каждой задаче - свой специалист? Куда ж дальше специализироваться-то? И так идиотом себя чувствуешь, когда зовут настроить миниАТС, смотришь на эту гробину и пытаешься объяснить, что это несколько не то, к чему привык. "А чё, ты ж программист?". Rem, ваш ответ - не ответ. Это тавтология: "Для решения нашей задачи нужен специалист, подходящий для решения нашей задачи". Сколько языков/систем программирования сейчас актуально? Ну, с учетом полумертвых - никак не более 50. А сколько ВИДОВ ЯП? Сильно почесав репу, скажу - не более 5. Неужели человек, занимающийся к моменту начала серьезной трудовой деятельности изучением этого (одновременно со всякими концептуальными вещами вроде технологии, идеологии, инженерии, проектирования, управления) 5 лет, не способен приобрести квалификацию, при которой за неделю "с книжкой и мышкой" готов НАЧАТЬ (не говорю о профессиональной работе) писать на чем угодно? Почему я так ставлю вопрос? Потому, что у профессионала проблем с трудоустройством и определением своей цены обычно нет. А вот у того, кто потенциально может им стать - есть. О нем и тема. Чтобы сделать работу качественно и в срок - ИМХО более всего нужен характер. Просто деловой характер, сильный и требовательный к себе и коллегам. Которому никак не учат в ВУЗе.
osa, С одним характером Вы, увы, ничего не сделаете. А вот чувствовать себя идиотом никому не к лицу. Просто нужно сказать, что "у меня другая специализация". Зачем разбираться, вникать, когда есть спецы и по программированию АТС. Это я к тому говорю, что специализация - неизбежное следствие принципа разделения труда. Другой вопрос - когда возникают некоторые нестандартные задачи, которые ещё никогда не решались, какого специалиста предпочесть??
osa, ответ на твой вопрос в виде шутки - это твои слова - Только склад не в смысле склад, а в смысле склад. А если серьезно, на твой вопрос: - я бы ответил так: настоящий программист должен глубоко знать прикладную математику. В этом случае он найдет общий язык и с конструктором, и с технологом, и с бухгалтером, и с милиционером, и, самое главное, с другим программистом.
С характером, мозгами и бешеным честолюбием можно сделать многое... Я имел в виду, что характер ЗАСТАВИТ сделать как обещано даже ценой очень большого труда. Нестандартные задачи требуют нестандартного мышления, то есть таланта. А вот нестандартное образование может помешать :-) АВМ: перечитал трижды - про склад не понял. Наверное, это надо было слышать. Честно говоря, о прикладной математике не думал как об основе построения общения. Можно примеры?
osa В ближайшем будущем и эту тему ожидает подобное. Открыли бы тему в разделе соответствующую Вашему вопросу. А здесь этому не место.
вот еще, кому интересно: http://hedgehogs.softjoys.ru/Upuxa/CS/cs_tseitin.html http://hedgehogs.softjoys.ru/Upuxa/CS/cs_kalmar_ru.html а зачем тему закрывать - перенести ее в образование. делов-то.
Да. Это входит в понятие "задача" Rem добавил [date]1073973839[/date]: Прогресс налицо. Уточню - для решения задачи необходим тот, кто способен ее решить. Подходящий - недостаточно точный термин. Для решения текущих задач наиболее подходит узкий специалист, которых на такие задачи натаскан. При этом плевать, сколько у него классов образования и какой IQ. Чаще приходится брать специалиста на решение не только ближайшей задачи, но и на некоторую перспективу вперед. В этом разе выгоден компромисс между узкой специализацией и адаптивностью. И в этом случае образование стоит на последнем месте - после реального опыта, способности искать решения в нестандартных ситуациях и командности.
в понятие задача входит только то, что она имеет начало и конец. может быть я неточно выразился, тогда поправлюсь - качественно и в плановый срок. в остальных высказываниях Вы слишком категоричны. я например, придерживаюсь несколько другого мнения.
1. Знать инструмент, который он использует. Правильно им пользоваться. Это подразумевает не только заняние ЯП. Инструментов может быть много. 2. Знать предметную область. 3. Подчиняться руководителю или координатору проекта. Уметь работать с проектной документацией. 4. Уметь взаимодействовать с другими членами команды. Замечания типа - "иметь характер" "честолюбие", имхо это ерунда. Мировая индустрия программирования свидетельствует, что это процесс легко формализуем, легко ставится на поток, и от конкретной личности ничего не зависит. "Не боги горшки обжигают".
ИМХО вы не поняли. меня может наиболее мотивировать именно честолюбие и характер. быть винтиком даже за много денежков - неприятно. про проектную документацию - приятно слышать. Только уточните, что вы имеете в виду в контексте реальной российской практики? много слышал про то, что личность ничего не значит, взаимозаменяемость и тп. ИМХО: Чушь. Кадры решают все. Вы легко решите проблему ухода главного специалиста в проекте за месяц до его сдачи? Только реально ответьте.
osa, всё что я сказал, готов под этим подписаться. Я работал в реальной конторе, которая создавала коммерческие работающие проекты. Прошло уже много времени. Эти проекты живы и сейчас - всё отлично работает. Ещё раз повторю. Кадры ничего не решают, если производственный процесс построен правильно. А таак должно быть. Вдруг у вас важный специалист за 2 недели до сдачи проекта заболеет воспалением лёгких, и что вам его некем заменить? Ерунда, никто такие отговорки и слушать не будет! Деньги решают больше чем люди. Проектная документация готовится до начала основного этапа работ. Если вы конечно привыкли всё лепить на коленках, вам это не понадобится. Но я говорю о серьёзном (промышленном) программировании. Кстати разработка проектной документации и разумный дизайн будущего проекта - это 90% успеха. Программист решает только вспомогательную(неосновную) задачу. Поэтому суперзвезд тут не требуется, они даже вредны. Более важна роль проектировщика и координатора.
Полностью согласен с Bob только могу добавить, незнаю как это назвать, была одна задачка над которой я ковырялся 2 месяца, копал документацию, MSDN (инета небыло) и я конечно пропустил все сроки денег не заработал, но в итоге эту программу сейчас могу оформить за 15 минут. Было обидно... Вывод один - программист должен постоянно учиться, учиться и еще раз учиться (В.И. Ленин) В мою бытность стьюдентом преподы говорили, инженер не обязан знать все, тем более, что вокруг море справочников, главное - уметь правильно ими пользоваться и думать головой
Это должен понимать руководитель проекта и правильно мотивировать своих сотрудников. Сотрудник должен понимать свое место в команде иначе работы не будет. Это точно. При правильной организации работы так и должно быть, а если работа организована неправильно, то вы и с главным специалистом в срок не сдадите. jek добавил [date]1074080180[/date]: Гость Железно
Цитата, взятая из документа который лежит тут (кто-то уже приводил ее в ходе дискуссии): По-моему очень хорошо сказано.
граждане специалисты, забываете самое главное: любой программист должен обладать еще и физическими возможностями для решения вопросов по перемещению на своем горбу оборудования и всякой разной мебели в пределах объема отдельно взятого здания. У большинства сложилось ошибочное мнение о том что оргтехнику должны таскать только компьютерщики.
программист - не всегда сошка в ВЦ. есть вольные каменщики, есть просто те, кто не таскает. а что - проблемы с горбом?
по крайней мере настоящие программисты не должны задавать вот такие вопросы http://forum.volgograd.ru/showthread.php?s=&postid=328828#post328828 или изобретать свой свой алгоритм (в практической деятельности).
Саша, программист не обязан знать все существующие в мире алгоритмы. Алгоритмы придумывают другие люди. Например математики.
Володь, это ВСЕ существующие алгоритмя, а ОСНОВНЫЕ. тебя не удивляет, что за 13 лет я не забыл не только названия, но и сложностb алгоритмjd, причем воплощение их на ЯП у меня займет гораздо менее одного рабочего дня.
Гость Хм, я конечно не спец по этому вопросу, но чисто так интересно, что относится к "основным алгоритмам"?
ну ежели "чисто так интересно", то так как я тоже не спец по этому вопросу, т.е. не преподаватель и не занимаюсь академической деятельностью, то вот навскидку, что предлагает "Computing Curricula 2001" - вроде как новейшая версия рекомендаций по преподаванию информатики в ВУЗах. это ссылка на минимальный объем обязательный знаний: http://se.math.spbu.ru/cc2001/chapter05.html; http://se.math.spbu.ru/cc2001/ - это главная страница. и если лень читать всю статью, то вот как бы выжимка: " Алгоритмы и поиск решения задач: классические методы разработки алгоритмов; поиск решения задачи в объектно-ориентированной парадигме; применение методов разработки алгоритмов к проекту средних размеров с использованием формальных методов тестирования Основы анализа алгоритмов: асимптотический анализ максимальной и средней сложности; нахождение различий между лучшим, средним и худшим случаем; нотация О-большое; стандартные классы сложности; эмпирические измерения характеристик выполнения программы; компромиссы между алгоритмическим временем и алгоритмической памятью Рекурсия: понятие рекурсии, рекурсивные математические функции, простейшие рекурсивные процедуры, стратегия "разделяй-и-в ластвуй", рекурсивный перебор с возвратами, реализация рекурсии, рекурсия в применении к деревьям и графам Основные алгоритмы программирования: хэш-таблицы, двоичные деревья поиска, представление графов, обходы в ширину и в глубину, алгоритмы кратчайшего пути, транзитивное замыкание, минимальное остовное дерево, топологическая сортировка Основные структуры данных: указатели и ссылки; связные структуры; стратегии реализации списков, очередей и хэш-таблиц; стратегии реализации графов и деревьев; стратегии выбора подходящей структуры данных "
Сейчас меня камнями забросают, но помимо всего прочего программист должен любить свою работу. Когда работа не в радость, результат всегда хуже.
так, что-то тут все серьезно слишком стало. надо шутку юмора поддать. ВСЕМ НАСТОЯЩИМ ПРОГРАММИСТАМ, кто еще не читал, читать вот это: http://compuhumour.narod.ru/science/no_pascal.html