Уверен, каждый из нас не один раз задумывался над тем, что нас ждет в будущем. Я не собираюсь тратить ваше время на бесполезные, большей частью, размышления. Скорее наоборот, хотел бы поднять вам настроение (пост ведь пятничный) и обратить ваше внимание на важность стратегического планирования своей жизни используя хороший пример.
Одним словом — не судите строго.

Здесь и далее будут использоваться чудесные комиксы Geek and Poke и самая большая коллекция их переводов.
Любопытный и полностью реальный пример: Dave Rooney написал о своей жизни:
Недавно в Twitter я участвовал в разговоре о том, что зацикленность программных разработчиков на своих инструментах граничит с религиозным фанатизмом. Поймите меня правильно — хорошие инструменты повышают эффективность разработчиков, а их продуктивность, в свою очередь, зависит от того, в какой мере они овладели своими инструментами.

Однако, меня удивляет, что мы работаем в индустрии, в которой изменения не только нормальны но и ожидаемы. Скорость изменений постоянно растет и не собирается снижаться. Это странно, потому что разработчики, кажется, неохотно идут на смену привычных инструментов.

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

Вот перечень сред, в которых я работал с тех пор, как начал писать код:
30 лет назад (1983)
- Командная строка Apple; написание BASIC и ассемблерного кода.
- Мало функций редактирования, но чем меньше знаешь, тем лучше спишь.
- Через год в университете на мейнфрейме, использующем FORTRAN, был установлен Sed или похожий редактор.
25 лет назад
- xedit на мейнфрейме IBM с языком REXX.
- Это был приличный полноэкранный редактор, который можно было автоматизировать для обеспечения полноэкранного интерфейса пользователя для приложений мейнфрейма.
- Я также использовал vi для некоторых целей, который по сравнению с xedit кажется громоздким и отсталым.
20 лет назад
- Я использовал редактор для, не удивительно, языка C и ряда других.
- Редактор был удобным в использовании и я достаточно хорошо с ним ознакомился.
15 лет назад
- Я работал в интегрированных средах разработки Powerbuilder, Visual C++ и Visual Basic.
- Редактировать вне этих инструментов было неэффективно и рискованно.
- Я наловчился с ними работать.
- Редакторы IDE хорошо подходят для выполнения работ.
- Также использовал vi, запуская удаленные командные строки (remote shells) на Unix-системах.
10 лет назад
- Различные Java IDE: PowerJ, JBuilder, Eclipse в зависимости от стандарта организации клиента.
- Выполнял тесты в IDE.
- Использовал Textpad для редактирования текста вне IDE.
- В режиме терминала на удаленном хосте использовал vi.
5 лет назад
- Использовал Eclipse и NetBeans для Java, Visual Studio для C#.
- Выполнял тесты из IDE.
- Использовал Textpad для редактирования текста.
- В режиме терминала на удаленном хосте использовал vi.
Сейчас (2013)
- Sublime Text 2 для редактирования текста и кода.
- Выполняю тесты из командной строки.
- В режиме терминала на удаленном хосте использую vi.
Sublime Text действительно быстро выполняет индексирование и текстовый поиск среди тысячи файлов, но это цветочки по сравнению с умением находить определение метода на Eclipse или обходить иерархию классов. Я умею писать макросы в Sublime, способные автоматизировать повторяющиеся операции, что мне нравилось в Textpad и катастрофически не хватало в IDE. Однако, у меня нет автоматического рефакторинга, доступного в Eclipse и NetBeans.

Когда я наблюдаю за разработчиками, работающими в Vim и Emacs, мне кажется, что я смотрю на виртуозное выступление пианиста — весь процесс выглядит таким непринужденным! Меня поражает, что данные инструменты больше оптимизированы для написания кода, чем для анализа и рефакторинга.

Одно только предложение использовать другие — отличные от Vim and Emacs — инструменты вызовет нешуточные волнения. Но по своему опыту скажу, что не так трудно приспособиться к новым инструментам. Конечно, потребуется время, придется получить одни навыки, забыть другие, но гибкость того стоит.
Все-таки, выживают не самые быстрые или умные, а наиболее приспосабливаемые к изменениям.

Автор: aarner