Репост: Переживания цивилизованного человека.

Статейка про природу нашего беспокойства. Для хомо сапиенс характерно больше беспокоиться и переживать за будущее, чем за кратковременное настоящее. В отличие от менее развитых существ. Чем более цивилизовано общество, тем меньше его членам нужно заботиться о сиюминутном выживании, но тем больше они вынуждены переживать за свое и сородичей будущее. Образование, перспективы, зарплата, семья... И чем меньше уровень цивилизованности, тем короче тот период времени, за который человек пытается заглянуть. Причем это заметно и в современном обществе. Чем спокойнее и стабильнее живет страна (тот же СНГ), тем дальше начинают загадывать ее граждане — на 10, 20 и более лет. В 90е загадывать на год-два вперед было уже сложно.
В отличие о людей, у животных таких проблем нет. Поймал оленя, съел, валяешься под деревом и ни о чем не думаешь. Только пытаешься сам не стать съеденным.

---

The Evolution of Anxiety: Why We Worry and What to Do About It

lifehacker.com

Let’s pretend for a moment that you are a giraffe. You live on the grasslands of the African savannah. You have a neck that is 7 feet long (2.1 meters). Every now and then, you spot a group of humans driving around on a safari taking pictures of you.

Почему так мало людей становятся программистами?

В дополнение к статье "Не будите спящего программиста" хочется зафиксировать еще одну статейку, правда на английском. Это ответ на вопрос на сервисе Quora: "Why Don't More People Work As Programmers?" Поскольку подобные сервисы грешат всякими пропаданиями, зафиксирую ее копипастом здесь. В кратком изложении заметка рассказывает о том, что быть программистом (от себя добавлю, что описание может касаться и некоторых други Software специальностей типа DevOps и QA), нужно постоянно учиться чему-то новому, постоянно соревноваться с новичками, которые знают меньше, но готовы пыхтеть ночами, говнокодить, использовать кучу лишних костылей и велосипедов, постоянно нужно быть в курсе новых технологий, веяний, языков, инструментов... И к тому же, нужно учиться создавать продукты во все более узких рамках и короткие сроки. Постоянно. Бесконечно. Далеко не все могут, хотят, готовы на такие темпы.

Becoming a good programmer is incredibly difficult and it doesn't happen quickly.

We can't expect to plant some trees and have 2000-year-old redwoods grow overnight, regardless of the demand for them.


Personality traits

• One basically has to be an autodidact to learn programming. It takes years of practice to learn everything necessary to get beyond just a basic level where you can write short programs that work. No one has ever become a great programmer just by taking classes or reading books. It takes hours of practice. And contrary to popular belief, CS programs do not teach programming. CS programs teach theory.
• As a programmer you need to have nearly unlimited persistence to continue trying to troubleshoot, fix, and develop things. It takes a special person to persist this much, especially when it often seems like you're not making any progress. This is pretty much a personality trait, and not having this level of persistence is enough to turn off most people who don't have it from the profession.
• You need to be exceptional at math and problem solving. Programming is a LOT of problem solving.
• You need to have an excellent short term (and long term) memory so that you can juggle multiple things in your head simultaneously, and remember what you wrote a month ago.
• You need to have a great understanding of how things interrelate and how to design good architecture. If I change this little thing here, what might I be breaking elsewhere?
• You need to have incredible attention to detail. Close doesn't cut it in programming. Forget a semicolon somewhere? Program isn't going to compile! Misspell a function name? Your program could be doing something completely different than you anticipated.

Not having these personality traits is enough to weed out most people.



Subject Matter

• You need to have a strong understanding of data structures and classes and know when and how to use them.
• You need to have some familiarity with libraries that have already been developed so that you don't have to reinvent the wheel.
• You need to have familiarity with a lot of basic (and advanced) algorithms, again so that you don't have to reinvent the wheel.
• Often you need to know the limits of the hardware that you're working with so that you can do things like managing memory properly and avoiding running out of it, or utilizing your memory properly to eliminate wasted transfer of data within the processor and speed up processing.
• So you can program. Great! But do you know anything about packet structure, TCP/IP, HTML, CSS, user interface design, or databases? Programs don't run in isolation.
• There's a ton of stuff you need to know, and it keeps changing! It's not something you can be truly great at unless it's your main focus. You can't be a "weekend programmer."

Work/Life Environment

• You need to have long blocks of uninterrupted time so that you don't lose your concentration when you're programming (and learning to program). Many work (and home) environments struggle to offer this. Phone rings? Great, it's going to take you 15 minutes to regain your train of thought.
• You often have to make decisions about tradeoffs on the fly. Sure, you could write a program that could handle every single case, but how often is someone really going to put in "zero" as an input? Besides, we're behind schedule, and it's more important to get something up and running right now.
• On top of all this, the language that you thought was the next big thing was a passing fad and nobody is using it 5 years later. Now you're on to the next cool language, which might not be used 5 years from now. You constantly have to stay on top of things.

On top of that there are the management aspects.

Programmers are often treated like factory workers. People with no programming talent (and less business sense) are often in charge of projects. They think programmers are cogs in the machines. The truth is programmers are artisans and to get the best results from a project the wise thing to do would be to ask the people who are experts at programming how things should be done! Just about every project ends up being over budget and behind schedule, forcing programmers to work tons of uncompensated and unappreciated overtime to deliver a poorly-designed and poorly-tested product. The great programmers realize that they're not being paid more than the crappy programmers because management can't tell the difference - and on top of that, they're doing extra work to compensate for other programmers being below-par. And great programmers who speak up and try to change things for the better are often intimidating to managers, who often try to get rid of them (which is a general employment trend discussed in other posts). Enough of this and it's easy to see why good people get fed up with the profession - especially since there are plenty of other opportunities. People who are even average programmers, as long as they're reasonably good at dealing with people, have enough skills to be successful in a variety of other professions. Programming is something that can be easily transferred out of, but not into.


Good programmers are probably less likely to be randomly looking for work.

It's easy to find programmers. It's hard to find good programmers. The crappy programmers are probably perpetually looking for work. The good programmers, if a company realizes that they're good, should do whatever it takes to hang on to them, so they're probably looking for work a lot less often. And when they do they're choosy about where they want to work - which would explain why many companies claim "there are no good programmers available - all we can find are crappy ones." As has been said elsewhere, a good programmer can certainly be worth several times what an average programmer is worth, and a crappy programmer can actually have negative value. And it's really tough (if not impossible) for crappy and average programmers to turn into good ones - and certainly not worth the investment for any startup to try to undertake when they're supposed to be focused on developing something quickly and getting it out the door.

"Дающий" Лоис Лоури. Кратенько про впечатления

 Сперва посмотрел фильм "Посвященный". Ну, такой себе фильмец. Антиутопия, черно белый, тоталитарная коммуна... Видели, смотрели уже. Но потом решил прочитать книгу. Хотя книгой это произведение сложно назвать — 130 страниц всего. До последнего абзаца читал просто как сценарий фильма. А потом — бах, и книга раскрылась. Произведение изменилось. Стало восприниматься совсем по-другому. И это тот случай, когда книгу нужно прочитать перед просмотром фильма. В фильме я не увидел того, что открыла книга. Теперь, зная идею (по крайней мере я так думаю, что знаю), пересмотрю еще раз фильм с уже новыми ожиданиями.
Произведение — про выбор. Общество сделало выбор. В результате добилось описанного строя со всеми его привлекательными достатками и жестокими последствиями. Главный герой тоже сделал выбор. И получил красочное путешествие, приведшее к описанному финалу. И что самое интересное, читатель тоже получает возможность выбора: достигли ли беглецы своей цели, или описанный финал — сон умирающего замерзающего ребенка? К чему привел его выбор? К успеху или смерти младенца? А что бы читатель выбрал на месте Джонаса? Примечательно, что такая игра с читателем возникает на последнем абзаце произведения. Потому произведение как бы и не заканчивается — я рассказал, а ты выбирай.
Книга, как по мне, очень полезна для подростков, которые начинают делать первые значащие решения. И каждое решение может привести как к покатушкам на санках к теплому дому, так и к замерзанию в сугробе. Для людей взрослых, в прочем, книга тоже не будет бесполезным чтивом, если только не рассматривать ее как попытку автора описать возможное развитие событий. Она не о том.
Рекомендую.

Вариант оценки потенциального работодателя для ITшника на этапе собеседований.

Интересный вариант оценки IT компании вычитал на RSDNe. Кое-что субъективно, но есть здравые мысли:

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

Итак, начнём с собеседования с hr-менеджером

— с вами пытается торговаться о зарплате HR-менеджер и/или первым делом пытаются выяснить "минимальную сумму, за которую Вы согласны работать"

Сразу отметаем подобные организации. Дело в том что организация может искать человека с целью 1) закрыть вакансию 2) найти человека, который будет реально помогать делать продукт. В чём же отличие, спросит пытливый читатель? А отличие в том, что первый вариант предполагает менеджмент уровня "получить деньги на старт/продолжение проекта и набрать 'ресурс' за минимальный бюджет", в то время как второй вариант предполагает менеджмент уровня "собрать сильную команду на годы, для успешного создания и развития продукта". В результате разница разительная. В первом случае получается команда в среднем слабо компетентных разработчиков, просиживающих большую часть рабочего дня за интернетами, чаепитиями либо беседами "за жизнь". При этом над ними с кислыми минами и претензиями как коршуны вьются менеджеры проектов, которые являются в таких организациях first-class citizens. Что в принципе обосновано, т.к. вся работа по обеспечению притока капитала лежит на менеджерах. Во втором случае получается команда сильных профессионалов, которые большую часть рабочего времени делают продукт, обеспечивают качество продукта, и связь между притоком капитала и качеством продукта самая непосредственная. В этом случае именно инженеры являются first-class citizens. Подытоживая — во всех организациях, о которых я могу сказать что они ищут людей по схеме №2, вопрос о зарплате задавался после всех собеседований.

Вариант №1 практически всегда (пресловутые 95%) встречается у "интеграторов", "аутсорсеров", "стартапов", а также примерно в половине случаев она встречается у продуктовых компаний, причём чем крупнее компания — тем вероятность выше.Вариант №2 в 95% случаев встречается у небольших компаний со штатом инженеров в пределах дюжины, имеющих свой продукт который приносит стабильный доход.
— hr-менеджер даёт вам "психологические тесты"hr-менеджер действительно может оценивать кандидата в плане психологии, являясь фильтром для очевидно неадекватных кандидатов, однако тесты это уход hr-менеджера от ответственности в принятии решения, а так как работа hr-менеджера есть отражение менеджмента в целом, готовьтесь к тому что в организации весь менеджмент избегает ответственности любыми доступными средствами


Собеседование с техническим менеджментом ( тимлид/техдир )— в качестве системы контроля версий используется git ( исключение — open-source проекты )это может показаться забавным, но именно этот пункт является ярким индикатором незрелости/неадекватности команды инженеров. Дело в том что идеальной для подавляющего числа организаций является централизованная vcs, в частности svn ( в купе с vpn-доступом). Так как распределённая vcs вносит дополнительный уровень сложности, а количество инструментов для работы с тем же svn в разы больше чем для работы с другими vcs, то должна быть очень веская инженерная причина для использования git/mercurial/etc. Если вы поинтересуетесь причиной и вам в ответ скажут что-то пространное ( вроде "в git легко делать бранчи" либо "весь мир давно перешёл на git", "в git можно коммитить локально" ), то с вероятностью 95% вы имеете дело с молодой порослью — читателями ксакеп.ру, хабрахабр, лор, которые далеки от инженерии как Линус от балета.
— вам дают тесты на техническом собеседовании или "тестовое задание" на домздесь одно из двух, либо вы — молодой, подающий надежды специалист, которого не о чем спросить кроме как о виртуальных деструкторах, либо собеседующий вас — некомпетентен и опять же ( как в случае с hr ) избегает ответственности в принятии решений. Человека с опытом можно распознать в простой беседе о двух вещах: 1) зашипленных проектах и его роли в них 2) беседой о том как бы человек решил инженерную задачу ( реально существующую в компании или выдуманную — не суть ). В рассказе по этим двум пунктам важно услышать всё — и собранные требования и выбранные инструменты и примерный дизайн решения. Предложение же сделать домашнее тестовое задание — это моветон в чистом виде. Максимум что от вас могут попросить вменяемые технари — это пример кода.

Поле боя— у разработчиков один мониторБез комментариев. Просто бегите.
— рабочее место сильно ограничено по площадиЛюди цепляются локтями/спинками кресел? Вам здесь не рады."

Обзор: Don’t Overwhelm Yourself Trying to Learn Too Much

"Don’t Overwhelm Yourself Trying to Learn Too Much". В трех словах: "Нельзя объять необъятное". В данном случае — в приложении к самообучению программистов. Держать себя в тонусе конечно нужно, но если наброситься на все новости, инструменты, языки, методики, то специалистом все равно во всех областях не станешь, а сил и времени не вернешь. Походу к этим мыслям приходят со временем все. И Козьма Прутков тоже был не первым.

Обзор: What Makes a Good Check-in?

В статье "What Makes a Good Check-in?", как ни странно, обсуждается не Forsquare, а SVN. Потому я бы назвал статью в "What Makes a Good Submit?", но что есть, то есть. В статье рассуждается про пользу систем контроля версий, про то, как должен оформляться сабмит для того, чтобы нести реальную пользу для его автора и всех последующих пользователей. В общем, ничего особо нового, но освежить знания и понимание необходимости правильных самитов помогает.