так вышло, что мое высшее образование с IT практически не было связано, но когда меня занесло в индустрию, я поняла, что дальнейшее развитие без фундаментального образования невозможно. Последние пару лет я прохожу разнообразные курсы, в целом неплохие, но у меня по-прежнему нет целостной картинки, я чувствую пробелы в знаниях, но мне сложно понять, что именно стоит еще почитать/подучить или как должен называться предмет, которого мне не хватает.
Опишу что уже пройдено:
Data Communication and Networking (основной упор, был на типы сетей, протоколы, совсем немного про роутеры. но ничего не было про cloud, например).
Database Administration
PHP & MySQL + basic html and javascript (базовый курс, с простыми алгоритмами и функциями)
С/С++ (базовый курс, дошли до принципов ООП и немного практиковались в использовании)
Advance Business Systems Analysis (как из требований создается большая система, от анализа требований, моделирование данных, к дизайну интерфейса)
Quality Assurance (основные методологии, ничего про автоматизацию)
Software Project Management (тут тоже все понятно, про процессы разработки)
Где я чувствую пробелы:
1. В понимании архитектуры приложений. Точнее, я понимаю, когда мне объясняют, почему сделано именно так и за что отвечают компоненты, но как люди приходят к пониманию как эту архитектуру оптимальнее всего построить? Это исключительно опыт или все же какие-то фундаментальные принципы?
2. Несмотря на курс №1, понятие ACL мне было незнакомо (http://en.wikipedia.org/wiki/Access_control_list). Пытаюсь понять, что еще я могу упускать? Или это должно быть в рамках курса по безопасности компьютерных систем?
3. Читаю про static assets и не понимаю, кто их использует и почему. Точнее, почему кто-то использует, а кто-то нет (и чем обходится тогда?) Наверное какого-то общего понимания ка кработают фреймворки не хватает.
Что порекомендуете? И без чего никаки нельзя? Подойдут либо названия курсов, либо книги.
Цель минимум: понимать что говорят соответствующие специалисты, а не глупо хлопать глазами.
Цель максимум: уметь писать грамотные технические задания разработчикам, понимая как оно работает и зная чего хотят бизнес-заказчики
Вы бы определились, в какой области вы хотите получить необходимые знания. Глядя на набор курсов, которые Вы изучили, мне решительно непонятно в какой области Вы работаете. В кучу смешано администрирование сетей, администрирование приложений, веб-разработка, разработка на нативном коде…
Если Вам нужно администрирование систем и сетей, то рекомендую посмотреть хотя бы CCNA, там будут все необходимые базовые знания по сетям и маршрутизации. По приложениям сложнее, надо смотреть курсы по конкретному софту. Аналогично по фреймворкам, в их зоопарке надо разбираться с каждой конкретной системой.
В университете обычно студентам и преподают всего понемногу, как минимум основы. Я как раз пытаюсь понять, чего еще из основ мне не хватает для «фундаментального» понимания, но нет стремления углубляться в какую-то специфическую область (программистом я уже не стану), цели свои описала.
1. Опыт. Но книги почитать тоже не помешает, чтобы было откуда брать зачатки идей.
Code Complete
Design patterns
Writing Secure code
2. Windows Internals,
Windows via C++
Data Communication and Networking (основной упор, был на типы сетей, протоколы, совсем немного про роутеры. но ничего не было про cloud, например).
Я не вижу смысла разработчику углубляться в сети. Однако, по опыту общения с разработчиками скажу: вы ОБЯЗАНЫ прекрасно понимать работу стека TCP/IP и в первую очередь самого протокола TCP, который на самом деле имеет массу нюансов. Но при этом то, каким образом роутеры осуществляют доставку пакета, вам едва ли потребуется, этим займутся другие люди.
Я давно сбился со счета, сколько раз мне доводилось анализировать дампы пакетов тормозящего сетевого приложения и к примеру объяснять разработчику, почему в Москве оно летает, а во Владивостоке страшно тормозит при слабо нагруженных каналах связи.
Упомянутый выше CCNA — это здорово в качестве базы. Но стоит попутно углубиться в работу TCP на конкретных конечных системах.
Вы меня здорово подбодрили, мне казалось, таких вещей не знаю только я :-)
Спасибо, почитаю подробнее, в рамках моего курса tcp/ip была посвящена всего одна глава.
Насколько ваше образование было далеко от IT?
Математика, дискретная в частности? Это некий базис для архитектора. Потом пошли best practice, шаблоны и отдельные, хорошо изученные случаи типа клиент-сервер. Понимание приходит с опытом — пока что нет объединяющей теории, которая перечислила и оценила варианты дизайна. Если вы поняли Project Managment то должны быть знакомы с WBS и то как строиться план работ. В архитектуре примерно также — берем большую задачу и начинаем ее разделять на «красивые» куски. используя какие-то шаблоны. И так до тех пор пока минимальными кирпичиками будут понятные, читай шаблонные, задачи.
Базы данных базируются на RDBMS
Судя по списку вы работает, хотя скорее пытаетесь, работать ПМ-ом или бизнес-аналистом в студии веб-дизайна?
Если так что архитектура приложений для вас MVC, сетевая — клиент-сервер, базы данных для вас вторичны. ибо закрыты ORM фреймворка
У меня экономическое первое, год высшей математики, статистики и тервера, не думаю, что углубляться сильнее уже актуально. С областью вы угадали — бизнес-анализ, тестирование и релиз-менеджмент. Подумываю о продакт-менеджменте. Работаю в основном в веб-проектах, поэтому веб-архитектуры приложений актуальнее. Возможно, конечно, меня просто окружают люди с большим опытом, поэтому они и знают больше, а не в силу раз нос тор он него базового образования.
Спасибо, интересно. Муж признался, что и сам изучал лишь половину от перечисленного, но теория графов ему разок в работе понадобилась. Пойду смотреть что есть на coursera.
Образование — это прекрасно, но модель непрерывного образования — необходимость. В ИТ знания устаревают раньше, чем вы закончите даже бакалавра. Продолжайте делать то, что делаете, фокусируетесь на ключевых компетенциях в вашей области. Идея в том, что когда веб только начинался, не было разделений между дизайнерами, верстальщиками, администраторами, но по мере развития в одном клауд-компьютенге появится с десяток-другой профессий с достойными соц.пакетами. Такова жизнь. Никто не в состоянии понимать код на уровне архитектора, формулировать задания исходя из особенностей фреймворка и отвечать за сроки сдачи проектов. Больше похоже на то, что у вас проблемы с менеджментом подчиненных специалистов, среди которых есть и понимание архитектурных особенностей и политик безопасности и архитектуры БД. Я правильно вас понял?
Да, вы правильно понимаете задачу. Либо надо быстро определить что именно пошло не так во время релиза, и к какому узкому специалисту бежать за помощью.
По идее, всё это знание вы должны получить от команды, но как получить от команды эти знания — этот ответ лучше искать не среди «лаборантов» (или даже лабораторных хомячков), а среди менеджеров высокотехнологичных команд. Это же по сути менеджмент инноваций, копирование лучших практик конкурентов и пр. и др.
Посмотрите, как хабр изумительно извлекает из людей знания. Если бы я был «эйч аром», то косил бы здесь самых забористых спецов, но это мнение теоретика.
Дело пахнет написанием вами хорошего поста для хабра. Благо тут и технические директора имеются в читателях и менеджеры проектов. И, в отличии от Калифорнии, неприкрытый сексизм и лавры вашего обаяния вам лишь сыграют на руку. Таков «наш брат»: что бы получить кучу советов, нужно сказать что-то уверенно и потом услышать «как на самом деле нужно делать» от возбудившейся толпы зубастых читателей. Вы и не заметите как вдруг обсуждение вашего материала превратится в разборки между собой, а вам, как психиатру, останется лишь записывать и подливать масла в огонь.
У меня нет проблем с получением информации от команды, все очень открытые и с удовольствием рассказывают как и что устроено. Но я вижу как у более опытных коллег необходимость задавать вопросы присутствует намного реже, и тут мне не вполне понятно, только ли дело в опыте (который мне еще нарабатывать), то ли в знаниях. Плюс при собеседовании на следующую работу мне бы хотелось чувствовать себя уверенно, заявляя, что у меня есть образование в IT (будет сертификат, не диплом), и не чувствовать себя «самозванцем», который, вдруг, не знает чего-то общепринятого. Как, скажем, я удивляюсь, когда встречаю специалистом с дипломом экономиста/менеджера, не знающих базовых вещей из маркетинга, бухгалтерского учета или статистики.
Простой
Простой
