Телеграмм чат группы erlangrus страница 2613

У меня на предыдущей работе был парень, который не мог просто фиксить баги. Он смотрел блейм и, только если сотрудник уже уволился, кидал в общий чат и писал что-то типа "Ну тупыыые"

источник

15:43пожаловаться #7

ŹR

Źmićer Rubinštejn in ErlangRus

Но либо вы решили держать лицо и марку - либо нет

источник

15:43пожаловаться #8

ММ

Михаил Малюк in ErlangRus

Źmićer Rubinštejn

Не, ты же не с врагами работаешь, а с друзьями

при принципиальных друзьях порой сидишь, как в траншее, настолько они принципиальные. а враги что? врагам пофиг

источник

15:44пожаловаться #9

AN

Alexey Novoselov in ErlangRus

запустил rebar3 fmt и во всех проблемах виноват ты))

источник

15:44пожаловаться #10

AN

Alexey Novoselov in ErlangRus

так что в идеале надо по-умолчанию весь код считать своим

источник

15:45пожаловаться #11

AN

Alexey Novoselov in ErlangRus

и исправлять говно. И другие подтянутся...

источник

15:46пожаловаться #12

ML

Maksim Lapshin in ErlangRus

Aleksey Kluchnikov

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

> Мое личное мнение что на скольнибудь большом долгосрочном проекте надо работать со СВОИМ кодом.

ты просто продолжаешь жечь напалмом.

СВОЙ код. Общий сервер разработки, который настраивает админ.

Дальше что? Хорошо проработанные четкие спецификации по которым можно идти программировать?

источник

15:46пожаловаться #13

AK

Aleksey Kluchnikov in ErlangRus

Maksim Lapshin

> Мое личное мнение что на скольнибудь большом долгосрочном проекте надо работать со СВОИМ кодом.

ты просто продолжаешь жечь напалмом.

СВОЙ код. Общий сервер разработки, который настраивает админ.

Дальше что? Хорошо проработанные четкие спецификации по которым можно идти программировать?

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

источник

15:48пожаловаться #14

AK

Aleksey Kluchnikov in ErlangRus

И я специально написал что это мое мнение

источник

15:49пожаловаться #15

AK

Aleksey Kluchnikov in ErlangRus

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

источник

15:50пожаловаться #16

LL

Lama Lover in ErlangRus

Aleksey Kluchnikov

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

А как же bus factor ?

источник

15:51пожаловаться #17

ML

Maksim Lapshin in ErlangRus

Aleksey Kluchnikov

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

>с разделением труда полюбому проще и результат лучше

сколько времени и человеколет в проектах? Ты ими сам рулил?

источник

15:52пожаловаться #18

AK

Aleksey Kluchnikov in ErlangRus

я их делал и смотрел как соседи делают

источник

15:52пожаловаться #19

AK

Aleksey Kluchnikov in ErlangRus

18лет вроде

источник

15:52пожаловаться #20