bookmark_borderDevelopers, developers, developers, developers!

You are a dev. You find a job. You get a PC. It’s slow. It lacks the software which allows you to be productive. Half of the internet is blocked. You can’t choose your favorite keyboard or mouse or chair. Sounds familiar?

5S

Japan has a fascinating culture. Esthetics, order, industriousness are its strengths. One of the biggest achievements of modern Japan is its automotive industry. American car manufacturing companies, with the great Detroit and Ford’s assembly line, have been one of the landmarks of USA industrial power. These enterprises had decades of experience, America won the war but despite this in the 80s Japanese took over the automotive industry. Toyota production system became famous and the whole world looked at Japanese organizational techniques to find inspiration.

One of the elements of Japanese culture in this field is 5S. Long story short, it’s the organization of a workplace where:

  • useless tools and items are removed
  • unnecessary move and effort of workers is minimized
  • workplaces are kept tidy and organized

Implementing these principles helps to create a safe and effective workplace. It improves the efficiency of a whole company without putting a strain on workers.

Alcoa

Alcoa is one of the biggest aluminum producers in the world. Charles Duhigg in his famous book, the Power of Habit, described an interesting story about the company. Once upon a time, the new CEO has been nominated. His name was Paul O’Neill. He shocked stakeholders on his inauguration speech because instead of describing his plan to increase effectiveness, profit, and reduce cost, he gave a talk about increasing workplace safety.

 O’Neill managed Alcoa from 1987 to 1999. During that time period, the market capitalization skyrocketed from 3 to 27 billion USD, while net income went up from 200 million to almost 1.5 billion USD.

Was it money saved on industrial accidents?

Obviously not. The money was wasted because of bad organization. Workplaces have been badly organized, they posed risk for workers, reporting the problems was far from perfect and the whole organization suffered. O’Neill has introduced the pressure for improvement of the production process. Workplace safety was metrics of perfection. As we can see from the results – it was a proper one.

The workplace of software engineer

Software development and IT industries obsessed with optimization. New frameworks which allows us to work faster. New processors, more RAM, more storage. Faster algorithms. CPUs generating more FPS. We continuously believe that we can make anything better, quicker, cheaper and more efficient.

A software engineer, when confronted with the job, tries to optimize it. If the tasks are repeatable, a developer will try to automate it. If something takes too long, the engineer will figure out how to do it quicker, using a different approach.

What then can be more annoying and demotivating for a developer than the situation where something slows him down and he can’t get rid of it!

The amount of these obstacles is surprisingly substantial in most corporate workplaces. Let me give you a few examples:

  • our development workstation has too less memory / too slow processor / too small hard drive
  • the internet connection is slow (for example due to proxy)
  • antivirus software dramatically slows down our computer
  • company policy blocks some pages (for example youtube, where we can find a tutorial to solve the technical issue)
  • granting access rights takes ages (for example, to perform some task we need access to system X, but it must be accepted by three managers, which takes three weeks and blocks our)
  • the company does not buy some tools or does it very slowly (for example we need a new testing tool in a week when we start the project, but we can order only during next fiscal year starting next few months)
  • repairing broken hardware takes very long (personally I waited two weeks until my workstation has been fixed)

I remember one manager in a big company wondering how it’s possible that startups are more efficient while they have smaller budgets so theoretically they should have worse engineers. My experience tells me the reason is the corporate inertia, when all the procedures mentioned above slow down everything sometimes to gargantuan extent.

Flow

Except for technical aspects, we need to remember also about the ergonomics of the developer’s workplace. Many companies buy the same chairs, keyboards, desks, monitors, and other gear for all employees. It’s understandable and usually, these things are of good quality. However, there always be some amount of people – some unusually short, others obese, tall or sensitive – who will suffer from these default solutions. They will have headaches, sore eyes, the pain of their wrists. You can be sure they will have a problem doing the most important thing in the work of the developer – to focus.

The software engineer, who doesn’t focus, burns company money. Getting the flow is not as easy as going to the office every day. Talkative colleagues, lots of meetings interrupting our focus during the day, uncomfortable chair – all of this can ruin our flow.

Developer eXperience

User experience became big thing. Every company knows now how important UX is and almost all enterprises producing software have UX experts in their teams.

Analogically we should adopt the idea of developer experience, DX. The lower developer experience in the company and project, the more money will be burned, the staff turnover will be greater and the team’s output will be minuscule. On the other hand – awesome developer experience will bring us great experts at a lower price, will give us a productivity boost and we will not need to constantly recruit new team members because old ones decided to quit.

Last but not least, let’s remember – Microsoft always cared about developers 🙂

bookmark_borderUser experience? Developer experience!

Zatrudniasz się jako programista. Dostajesz powolny komputer. Nie ma na nim oprogramowania, które pozwala na wydajną pracę. Sporo stron w internecie jest zablokowanych. Nie możesz wybrać sobie klawiatury ani myszy, krzesła też wszyscy mają takie same. Brzmi znajomo?

5S

Japonia posiada interesującą kulturę. Estetyka, porządek, pracowitość – to bez wątpienia ciekawy kraj. Jednym z jego wielkich sukcesów jest motoryzacja. Amerykański przemysł samochodowy – z legendarnym Detroit, z linią produkcyjną w fabrykach Forda – był dumą Stanów Zjednoczonych. Mimo wygranej wojny i lat doświadczeń, w latach 80 przegrał z Japońską motoryzacją, a System Produkcyjny Toyoty wszedł do podręczników organizacji i zarządzania.

Jednym z elementów Japońskiej kultury w tym obszarze jest 5S. Nie wchodząc w szczegóły, jest to organizacja miejsca pracy polegająca m.in. na:

  • usunięciu zbędnych przedmiotów
  • ograniczeniu zbędnego ruchu i wysiłku pracowników
  • utrzymaniu stanowisk pracy w czystości

Wdrożenie tych zasad pomaga stworzyć bezpieczne i efektywne miejsce pracy. Nie trzeba mówić, że pomaga to całej organizacji w utrzymaniu wydajności – co istotne, bez zwiększania wysiłku pracowników.

Alcoa

Alcoa to jeden z największych producentów aluminium na świecie. Ciekawą historię o firmie opisał Charles Duhigg w Sile nawyku. Otóż swego czasu pojawił się w Alcoa nowy CEO – Paul O’Neill. Po nominacji na stanowisko prezesa zaskoczył udziałowców, bo w swoim przemówieniu inauguracyjnym skupił się nie na wynikach, opłacalności biznesu, planach rozwoju, ale… na bezpieczeństwie pracowników. Było to jedyne, co poruszył. Zmniejszenie liczby wypadków przy pracy.

O’Neill zarządzał firmą od 1987 do 1999 roku. W tym czasie wartość rynkowa firmy wzrosła z 3 do ponad 27 miliardów dolarów, a dochód netto wzrósł z 200 milionów do prawie półtora miliarda.

Czy te pieniądze Alcoa traciła na wypadkach przy pracy?

Oczywiście, że nie. Traciła je z powodu złej, niedbałej, niechlujnej organizacji stanowisk pracy. Na tym, że były nieprzemyślane, nieergonomiczne i były takie od lat z powodu złych procesów oraz komunikacji. O’Neill wprowadził presję na ulepszenie organizacji produkcji, bezpieczeństwo stanowiska pracy było metryką doskonałości. Jak widać – skuteczną.

Ciągle im mało

Tak, wiem, jesteśmy roszczeniowi. Mamy game roomy, podnoszone biurka, dwa monitory i owocowe czwartki, ale ciągle nam mało – snujemy się po kolejnych firmach w poszukiwaniu Bóg jeden wie czego, ale pewnie pieniędzy, których ciągle nam mało.

Może tak jest.

Co jednak, jeśli nie?

Co jeśli jest jakaś głębsza przyczyna migracji koderów?

Stanowisko pracy programisty

W programowaniu duży nacisk kładzie się na optymalizację. Motywem przewodnim tej branży od lat jest efektywność. Nowe frameworki, które pozwolą zrobić to samo szybciej. Szybsze procesory, więcej pamięci, potężniejsze dyski. Algorytmy, które liczą sprawniej, lepiej niż starsze. Karty graficzne, które generują więcej klatek na sekundę. Branża technologiczna oparta jest o wiarę w to, że da się lepiej i szybciej, taniej i sprawniej.

Programista, kiedy siada do pracy, próbuje ją sobie zoptymalizować. Jeśli musi wykonywać powtarzalną czynność – napisze skrypt. Jeśli coś zajmuje dużo czasu – pomyśli jak zrobić to szybciej, innym sposobem.

Co więc może być bardziej irytującego dla programisty od sytuacji, w której coś spowalnia jego pracę, a jednocześnie nie da się obejść, usunąć, poprawić?

Tych mniejszych lub większych przeszkód na drodze do wydajności, w wielu miejscach pracy, jest zaskakująco dużo. Oto kilka przykładów:

  • komputer, na którym programujemy ma za mało pamięci / za wolny procesor / za mały dysk
  • internet w firmie działa powoli, np. przez proxy
  • oprogramowanie antywirusowe dramatycznie spowalnia komputer (choćby od czasu do czasu)
  • polityka firmy blokuje pewne strony (np. youtube, gdzie możemy znaleźć tutorial do rozwiązania problemu)
  • przyznanie praw dostępu przeciąga się w nieskończoność (np. by wykonać zadanie potrzebujemy dostępu do systemu x, ale musi je zaakceptować trzech managerów, a to trwa trzy tygodnie)
  • firma nie kupuje pewnych narzędzi albo robi to bardzo powoli (np. potrzeba jakiegoś narzędzia na za tydzień, ale akceptacja i zamówienie zajmuje trzy miesiące)
  • naprawa zepsutego sprzętu trwa bardzo długo (osobiście raz czekałem dwa tygodnie na naprawę mojego firmowego komputera)

Pamiętam pewnego managera, który dziwił się, jak to jest możliwe, że startupy są wydajniejsze? – przecież mają nieraz mniejsze budżety, czyli teoretycznie gorszych pracowników, a jednak dostarczają szybciej. Z mojej praktyki wynika, że to właśnie narzut organizacyjny zabija efektywność…

Skupienie

Poza czysto technicznym aspektem, jakim jest wydajność sprzętu i dostępność narzędzi warto jednak pamiętać również o ergonomii miejsca pracy programisty. W jej skład wchodzą zarówno wygodne, dostosowane do konkretnej osoby krzesło, czy klawiatura, jak i otoczenie.

W wielu firmach kupuje się kilkaset takich samych krzeseł, biurek, monitorów, klawiatur i przydziela każdemu nowemu programiście. To zrozumiałe. Stan tych narzędzi jest zresztą zazwyczaj bardzo dobry. Jest jednak część osób – może niskich, może otyłych, może wysokich albo czułych w jakimś sensie – którym taki standard będzie utrudniał życie. Będzie ich bolał kark albo nadgarstki, będą ich bolały oczy. Trudno wtedy o najważniejszą rzecz w pracy programisty – skupienie.

Programista, jeśli nie może się skupić, trwoni pieniądze firmy. Skupienie zaś nie jest tak łatwe jak przyjście do biura. Rozmowni koledzy, liczne spotkania w trakcie dnia, niewygodne krzesło, zapach ryby atakujący nas z biurowej kuchni… wszystko to może zburzyć delikatną materię flow.

DX

User experience stało się głośną ideą. Na tyle głośną, że specjaliści projektujący interfejsy wygodne dla użytkownika zagościli w wielu firmach tworzących oprogramowanie. Każdy dziś wie już, że ergonomia aplikacji jest ważna.

Analogicznie, należałoby stworzyć ideę DX – developer experience. Im gorszy, tym więcej pieniędzy utonie w projekcie, a to co powstanie może okazać się niewarte wysiłku. Im lepszy tym mniejsza rotacja w zespole, wydajność i motywacja programistów, mniej błędów, a więcej zysku.

Za zalążek DX uznać można słynny test Joela – listę punktów, jakie spełnia proces rozwoju oprogramowania. Im więcej, tym on dojrzalszy, ale również przyjemniejszy dla programistów uczestniczących w projekcie…

Starając się „dopieścić” koderów warto wyjść poza standardy. Nie muszą to być duże koszty. Zyski zaś i owszem. 

Na koniec przypomnijmy, że i Microsoft nigdy nie był obojętny na developerów…