ya_recoder

Меня всегда мучал вопрос - как объяснить людям никогда не занимавшимся такого рода трудом, каким занимаюсь я то что вот происходит у меня и у таких как я в голове когда мы работаем. Как НЕ программисту представить себе работу программиста и понять наконец чего же происходит и как вообще с этим быть.

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

Ну вобщем хватит предъистории.

Как работает программист.

Работа программиста - это СОН.

Звучит нелепо, правда?

Если вы хотите представить что именно делает программист во время работы, то легче всего это представить именно так. Он спит!

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

Это вы думаете что программист взял задачу, написал программу и задача решилась. Всё не так.

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

Для решения задачи программисту приходится стать в своём сознании и лабиринтом, и искомым выходом, и заблудившейся девочкой, и тем перстом что ведёт её куда-то, и теми камушками которые она разбрасывает по дороге чтобы узнавать уже пройденные места. Всё это СНИТСЯ программисту во время работы.

Я не фигурально выражаюсь. Это БУКВАЛЬНО снится. Программист при решении задачи виртуально живёт в создаваемом мире химер, похожих каким-то образом на условия решаемой задачи.

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

Большинство людей процесс засыпания воспринимают как определённый ритуал. У кого-то он довольно короткий, а у кого-то довольно сложный и длинный. У кого что. Кому-то надо непременно почитать перед сном, кто-то не засыпает если тридцать приседаний не выполнит перед тем как лечь. Так или иначе отход ко сну у каждого происходит по своему и это не просто ЧИК - и заснул. Хотя бывает у некоторых и так.

Вот тоже самое и в работе программиста. Процесс начала работы это тоже самое. Программист не может просто сесть и начать работать точно также как вот вы не можете сказать себе "СПИ УЖЕ СКОРЕЙ!" и отключиться. И общего какого-то способа тоже нет, как нет его в ритуале засыпания.

Кто-то вот считает баранов, которые будучи вызваны к жизни этим вот самым процессом счёта вынуждены потом как-то дальше жить у нас здесь в Новой Зеландии. А кто-то фантазирует. Кто-то следит за своим дыханием, а кто-то просто прилепит чаю с ромашкой и готов.

Это ведь ещё и меняется со временем. Сегодня вот вы легли спать и всё - уже сладкие грёзы. А завтра ворочаетесь час, два, три и ну никак. Тоже самое и в работе программиста. буквально тоже самое.


Ну и что делать всвязи с этим?

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

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

Представили?

Вот это именно так выглядит для нас - программистов. БУКВАЛЬНО ТАК.

Это вам со стороны кажется что вы просто подошли и спросили который час.

А давайте я вас подойду и спрошу в три часа ночи который час?
Чего страшного-то? Ну и что такого что вы только что заснули?
Я просто спрошу, вы ответите и спите дальше. Чего такого-то?

Так легче понять я думаю будет. На таком примере.

Вот вы представляйте что от вашего сна зависит ВСЁ! Всё при всё. Вот от того как вы сегодня поспите зависит будет завтра чего дома жрать или нет. Зависит будет ваша дочть замужем или нет. Вырастет ваш сын неудачником или добьётся чего-то в жизни. Всё это зависит от того как продуктивно вы сегодня поспите.

Представили?

И вот вы собираетесь начать этот сон. Этот вот самый сон от которого ВСЁ зависит и вы это отчётливо осознаёте.

Скажите вот теперь. Как насчёт спать и одновременно немножко, краем глаза разговаривать, чуть чуть помогать сыну решать арифметику, немножко подглядывать в телевизор и чуть чуть так совсем немного съездить в магазин? Не на долго...

Как спится, сладко?

Вот теперь подумайте что происходит с программистом к которому раза два-три в час подходят и просят чего-то подсказать, чего-то помочь там вот и тут, чего-то просят его где-то заполнить, отметить и ещё о чём-то не забыть.

Вы бы так смогли КАЖДЫЙ ДЕНЬ?

Ну тоесть каждый день вот вы ложитесь спать ЗНАЯ что от вашего сна зависит всё при всё при всё и даже больше. И вот в процессе вашего сна происходит вот это всё - напоминания, запоминания, помогания, звонки, разговоры посторонние под ухом и всё такое. И так каждую ночь. Как вам такая жизнь?

Хотите?

Призодите работать программистом в нашу контору. Получите в полной мере!

Хотя не всё так трагично. Конечно есть люди которые способны кимарить просто постоянно. Водители такие бывают что чуть-ли не на каждом сфетофоре способны чуток вздремнуть. Ну вы знаете - им чуть бибикнуть приходится чтобы вернуть к жизни. Наверняка вы знакомы с такой ситуацией.

Ну так вот и программисты тоже такие бывают. Они всегда находятся в состоянии близком ко сну. Чуть не мешает никто - сразу "брык" и в сон. Не глубоко, только на чуть чуть. Особо серьёзных никаких химер не успеешь понагрезить, но чуть-чуть немножко слабо-туманных вполне успеешь. Вот в такой сон.

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

Ну потому что отвлекают постоянно. Потому что БУДЯТ же бля постоянно! Потому что люди не понимают что ты же спишь и что их ебучая менеджерская "организационная" активность она на самом деле только мешает работать. Большинство людей НЕ программистов этого не понимают.

Я надеюсь что осознав аналогию работы программиста со сном может быть люди лучше поймут как надо обходиться с программистами и откуда вообще берутся хорошие программы. Поймут наконец что вот этот ебучий ЖЖ - это то что пишу и читаю ПЕРЕД СНОМ. Вот также как вы. Вы не можете спать пока неначитаетесь или пока телевизор не насмотритесь. Не можете ведь?

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

Хотите хороших программ?

Хотите чтобы ваш муж-программист был успешен и заработал все деньги?

Хотите чтобы ваши подчинённые программисты наконец-то сделали всё как надо?

Тогда вот вам простой рецепт:

НЕ БУДИТЕ СЛИШКОМ ЧАСТО ПРОГРАММИСТА!

ya_recoder

The 501 Developer Manifesto

We are software developers who take pride in our work but choose not to be wholly defined by it.
As such, we are proud to say that we value:

• Our families over the commercial goals of business owners
• Free time over free snacks
• Living our lives over maintaining our personal brands
• Sustainable pace over muscle-man heroics
• Our personal creative projects over commercial products the world doesn't need
• Having money for nice clothes over getting free t-shirts from Microsoft
• Playing fußball in the pub with our friends over playing fußball in the office with our team leader
• Not being a dick over being a rockstar

That is to say, we value the things on the left more than we value the things on the right. And some of the things on the right aren't even on our radar.

ya_recoder

Как в старые добрые времена - чего только не запихнут в килобайт кода! Только теперь это JavaScript.

• Legend Of The Bouncing Beholder
• Tiny chess
• Tetris with sound
• WOLF1K and the rainbow characters
• Binary clock
• Mother fucking lasers
• Graphical layout engine
• Crazy multiplayer 2-sided Pong
• Morse code generator
• Pulsing 3d wires

ya_recoder

A lot of our clients are startups, and I've been noticing a recurring pattern among them:
1. Develop web application using a framework
2. Launch it
3. It gets popular, and needs to scale
4. Application breaks
5. They call us
6. We re-write the application without the framework
The framework used doesn't really matter; we've dealt with Django, Cake, Drupal, Zope, Joomla, Rails, Catalyst and even OpenACS.  Looking at this repetitive pattern, for a while I thought it was a problem; maybe people shouldn't be using frameworks if they're just going to have to throw them away.  But then I realized it wasn't a problem at all ... it's actually working very well. 
As long as the company has the right expectations.
When you're launching your web/mobile startup, time-to-market is everything.  Every day of delay until you launch is another day of spending money without any visible progress.  Further, without real users you can't start the "agile" phase of your development, because you have no feedback on which to base your design changes.  So using a framework makes all the sense in the world to get started; you can develop faster and launch faster.  It's also easier to hire staff.
Some applications never really get high-traffic or need to add high-end custom features, so even if they succeed in a niche, they can stick with the framework and be happy.  Good for them.  I have a few of these.
However, for most web applications, success means traffic and lots of data.  And not one framework I've worked with was engineered to deal with real volume.  Further, every framework was really designed to support one specific type of application and becomes harder and harder to use the further your application is from that specific application.
So once you do get some success and (hopefully) have the money to re-engineer your application, it's time to throw away the framework and redo it from scratch.
This isn't a framework issue, even, specifically.  Really, any startup should be prepared and expect to throw away version 1.0 of their application and re-do it once they know their real market and userbase.  Version 2.0 will be new code.
The problems come when a company is not prepared to throw anything away.  They keep tinkering with the framework and with their old code, trying to make it work for 100,000's of users and 100's of GB of data.  It keeps failing and causing downtime.  They try to add highly specialized features their users want and discover that the framework isn't designed to support them, and development stretches into "never complete".   They patch the framework and find they can no longer apply updates.
Now, sometimes hybrid models work where some parts of the application still use the framework and other parts don't.  I'm working on one of those now.  That means that the ability to selectively bypass it is a desirable quality in a framework.
So, if you're just starting out ... use a framework.  It doesn't matter which one, really, as long as it's well-maintained with a strong community (although some definitely work better with Postgres).  If you're scaling up, though, it's time to put the framework behind you.

ya_recoder

If you write code, write tests.

The pupil asked the master programmer:
   “When can I stop writing tests?”

The master answered:
   “When you stop writing code.”

The pupil asked:
   “When do I stop writing code?”

The master answered:
   “When you become a manager.”

The pupil trembled and asked:
   “When do I become a manager?”

The master answered:
   “When you stop writing tests.”

The pupil rushed to write some tests. He left skid marks.

If the code deserves to be written, it deserves to have tests.