10 вредных советов для начинающих разработчиков


Оглавление (нажмите, чтобы открыть):

XI Международная студенческая научная конференция Студенческий научный форум — 2020

10 советов для начинающего разработчика.

Программист – актуальная профессия в современном мире. Процент заинтересованных людей в IT-сфере растет с каждым днем по всему миру. Многие желают овладеть языками программирования, веб-технологиями и получить необходимые для будущей карьеры навыки. Однако, не все молодые разработчики удачно идут по ступеням своего профессионального развития. Делая первые шаги самостоятельного изучения программирования, у многих возникает больше вопросов, чем ответов. Что нужно знать? Как понять, как «фиксить баги»? И как сохранять мотивацию, когда задача кажется невыполнимой? Неопытному программисту не стоит паниковать.

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

1. Ставьте перед собой конкретную цель.

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

Первое, что нужно выяснить, это какова ваша конечная цель. Для чего вы хотите научиться программировать? Вы хотите научиться писать код, чтобы что? Уделите немного времени этому вопросу и подумайте над своей конечной целью. Когда у вас будет цель, вы сможете понять, что вам нужно для ее достижения.

2. Составьте план и придерживайтесь его.

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

3. Это марафон, а не спринт.

Есть много постов в блогах и видеороликов, где вам обещают, что вы научитесь программировать и найдете работу за 3-6 месяцев. Ну, это возможно, но есть множество «если». Проблема в том, что продвижение подобных идей рисует перед людьми чрезмерно оптимистичную картину того, как легко стать программистом. А когда они понимают, насколько это на самом деле сложно, наступает жестокое разочарование.

4. Побеждают медленные и настойчивые.

Некоторые люди хотят изучить как можно больше и как можно скорее. Для этого начинают заниматься по 5 часов в день после работы. Для кого-то возможно выдерживать такой темп, для других это может быть уже слишком. Есть реальная опасность выдохнуться и сдаться. А вот сдаваться как раз не надо. Нацеливайтесь на разумный прогресс. Начинайте с малого, с 30 минут или часа в день. Или 1-2 часов несколько раз в неделю. Конечно, чем больше времени вы будете уделять учебе, тем значительнее будет прогресс. Но начиная с малого, вы сможете постепенно увеличивать количество времени, которое тратите на программирование, выработав тем самым полезную привычку.

5. Не сравнивайте свой прогресс с прогрессом других людей.

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

6. Сделайте программирование своей привычкой.

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

7. Фильтруйте информацию и решайте проблемы.

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

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

8. Постоянно пробуйте создать что-нибудь новое.

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

9. Будьте готовы к поражениям.

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

Боязнь провала может привести к тому, что вы будете пытаться оставаться в «безопасности» и избегать ситуаций, в которых потенциально можете совершить ошибку. Но при таком раскладе у вас не будет такого прогресса, какой мог бы быть. Несмотря на все сложности, продолжайте двигаться вперед и испытывать новое.

10. Постоянно учитесь.

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

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


Вредные советы для фронтенд-разработчиков

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

Занимаясь разработкой
Приложениев клиентских,
Есть опасность это сделать
Неожиданно нормально.

Чтобы это не случилось,
Я бесплатно дам советы,
А то вдруг тебя припишут
К шибко умным программистам.

Несколько рекомендаций
Жизнь тебе облегчат сильно.
И клиенты будут рады,
И тимлиды одобрять.

Файлов-стилей на странице
Подключать нужно побольше,
Чтобы каждая табличка
Свой тянула css.

И не вздумай ты в угаре
Склеить стили в один файлик.
Модульность не ты придумал,
Не тебе и отменять.

Сжатие html-a,
Равно как и css-a —
Бесполезная работа
И дешевые понты.

Знает каждый сладкоежка,
Пара лишних килограммов
Никому не повредили.
С мегабайтами все так же,
Браузер от них не треснет.

Если в папке icons файлов
Набралось уже две сотни,
Знай, что все идет как надо,
Лучше много и поменьше.

Если кто неосторожно
Скажет «спрайт» тебе на ушко,
Плюнь ему ты прямо в морду,
Он не знает, что творит.

Ты, как опытный работник,
Думай наперед про бизнес
И представь, как будет сложно
В этом непонятном «спрайте»
Заменить одну иконку.

А зеленому коллеге,
Нахлебавшемуся смузи,
Ты скажи авторитетно,
Keep It Simple что-то там.

Если делать галерею,
У которой умный принцип
Не грузить картинки сразу,
А подтягивать аяксом,
То не вздумай ты превьюшки
Предварительно нарезать.

В этом смысл технологий —
Стырить в интернете либу,
Как попало ее внедрить
И тимлиду доложить.

Вот аякс, а вот картинка,
Ее мягко подгружает
Либа только по запросу.

Ну а то, что для превьюшек
20 мегабайт скачалось —
Это мелкие нюансы,
Ты вообще не виноват.

Когда блоки ты верстаешь,
Делай вложенность побольше,
Больше дивов внутри спанов,
Больше вложенных таблиц.

Классы называй длиннее,
Задавай всем элементам,
Чтобы каждый распоследний
Span имел свой личный класс.

Удивленные вопросы,
На хрена все это надо,
Ты устало игнорируй,
Говори, что это БЭМ.

Если кто-то съехал крышей,
Посягает на святое,
Предлагает на проекте
Не использовать jquery,

Бунтаря чмырить не нужно,
Просто отвечай мерзавцу,
Чтобы завалил хлебало,
Ведь аналогов append-у
Не придумано еще.

Мама с детства говорила,
Кашу маслом не испортить.
Мудрость данная сгодится
Абсолютно в любой сфере,
И фронтенд не исключенье.

Все клиенты очень любят
Анимации на сайте,
Чтобы блоки при ресайзах
Запускались дружно в пляс.

Принимая смело вызов
На такой крутой задаче,
Откажись от css-а,
От ужасных media queries,
От transitions и keyframes.

Яваскрипт тебе поможет
Оживить чего угодно,
Анимации такие,
Что повесится мозилла
И в углу заплачет хром.

Эт проблема небольшая,
Ведь известно, у клиентов
Всех давно стоят макбуки,
И процессоры i9
Легко справятся с нагрузкой.


Ради плавных анимаций
Больше скроллов и ресайзов
Вызывай на каждый чих.

Мастер Йода рекомендует:  Кэширование с помощью eaccelerator PHP

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

Всем фронтендщикам известно,
Что web tools придумал дьявол,
Чтобы мог смотреть манагер
Скорости загрузки сайта.

На претензии смешные,
Мол, что грузится минуту,
Отвечай не сомневаясь,
Что виновен слабый ноут,
Ведь на нем оперативы
Всего 32 гига.

Для нормальной же работы
Расчудеснейшего сайта
Нужно просто купить сервер,
На него nginx поставить,
php седьмой, конечно,
Базу PostgreSql.

Стоит этот сервер мало,
Тысяч 20 или 40.
То ли в месяц, то ли в день —
Ты такими мелочами
Голову не забиваешь.

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

Это есть саморазвитье,
То, о чем радеет фирма
И советует тимлид.

Ну а ты, как честный прогер,
Эти нанотехнологьи
Добросовестно применишь,
И все будет хорошо.

Вот. С концовками у меня всегда туго. Чувствую, еще много так могу накатать, но хз, как прекращать. Полторы сотни строк получилось, прям не советы, а Евгений Онегин. Правда, без единой рифмы =)

Надеюсь, этим советам вы не последуете, а будете делать ровно наоборот =)
Адекватную статью (хотя кто уже поверит) по оптимизации фронтенда читайте здесь

10 вредных советов начинающему водителю

1. Можно не учиться — водительское удостоверение покупается

В принципе, это не заблуждение — еще не так давно в органах ГИБДД процветала коррупция такого уровня, что за деньги водительское удостоверение разве что на дом не приносили. Хотя бывало и такое.

В интернете до сих пор много объявлений об услугах по продаже водительских удостоверений. Но это в подавляющем числе низкопробные подделки, а фальшивку раскусит любой инспектор ДПС. А дальше последует неотвратимое наказание, причем уголовное.

2. Выбор автошколы не важен

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

Во-первых, на рынке до сих пор присутствуют «автошколы», которые не прошли всех необходимых проверок, а их лицензии просрочены. В ГИБДД попросту не допустят до экзаменов человека, который прошел обучение в таком заведении. Во-вторых, не все автошколы учат одинаково. Большинство лишь готовят к экзаменам в ГИБДД, но есть учебные заведения, где ученик выходит из стен действительно водителем, а не человеком, натасканным для сдачи экзамена.

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

3. Заниматься — необязательно

Еще одно распространенное мнение: главное не прогуливать лекции, а заниматься в автошколе совсем необязательно. Ведь деньги заплачены, значит учебное заведение обязано обеспечить ученику сдачу экзаменов в ГИБДД.

Но перед экзаменом в ГИБДД предстоит внутренний, самой автошколы. И если не учиться как следует, то завалить его — просто. А значит придется платить дополнительные деньги за пересдачу. На лекциях помимо тех знаний, без которых не сдать экзамен, ученикам зачастую рассказывают и о маленьких хитростях, о приемах и навыках, не входящих в «обязательную программу». И такие знания для новичка очень ценны.

4. Первый автомобиль должен быть «на ручке»

Первый автомобиль нужно выбирать, в первую очередь, исходя из бюджета и здравого смысла. Если есть деньги на новую машину, то зачем покупать подержанную, у которой еще может оказаться и мутная история? Зачем вам механика, если вы собираетесь всю жизнь ездить на двухпедальной машине? Ну и наконец, уж точно не стоит брать старые Жигули или иномарку в возрасте вашей бабушки. Мы бы рекомендовали взять новый или подержанный в возрасте до трех лет, простой и относительно надежный автомобиль. Благо такие на рынке еще остались.

5. Первая поездка должна быть в пробке

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

6. Обслуживаться надо, когда сам решишь


Многие, особенно те, кто застал времена, когда автомобили обслуживали и чинили сами владельцы, говорят новичкам, что плановое техобслуживание автомобиля — заговор маркетологов. Дескать, и масло, и фильтры могут «проходить» гораздо дольше, чем межсервисные интервалы, заявленные производителем. В качестве примеров приводятся все те же Жигули или старые «американцы».

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

7. Прогревать машину не требуется

А вот тут как раз полно советчиков, начитавшихся инструкций к автомобилям и не нашедших там пункта о необходимости прогрева автомобиля. Они говорят, что можно ехать сразу после поворота ключа в замке зажигания.

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

8. Стояночный тормоз должен быть затянут

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

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

9. Правила дорожного движения – для дураков

Ездить нужно, соблюдая все пункты Правил дорожного движения, даже если некоторые кажутся нелепыми. Помимо банального «ПДД написаны кровью» хочется напомнить о том, что камер на дорогах становится все больше. И фиксируют они все новые и новые нарушения.

10. ГИБДД занимается только «разводами»

Что все гаишники взяточники и на каждом углу вас будет поджидать «развод» с их стороны, новичок слышит со всех сторон. И морально действительно готов к тому, что инспектор ДПС обязательно окажется вымогателем.

На самом деле в Госавтоинспекции серьезно закрутили гайки. Низовая коррупция, конечно, до конца не побеждена, но носит эпизодический характер. Задумайтесь сами — если вы ничего не нарушали (см. предыдущий пункт), то как инспектору удастся получить взятку?

Вредные советы для начинающих разработчиков софта.

AngelOfLove

Новорег

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

  1. Будьте краткими. Все связанные между собой вещи располагайте на одной строчке.
  2. Используйте однобуквенные переменные. Добавляйте к ним цифры, если буквы закончатся.
  3. Не ставьте пробелы. Вообще. Они только для нубов.
  4. Сначала пишите код, только потом думайте. Не стоит строить планы, пока в них нет потребности.
  5. Никогда не оправдывайтесь. Если менеджеры не понимают чего-либо, то почему должны вы?
  6. Если ваши расчёты не сходятся, просто прибавьте единицу и двигайтесь дальше.
  7. Если у вас есть сомнения, всегда обвиняйте железо. Эти чёртовы микросхемы такие сложные.
  8. Когда программа не компилируется, просто продолжайте писать код. Как-нибудь само починится.
  9. Если какая-нибудь функция не работает, замените её на три других. Вам лучше знать, как должно быть.
  10. Никогда не тестируйте. Если вы написали код, то он работает.

10 вредных советов для начинающего вейпера

Не особо разбираясь в теме, попросите посоветовать «Вейб» у консультанта магазина;

Не слушая ответа, попросите что подешевле и просто купите Eleaf iJust 2;

Не приобретайте жидкости, они же с завода. Это дорого. Просто возьмите самую дешевую основу и накапайте туда каких-нибудь ароматизаторов по какому-нибудь рецепту, обязательно измерять ароматизаторы по каплям, каким-нибудь средним, как рекомендует автор рецепта;

Получившуюся жидкость поставьте на батарею, или выставьте на солнце, ведь говорят что это помогает настаиванию;

Залейте жидкость в бак, не пропитывал испаритель. Зачем? Всё же продумано. А как сожжёте испаритель – съешьте мозг продавца с требованием «вернуть деньги, потому что вейп не получается»;

Получив отказ, расстройтесь и купите обслуживаемый испаритель. Теперь вы прошаренный вейпер, на обслуге;

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


Что-то получилось! Ура! Теперь-то вы настоящий вейпер! Можно выходить в свет;

Самый важный пункт! Идя по улице-выпускайте клубы своего вонючего пара от неудавшегося самозамесы в лицо прохожим, парите в транспорте (метро, автобусе), обязательно парить на остановках и в поликлинике. На все претензии со стороны прохожих кричите, что это пар и он на 95% безопаснее дыма!

Обязательно возмущайтесь любым попыткам регулировать вейпинг со стороны государства, подписывайте петиции, основываясь на своём опыте. Устройте митинг во дворе дома, Заставьте жильцов подписать обращение к президенту.

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

15 вредных советов для PM: как не надо управлять творческой командой

Мы подготовили вредные советы для менеджера проектов, которым ни в коем случае нельзя следовать.

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

Совет №1

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

Мастер Йода рекомендует:  Красивый текст на мокром окне

Что тут не так

Вы можете руководить проектом, когда не понимаете его целей? Можете, только результат будет никакой. Вот и дизайнер — это не про «иди сделай макет», а про цель и решение конкретных задач, которые правильно поставить придется вам. От этого зависит результат.

Совет №2

Не пытайтесь заинтересовать сотрудника. Если ему не интересно то, что он делает, это не ваши проблемы. Ну и что, если все проекты одинаковые и ему скучно. Вы же не должны думать еще и об этом, правда?

Что тут не так

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

Совет №3

Не надо давать сотруднику всю информацию о проекте. Расскажите только основное, дальше пусть сам додумывает. Как это он не понимает, что нужно заказчику? Пусть подумает, он же дизайнер, а не вы.

Что тут не так

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

Совет №4

Не думайте о психологическом климате в команде. У вас что, других дел нет? Пусть спорят, ругаются, ненавидят друг друга. Это их дело. Все равно это никак не отразится на работе.

Что тут не так

Если ваша команда постоянно выясняет отношения, то у нее просто нет времени, чтобы полноценно работать. Менеджер должен быть немножко психологом, чтобы чувствовать и грамотно решать конфликтные ситуации.

Совет №5

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

Что тут не так

Если вам не нравится результат работы дизайнера, это не повод для него все переделать. Зато ― повод обидеться. Критикуйте правильно: сначала похвалите за то, что получилось хорошо. А потом уже объясните, какие есть минусы, и если знаете, подскажите, что и как исправить.


Совет №6

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

Что тут не так

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

Совет №7

Не надо выяснять, правильно ли сотрудник понял задачу. Вы все хорошо объяснили. Иначе и быть не может. Остальное ― его забота. Не понравится результат — переделает. И так — до тех пор, пока вы не будете довольны.

Что тут не так

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

Совет №8

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

Что тут не так

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

Совет №9

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

Что тут не так

Указать на ошибки ― это пустая трата времени, если вы оставляете внесение правок на совести сотрудника. Например, дизайнер может не хотеть что-то менять, но согласится с вами, чтобы не идти на конфликт. Вы расслабитесь и отпустите ситуацию. И очень скоро об этом пожалеете, когда поймете, что в готовом проекте все осталось по-старому.

Совет №10

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

Что тут не так

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

Совет №11

Сами вносите правки в макет. Не зря же вы посмотрели те два видео по основам Photoshop. Как раз — подходящий момент, чтобы применить полученные знания. А что дизайнер? Ему так даже лучше ― меньше работы делать.

Что тут не так

Представьте, что дизайнер вмешивается в процесс управления командой. Ну как, нравится? Даже если вам очень хочется попробовать себя в дизайне, лучше поискать для этого другое время и место. А на проекте пусть каждый занимается своим делом.

Совет №12

Не забивайте себе голову всякими мелочами, например, развитием и совершенствованием сотрудников. Хотят развиваться? Пусть занимаются этим вне работы и за свой счет. У вас и так слишком много забот и расходов.

Что тут не так


Менеджер проекта отвечает за результат головой. А чем профессиональнее команда, тем больше шансов на успех. Значит, вы как никто должны быть заинтересованы в развитие ваших сотрудников. Иначе они рано или поздно уйдут.

Совет №13

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

Что тут не так

Любой человек хочет, чтобы его ценили. Для творческих людей это важно вдвойне. Если сотрудник принес команде классную идею, скажите ему об этом. Покажите, что цените его мнение.

Совет №14

Расслабьтесь сами и оставьте в покое команду. Дисциплина ― это не главное в работе. Пусть делают, как и что хотят. Иногда можете напоминать про сроки, а остальное пустите на самотек. Все ведь так работают — и ничего.

Что тут не так

Есть менеджеры, которые любят критиковать и дергать без повода. А есть обратная история ― когда руководитель проекта ленится или боится управлять командой. Тогда на проекте начинается анархия: никто не стремится к результату. А зачем? Если менеджеру все равно, то и сотрудники берут с него пример. Рабочий процесс так не построить. Менеджер должен быть требовательным и уметь добиться от сотрудника нужного результата.

Совет №15

Всегда держитесь отдельно от команды. Смотрите на сотрудников свысока. Делайте, как вам удобно, а что они там думают и чувствуют, ― это не важно.

Что тут не так

Если менеджер считает себя выше других, а еще и публично это демонстрирует, то о гармонии в команде можно забыть. В лучшем случае сотрудники начнут его бояться, в худшем ― ненавидеть. А если команда не уважает руководителя, то работу свою будет делать по принципу «чтобы отстал». Такой проект далеко не уедет. Поэтому хороший менеджер всегда найдет золотую середину: быть лучшим другом для всех не обязательно, но вот уважать и ценить по достоинству придется.

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

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

Как и где этому научиться? Нужно заложить базу: много читать, слушать и смотреть лекции. Этого хватит, чтобы войти в сферу и примерно понять, кто есть кто. А это уже развитие. Но всегда лучше, когда есть возможность «снять с руки»: найти практика, который укажет, какую дорогу выбрать, кого с собой взять и как не заблудиться в мире digital.

10 вредных советов для начинающих своё дело заточников

В сети очень много советов для тех, кто начинает своё дело, в том числе для независимых предпринимателей-заточников (как у меня в этой статье — ссылка). Люди делятся своими советами о том, как наработать базу клиентов, как получить наибольший доход, и в этом нет совершенно ничего плохого. С другой стороны, всё, в чём вы преуспели, может постепенно загибаться под тяжестью ошибок, которые вы совершаете и даже не замечаете этого. Множество заточников, которые совсем недавно обучились или же, наоборот, довольно долго нарабатывали опыт, работая на «дядю», терпят фиаско при попытке организовать своё дело. Я решил пойти от обратного и предложить несколько вредных советов, которые помогут вам в этом деле — потерпеть фиаско и разориться.

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

1. Помни, что заточка не бизнес, заточка — это призвание.

2. Лишь нарабатывая опыт долгие годы, терпя лишения и превратности судьбы, можно заработать на кусок хлеба с маслом.

3. Найди каморку поскромнее и подальше от центра города. Там ты сможешь спокойно творить, не заботясь о высокой плате за аренду, а клиенты сами тебя найдут.

4. Ты один знаешь, как должен быть заточен инструмент. Не слушай никогда своих клиентов, ведь это ты заточник! Откуда им знать, как надо затачивать? Они же стригут волосы и делают маникюр, а не обрабатывают металл.

Мастер Йода рекомендует:  Как использовать уникальные индексы в MySQL и других базах данных

5. То, чему научил тебя твой наставник, — единственно правильный способ заточки. Кто с тобой не согласен — ошибаются.

6. Если клиент выражает недовольство твоей работой, постарайся как можно быстрее от него избавиться. Помни правило № 4, а также то, что мастеров маникюра и парикмахеров много, а ты один. От одного недовольного клиента тебе не убудет.

7. Никогда не просчитывай целесообразность и экономическую выгоду от методов заточки. Помни правило № 1.

8. Главное в работе заточника — качество заточки. Обслуживание клиента, его комфорт — мелочи, на которые не стоит обращать внимания.


9. Бухгалтерия и порядок в финансовых вопросах — нет ничего проще! Постарайся делать всё сам, так ты сможешь неплохо сэкономить.

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

10 вредных советов для начинающих разработчиков

Вредные советы 1

Книга для непослушных детей и их родителей

Послушным детям читать запрещается!

Недавно учёные открыли, что на свете бывают непослушные дети, которые всё делают наоборот. Им дают полезный совет: «Умывайтесь по утрам» – они берут и не умываются. Им говорят: «Здоровайтесь друг с другом» – они тут же начинают не здороваться. Учёные придумали, что таким детям нужно давать не полезные, а вредные советы. Они всё сделают наоборот, и получится как раз правильно.

Советы программистам (вредные советы)

В попытках объяснения происходящему наткнулся на вот такой вариант объяснения.

Как писать неподдерживаемый код

Вы хотите чтобы Вы были самым ценным сотрудником компании? Чтобы Вас носили на руках? Тогда эта статья для Вас. Эти знания передаются из поколения в поколение и представляют особую ценность в умелых руках.
Данная статья является переводом (с большой долей подсматривания в megamozg ) известной статьи с небольшим приложением на мир 1С.

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

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

Общие правила. Соглашения

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

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

Пример:
Как правило, предполагается что процелура с названием ДополнитьСтруктуруНаСервере(Структура) дополняет некоторые данные в переданную структуру. Достаточно слегка изменить процедуру с учетом особенной платформы и у программиста уже будет некоторая непонятка происходящего:

Прочитав только процедуру «Тест_1» можно ожидать что на выходе вы получите структуру с ключами А, Б и В. Но не тут то было. На первый взгляд все сделано верно, даже объявление переменной с использованием знач соответствует правилам. В тоже время, вы можете подобный код писать с директивой &НаКлиенте и получить абсолютно ожидаемое поведение и структуру с тремя ключами. Возможно именно подобный пример сделает пару часов работы вашего коллеги особенно приятными.

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

Возможно вам стоит приобрести книгу «Как правильно назвать ребенка. 40000 русских и иностанных имен» и у вас никога не будет проблем с именованием переменных. В тоже время «Йцук» прекрасное имя и легко набирается. Если тем не менее вы до сих пор придумываете имена переменных, попробуйте «авыф», «апро», ну или наконец купите себе клавиатуру Дворака.

2. Однобуквенные имена переменных

Если вы называете свои переменные «и», «а», «к», их будет невозможно искать в редакторе. Кроме того, никто не догадается для чего они нужны. Если кто-нибудь упомянет о нарушении традиции называть счетчики циклов простыми буквами, чтимой со времен Fortran, напомните о том, что испанская инквизиция делала с еретиками. Более того, используйте однобуквенные переменные где угодно, кроме счетчиков циклов.

3. «Случайные» опечатки

Если же вы вынуждены использовать описательные переменные, просто «очепятайте» их. Поверьте, неправильное написание в какой-то функции или имени переменной способно свести на нет все удобства использования, не без этого, неудобного редактора от 1С. Добавляйте интернационализацию по вкусу.

4. Будьте абстракты

Используйте абстрактные слова и понятия, вроде «все», «это», «данные», «ссылка» и т.п, аналогично можете использовать цифры: Заполнить1(), ПосчитатьВсе(), ПроверитьЭто().

5. Сокращения (Акронимы)


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

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

7. Избегайте глоссария проекта

Запомните: написания глоссария — непрофессиональное нарушение принципа структурного дизайна, известного как «сокрытие информации». Если же вы вынуждены его писать, постарайтесь использовать рекурсивные определения. Дразните своего читателя, притворяясь, что вы даете информацию там, где ее нет ни грамма. Формулируйте ваши пустопорожние сентенции так, чтобы читатель испытывал чувство вины за неспособность понять что вы хотите сказать.

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

8. Используйте правила других языков

Отлично подойдет любой язык: Клингонский, Вестрон, Дотракийский и даже родной язык ближайшего гоп-стоп района. Вполне можно вспомнить как в детстве вы придумывали слова разбивая на слоги и добавляя любой понравившийся вам слог. Таким образом, вы поддерживаете мир во всем мире.

9. Использование регистра

Можно сколько угодно спорить о правилах 1С относительно прописных букв, но намного лучше ввести собственное правило. Например: выделять псевдослова в переменных или случайным образом выделять прописные буквы. Например: ПараллелоГрамм.

10. Повторное использование переменных

Во всех случаях, допускаемых платформой, давайте переменным, глобальным, клиентским или серверным методам одинаковые имена. Желательно повторно использовать имена реквизитов внутри процедур в качестве имен параметров, переданных для обработки. Это делается для того, чтобы сопровождающий внимательно изучил область действия каждой переменной. Особенно приятно, передавая в функцию переменные А и Б, в объявлении функции поменять их местами; использовать одну переменную для разных целей или просто слегка менять назначение.

11. Подчеркивание, ваш надежный друг

Используйте _и__ в качестве имен переменных. Особенно неплохо работает приписывание их в начало или конец имени переменных, реквизитов или методов. Более того, это в целом не противоречит стандартам 1С.

Пишите на разных языках. Если все в вашей организации пишут на русском, пишите на английском. Можете применять смешанно, например переменные называть на русском, а методы на английском.

13. Специальные или эмоциональные имена

Отлично подходят имена которые выдают себя за определенные объекты: Параметр = (счетфактура — накладная) / проценты. Также можно выбирать имена переменных с неуместным эмоциональным оттенком: Хрень = (половинаХрени — втораяПоловина) / СуперДоля.

14. Игнорируйте соглашения

Это самое простое, компилятор на это не отреагирует. Также можно предложить свои собственные правила, тогда можно обвинять окружающих в их несоблюдении.

15. Ложные имена

Убедитесь, что каждый метод делает чуть больше (или меньше), чем предполагает его название. В качестве простого примера метод ПроверитьЗаполнениеСчетФактуры(СчетФактура) в качестве побочного эффекта может записывать текущую версию документа в базу данных.

16. Ограничения возможностей человека

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

Вредные советы для начинающих разработчиков софта.

AngelOfLove

Новорег

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

  1. Будьте краткими. Все связанные между собой вещи располагайте на одной строчке.
  2. Используйте однобуквенные переменные. Добавляйте к ним цифры, если буквы закончатся.
  3. Не ставьте пробелы. Вообще. Они только для нубов.
  4. Сначала пишите код, только потом думайте. Не стоит строить планы, пока в них нет потребности.
  5. Никогда не оправдывайтесь. Если менеджеры не понимают чего-либо, то почему должны вы?
  6. Если ваши расчёты не сходятся, просто прибавьте единицу и двигайтесь дальше.
  7. Если у вас есть сомнения, всегда обвиняйте железо. Эти чёртовы микросхемы такие сложные.
  8. Когда программа не компилируется, просто продолжайте писать код. Как-нибудь само починится.
  9. Если какая-нибудь функция не работает, замените её на три других. Вам лучше знать, как должно быть.
  10. Никогда не тестируйте. Если вы написали код, то он работает.
Добавить комментарий