10 вещей которые должен знать программист

10 вещей которые ОБЯЗАТЕЛЬНО должен знать любой программист.

Прошу описывать все по пунктам в столбик:
1.
2.
3.
и т.д....

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
  • #code — «це тег кода» /**
  • *
  • *1. Наф. вашу яву, есть мнемокоди і с++
    *
  • * 2. Поф. на результат, главне путь, і фішкі попрікольніш в коді., можна і в * канкуляторі тиждень ## * довбаться, аби нравилось.
  • *
  • * 3. Якшо живеш з мамкою, поф. на зарплату і вобще на роботу.
  • *
  • * 4. Не обов’язково писать вобще програми, можна чужі «розкопувать»
  • *
  • * 5.Без рідмі і мануала — піпец.
  • *
  • * 6. Йохана матиматика і криптографія тоже нада.
  • *
  • * 7. Не нада фігачить заново велосипед якшо він есть в інеті .
  • *
  • * 8. Нада дивиться за здоров’м трохи, нада хоть раз в год миться, і спать * тоже нада, а то можна ## * получить геморой і загнуться.
  • *
  • * 9. Треба шоб клавіатура була хароша, і не розліталась після першого удару * хлебалом об неї, і не * нада фігачить монітор з ноги.
  • *
  • * 10. Треба бути обережним. А то мишка покусає, больно буде.
  • */

1) Как заработать 1000$
2) Как заработать 3000$
3) Как заработать 100000$
???????
PROFIT

Не желаете ли проинвестировать? ;)
Прибыль от 3 пункта пополам :)

Судя по последним тенденциям, то пункт только один:
0) Как держать автомат
:(

10 вещей которые должен знать программист
1. де купити бакс по 12
0. де продати по 15...

Это все такое гонево кто что должен знать.

Причина до банального проста: в каждой задаче есть своя специфика, с чем-то Вы работатет каждый день, а что-то только раз в году.

Нельзя знать так технологии чтобы выучиться раз и на всегда.

Даже фейсбук СДК меняется от версии к версии...

Как по мне к программисту могут быть только два требования — желание осваивать новые технологии и отсутствие занудства (это делаем только так) — иногда другие люди тоже бывают правы :)

1. Как пользоваться зеркалкой
2. Как ездить на велосипеде
3. Где купить сыр за 500 грн

3. Где?

нашёл максимум за 429 грн./кг козий сыр

Учитывая рост курса доллара, скоро сыр по 500 грн будет везде)

Подешевел, наверное. Точно был 500 на то время. Вот еще примеры:
winetime.com.ua/...voju_200346.htm
winetime.com.ua/...voju_200286.htm

Пункт № 0 — Цель Программирование — не цель, а средство, если бы можно было решать проблемы выстругивая квадратные палочки и выкрашивая их в зеленый цвет так бы и делали.
Пункт № 1 — Предназначение Людей интересуют они сами, их проблемы и немного другие люди. Все остальное их не колышет. Это помогает осознавать, что если можно сделать за 2 человеко-месяца, не надо растягивать на 50 человеко-лет, ваш заказчик не такой дурачок, он быстро смекнет что к чему и свалит, раструбив на весь мир что ваша фирма — куча муд*ков, вам с вашим эгоизмом может быть пофигу, но если ваше имя засветиться в black-list-е, потом не найдете работу.
Пункт № 2 — Результат Результат — главное, все остальное не имеет значения. На каком языке/томкате/сборки и что вы делаете, если результата нет — получите лучи гнева в свой адрес, в худшем не выплатят часть денег и поверьте, менеджер с вас не слезет после этого. Не выпендривайтесь перед заказчиком/ихним менеджером умными словами если результата нет. Сравните это поведение с поездкой в автосервис когда вам машину не починили, но вылили на голову ведро умных слов.
Пункт № 3 — Код Код должен делать то, что от него ожидается, ничего другого он делать не должен. Никаких методов про запас, никаких закомментированных кусков. Если вдруг в вашу сторону что-то полетит тяжелое — значит это вы создали getter, который допустим «заодно» подчищает объекты в базе, никаких побочных эффектов. Метод 1000+ строк с 20-ю блоками if-else и циклами 14-го уровня вложенности осилить невозможно.
Пункт № 4 — Подход Пишите как можно проще, я не призываю на все наплевать и получить сложность O(n*n) где можно обойтись O(1) или O(log(n)), то что вы напишете кто-то должен понимать и поддерживать. Код должен нормально читаться и восприниматься.
Пункт № 5 — Отраслевые стандарты Почитайте, освойте и ПРИМЕНЯЙТЕ отраслевые стандарты по использованию VCS, форматировании кода, деплоя, именования всего и вся, составления документации, создания тасков. Понятно что каждая кухарка мнит себя королевой, но блин вы не представляет как задолбал каждый раз новый flow в JIRA на одни и те же проекты, как задолбало форматирование в 2 пробела в Java коде, задолбал деплой через ж*пу подкидыванием файликов по одному на тестовый сервак. Задолбали отчеты в 4 места по UI-таску. Посмотрите как делаются проекты в Apache и не позорьтесь своими «ноу-хау».
Пункт № 6 — Выпендрежу и закидонам нет места Если бы заказчики почитали хотя бы 10% DOU, они бы вывели большую часть проектов с Украины. Потому что программисты в большинстве своем ведут себя, мягко говоря, неадекватно. Переписать код с Java на Хаскель потому что Хаскель — «тру», а Java — «не тру», линукс — «тру», винда — «не тру», абстрактные фабрики и монады для вывода 5 строк на консоль — «тру», конкатенировать 5 строк 1 раз — «не тру», адское шаманство JVM/среды разработки/инструментальных средств — «тру», чистый билд на Jenkins — «не тру». Задолбали, честное слово. Поймите, заказчику до фонаря, он привык сидеть в IE8 и готов ввалить в вас несколько лимонов долларов, чтобы вы поддерживали этот IE8, задумайтесь — миллионы долларов, его все устраивает и он готов заплатить за этот и тут вы с этим идиотизмом. Так что закройте рот и молча фиксите IE-баги. Если потребуется новые фичи, например полноценные CSS3 — вежливо и развернуто подскажите, что мы бы рады, но IE8 не поддерживает, давайте повысим версию?
Пункт № 7 — Уважайте коллег по работе На работе в основном занимайтесь работой, а не херней. Не отвлекайте коллег по пустякам, не врубайте музыку на всю комнату, не тролльте и не подкалывайте просто так, особенно в релиз. Не ведите себя как стадо обизян, не устраивайте кукольный театр в опенспейсе в рабочее время. Не разрисовывайте офис целую неделю. Не используйте масляные краски в непроветриваемом помещении и вообще в помещении и вообще рисуйте, с*ка, на дому.
Пункт № 8 — Документирование Пишите, бл*, комментарии на сложные методы, модули и в коммитах что это делает. Не пишите, бл*, что метод возвращает boolean или бросает проверяемый Exception, я это и так вижу по его сигнатуре. Поверьте 100500 х //TODO в коде не радует и хочется кому-то дать в морду. Составьте wiki как вашего франкенштейна поднять, если не хватает ума сделать скрипт в одну команду.
Пункт № 9 — Пожелания Делайте работу качественно, с любовью или хотя бы с достоинством, спустя рукава и лишь бы отсидеть и затянуть 2-х дневный таск(на расслабоне) на 4 недели — не надо, пожалуйста. Не стоит делать видимость работы, все прекрасно понимают что к чему и рано или поздно вас «сдадут» ли вы сами сядете в лужу.

Позволь сократить твой текст.

Кстати, сайт с оригиналом УМЕР. Если кто хочет поднять копипасту — самое время поймать топ гугла. В идеале — поселить на DOU на ПМЖ.

Вы неправильно поняли или невнимательно читали. Код — от силы 10% успеха в программирование, еще 50% — отношения с людьми и 40% поставленный процесс.

А вот это, я считаю, работа организации: строить рабочие отношения с людьми и поставленный процесс. Тогда код будет давать 100% успеха. Это в 10 раз больше чем в предыдущем случае.

Если программист должен это всё делать сам — самое время бросить «дружный коллектив» и найти работу, где надо код писать.

Смерть всем жалким эпигонам programming-motherfucker.com !!!
Да и Zed Shaw не рубит тему, да здравствует единственно верная концепция «Engineering, motherfucker» с инженером из TF2 в качестве маскота;)

Поддерживаю в части пункта 6. Делайте что просят, а не то что нравиться.

0. Уметь дорого продавать свое время и знания. ;-)

И quertysmerty пророк его;)

Я думаю что он преувеличивает, с его гонором и звездной болезнью маловероятно, что его будут в бодишопе терпеть, а в продуктовой/стартапе пашут и больше 8 часов, так что выходит он где-то привирает. :-)

Тем не менее, «концепция ситха» логически непротиворечива и работает, некоторые моменты проверял на себе.

Вряд ли рабочий день начинается с проповеди разумного эгоизма (dou.ua/...rticles/egoism) своему начальству, все же нужно делать так, чтобы выглядеть белым и пушистым.

Lovers gonna love, haters gonna hate, мудрый человек берет то, что ему по нраву из любого учения, лепит своего Франкенштейна и двигается вперед.

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

А тут чувак раструбил на всю Украину что он эгоист, чихать хотел на всех, у него 8 часов (кстати тут не мешало бы проверить чего), ему вынь и полож в конце месяца, ну детский сад какой-то.

Дык он разумный эгоист, во главу угла ставит договор о выполнении определенных обязанностей, а не следование идеям секты с неясными целями.

Как ни странно, когда я начинаю «чихать на всех», заниматься только своими обязанностями, работать 8 часов в день (но интенсивно)и фокусироваться только на своей задаче — у меня резко повышается производительность и отношение ко мне менеджера.

Когда начинаю чересчур «болеть за проект» — то все обычно ухудшается, ибо общество без цветовой дифференциации штанов бессмысленно(тм) и не стоит сильно лезть в чужую зону ответственности специально обученных для этого людей.

Вследствие этого работодателю выгодно, чтобы я был немножечко «разумным эгоистом»

Мир полон единством и борьбой противоположностей;)

Раструбил анонимно (почти) на форуме, на «всю Украину». И вести себя как так в реальности — сильно разные вестчи.

К примеру деплой на продакшен и что-то идет не так и нужно фиксить, а затем подливать и это затянется на несколько часов, а чувак тут такой встал и ушел, хотя нужна его помощь, это норма по-вашему? Одной такой выходки достаточно, чтобы заслужить «слив» на вечный сапорт-проект, из которого он уйдет сам. Разумеется ни о каком повышении з.п. и должности речь не идет. А если заказчик озверел и не выплатил часть денег, то могут и з.п. не выплатить и вполне обосновано, можно потом как ЧП-шник судиться.

Я веду к тому что нужно понимать главное: платят за решение проблем, а не за отсидку на попе 8 часов. Если проблема затянулась — надо решать, а не вести себя подобным образом.

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

Габі, я тебе не впізнаю. Чи не покусав тебе часом інфікований копроративними цінностями ХєР?

[GrammarNaziModeEnabled]
Чи то ХіР? Ангажуємо дідуся азірова для консультації? ))

А якщо серйозно, то в ситуації, коли:

деплой на продакшен и что-то идет не так и нужно фиксить, а затем подливать и это затянется на несколько часов

і у випадку, якщо якимось довбням вистачило клепок деплоїти за десять хвилин до закінчення робочого дня, то це, вибачте, клініка, і тут дійсно варто встати та піти, можна навіть прихопити з собою чашку та капці. Якщо ж навіть мова йде про повноцінний запланований деплой, а не вилив гівнокоду у лайв намання зі схрещеними пальцями, але баги на продакшені таки лізуть один за одним, то де та межа самопожертви? На скільки затриматися? Годину? Дві? Десять? Якщо проект настільки критичний, якого дідька не було прогону по тестам, пред-деплою і такого іншого, якщо не критичний, нафіга рвати собі дупу? Ні, я тебе не впізнаю, більш того, не розумію ((

Я веду к тому что нужно понимать главное: платят за решение проблем, а не за отсидку на попе 8 часов.

Чи ти часом не у менеджери пішов? Якась до нудоти знайома риторика.
Якого тоді, вибачаюсь, путіна, всі ті робочі графіки? Ось нехай ДІЙСНО дають бабло за вирішення питань і не очікують, що коли тасків нема, бо замовник плямкає обвислою пісею та не може сформулювати що за нах йому ще потрібно, всі будуть тупо сидіти і в буквальному сенсі торгувати пикою. А то, блін, коли це вигідно, то «вас, Штирлиц, я попрошу остаться ©, в нас же команда, взаємовиручка, деплой і бла-бла-бла», коли — не дуже, то «сиди собі тихо, тобі ж по годинам платять». Нє, я допускаю, можна обміняти затримку у декілька годин увечері, нехай навіть 5 (а це навіть гірше співвідношення, ніж один до двох) на додатковий віхідний, чи щось накшталт того, усе ж інше — від лукавого.

Если на проекте постоянно требуются "подвиги"(а не интенсивная, но размеренная работа), то их потом, увы, никто не оценит. Говорю как краевед;)

Если на проекте постоянно требуются "подвиги"(а не интенсивная, но размеренная работа), то
... народ там довго не затримується :))

Вопрос в том насколько часто такая ситуация возникает :) Если это раз в полгода-можно потратить час другой на достижения цели. Если это стабильно-тогда здоровый эгоизм.

Я еще раз повторяю: многие программисты ведут себя как кошки, потребляя консервы не задумываясь о том, откуда эти консервы берутся.

Пожалуйста. Был удивлён, когда не нашел этот документ в комментариях =)

1. Не говорить что ты программист.
2. Логически мыслить.
дальше опционально.

Кому не говорить ? ХР на собеседовании? не логично както...

Тем, кто попросит потом переустаовить винду и взломать контакт.

Или посмотреть «вот там в телефоне ...» Или будет спрашивать «сколько стоит сделать сайт»?

Когда-то встречал ссылку, где было расписано что должен уметь программист, в зависимости от своего опыта. Но сейчас найти не могу...

вот такая ссылка была бы очень полезна, я тоже искал такую статью

Да, похоже. Только там на английском было.

Спасибо, прикольная штука

Матрица компетентности программиста? Если она, то подборка критериев весьма достойная.

Не знаю насчет десяти, но скопирую чутка у дяди Боба
Here is a minimal list of the things that every software professional should be
conversant with:
• Design patterns. You ought to be able to describe all 24 patterns in the GOF book
and have a working knowledge of many of the patterns in the POSA books.
• Design principles. You should know the SOLID principles and have a good
understanding of the component principles.
• Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall,
Structured Analysis, and Structured Design.
• Disciplines. You should practice TDD, Object-Oriented design, Structured
Programming, Continuous Integration, and Pair Programming.
• Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri
Nets, State Transition Diagrams and Tables, flow charts, and decision tables.

Дядько Боб звичайно крутий але, як на мене, майже все це фігня словоблудна. Лінус гарантує ;)

Точно так же как во всяких Enterprise продуктах совершенно не нужно двоичное исчисление, глубокое знание структур данных и прочие вещи актуальные ембидщикам, железячникам, геймдевам и т.п.

На всяких Enterprise продуктах і програмісти не потрібні. Сотні вчорашніх барменів це підтверджують.

0) двоичное исчисление
1) прочее

Должен знать цепочку управления — тех кто непосредственно им руководит.
Знать принципы общения — кому, как и в каких случах обращаться.
Есть тикет — есть работа. Нет тикета — нет работы.
Без TЗ результат хз.

Потом уже всё остальное.

1. уметь программировать.
2. знать английский
3. уметь пользоваться гуглом, системой документации, манами, ртфмом, книгами, и прочими средствами для нахождения нужной информации.
4. уметь четко и связно доносить свои мысли коллегам и заказчикам.
5. уметь выслушивать, а главное вникать в то что говорят коллеги и заказчики.
6. уметь и не лениться писать техническую документацию.
7. уметь и не лениться читать техническую документацию.
8. знать про используемую у вас методологию разработки, организацию комманды, взаимодействие с лидом, менеджером, заказчиками итд.
9.Знать немного о тестировщиках, ба, и прочих не программистах. О том каков их смысл работы, и как с ними взаимодействовать.
10. знать про доу

тут таг скорее КЕП нужен))

это сарказм со слезами.
Ибо большая часть проблем возникает с тем, что люди эти КЕПовские пункты не соблюдают

Можно обобщить:
1) Уметь и не лениться

ну потом последуют темы на форумах, типа: «умею и не ленюсь, а брать на работу никто не хочет...»

Підписатись на коментарі