середа, 15 червня 2011 р.

CAJD::Technologies

Вопрос второй

В проекте, где я работаю, используются устаревшие технологии. Как мне в такой среде поддерживать свои знания в актуальном состоянии, профессионально расти и увеличивать собственную рыночную стоимость?


Простой ответ - изучать "новые технологии" самостоятельно. И это, вобщем-то очень хороший совет, но по-моему это только часть ответа на вопрос. Снова поднимемся над ситуацией и попробуем найти корень проблемы.

Для этого мысленно посмотрим на рынок навыков Java-программирования 8-10 лет назад. В том время человек, который знал EJB 2.0/2.1 считался джедаем и все новички в Java непременно стремились изучить EJB. Я не был исключением, и мне это удалось, и я знал EJB 2.1 довольно хорошо, и все рвался их применить в проекте. Но время неумолимо шло вперед. Сначала появились Hiberante и Spring, и знания EJB больше не были так необходимы. Потом вообще перестали говорить про middle-tier и стали говорить про JSF, GWT, затем - про NoSQL, Groovy/Grails и прочие модные штуки. К чему я все это рассказываю? К тому, что достаточно просто проследить следующую тенденцию

  1. Человек выучил Hibernate и знает ее досконально. Его знания будут востребованы на рынке до тех пор, пока Hibernate актуален и широко используется. Между тем это всего-лишь один из persistence famework, у которого куча конкурентов.

  2. Человек выучил Java и знает ее не то чтобы досконально, но достаточно хорошо. Его знания будут востребованы ны рынке до тех пор, пока Java актуальна и широко используется. Это уже уровень языка программирования. И сейчас кажется, что так будет всегда. Нам не дано досконально знать будущее - может быть и будет. Но вот C/C++ до сих пор актуален, а найти работу сложнее и сложнее.

  3. Человек понимает принципы программирования - как устроен и работает тот язык, на котором он пишет, что происходит во время и после компиляции кода, основные алгоритмические практики. Это уже несколько больше, чем даже уровень языка программирования. И на этом уровне конкретный язык программирования уже перестает иметь решающее значение. Его знания будут востребованы на рынке до тех пор, пока существует программирование как инженерная дисциплина. Здесь мы уже можем условно говорить про "инженерные навыки 1.0"

  4. Человек умеет решать проблемы заказчика. Не просто писать хороший, оптимальный, выверенный код, отдавая себе отчет почему он пишет этот код именно так, а еще и отдавая себе отчет зачем он пишет именно этот код и именно таким образом. Также, человек решает проблемы заказчика в тех временных и бюджетных рамках, которые установлены для задачи. Это уже следующий уровень. На этом этапе можно говорить о том, что само программирование уже не имеет решающего значения. Конечно, освоить принципиально иной инструментарий будет тяжелее, чем выучить новый язык программирования. Но тяжелее, не значит невозможно. Знания и умения этого человека будут востребованы на рынке.... Сложно провести черту, правда? Условно назовем это "инженерные навыки 2.0".


Как показывает мой опыт, старые и проверенные проекты, в которых поставлен процесс, определена архитектура (ну или то, что когда-то было архитектурой, бывает по-разному) и выбран технологический стек являются хорошим подспорьем для развития базовых инженерных практик. Покопайтесь в документации, поймите зачем и почему было сделано то или это. Если саппорт не занимает много вашего времени и усилий - отлично, у вас есть время зарыться в основы программирования, алгоритмику и/или принципы работы Java/JVM.

Резюме


Вот это и есть длинный ответ на поставленный вопрос. Я искренне убежден, что необходимо развивать вот эти самые инженерные навыки. Языки и фрэймворки меняются, сегодня на рынке востребовано одно, завтра - другое, послезавтра - третье. Неизменным остается дефицит людей, которые умеют решать проблемы бизнеса в рамках сроков и бюджетов, полностью отдавая себе отчет в том зачем и почему они решают эти проблемы именно таким образом. Разумеется новые, актуальные технологии имеют ценность. Но знание технологий без понимания зачем эти технологии были созданы, какую задачу они решают и чем они лучше/хуже других не так уж и ценно. Другое дело, если знание технологий подкреплено осознанием того, какую именно пользу принесет та или иная технология конкретному проекту отдельновзятого заказчика.