<polska wersja poniżej>
How to find and hire front-end engineers?
When we look back, it seems like it was another era. But it was only a decade ago. So if you are interested in a true case with true dev-meat, check our story out.
# 1: Front-end evolution, from ajax and prototype, through jquery and MooTools, to AngularJs and React.
The internet we don’t remember anymore
Bitnoise as a software house took off in a different era of the internet, and over the years technologies have turned upside down at least several times. In 2008/2009, the separate role of the front-end developer practically has not existed, and each developer in our growing team approached problems comprehensively.
Most people, who have been with us since then, remember that tasks or user stories were not split up because of the front-end/back-end but because of the context. The developer creating a specific functional module was responsible for the preparation of data structures in the database, preparation of business logic on the server-side and for sending an adequately formatted HTML template straight from the server.
These were the years of frameworks such as Ruby on Rails, Symfony 1.x, CakePHP or Django. We were pursuing clean code, good software development patterns and creating projects that can be maintained for years. On the one hand, it resulted in excellent quality projects as a whole, and on the other hand, a growing distaste and frustration for the lack of neat structures in JavaScript.
It was the time of the domination of the idea to display the first view directly from the server and rebuild all smaller or larger changes within the available view using the AJAX protocol. We also very quickly made friends with the popularising Prototype library.
Browsers are booming
The growing possibilities of web browsers and the overwhelming customer requirements regarding application dynamics, animation and smooth interfaces forced us to look for new solutions. We got stuck in a moment where we had great quality code on the server-side, covered with tests, written in line with the domain-driven design idea, and spaghetti-code in JavaScript.
In our search, we followed the path of jQuery fascination — we quickly saw an opportunity to write plugins that gave some form of modularization and tried to bring a substitute for the DRY idea to the UI layer. We also worked on large and heavy projects based on MooTools, in which the idea of classes analogous to the known back-end code was easy to adapt and allowed us to bring known and liked patterns from the back-end to the front-end.
A milestone in our organization was the appearance of Backbone and Marionette — these were the first moments when we began to efficiently transfer the burden of business logic to the front-end in a structured way. It was the moment in the team when people specialized in front-end, and JavaScript has started to emerge naturally. Our UI code has finally begun to bear the hallmarks of quality.
Finally, we are ready for a front-end engineer!
Next, there was an avalanche of events. The popularization of mobile devices forced us to change our thinking about CSS styles. In no time we’ve adopted LESS, then SASS and the modularization of styles. The growing need to separate front-end from the back-end has caused a change in thinking about applications as a monolith. New projects began to emerge in the form of a separate API and one or more front-end applications.
Our first jump in SPA was Angularjs 1. * you can say many things about it, but this framework showed us how good quality code can be written in javascript and how to create large and easy-to-maintain applications based 100% on the idea of a full-fledged application in the browser, which only asks the server as needed.
This is also a moment in our history when a new role grows in Bitnoise: front-end developer or JavaScript developer. We were at a time when one person was no longer able to maintain and develop applications on both: the server-side and the browser/smartphone side. Interestingly, our teams still have people with full-stack competencies, and each of them has walked with us from the server to the browser.
Where are we currently with our technology stack?
Over the years, we have managed to develop patterns and standards, drawing handfuls from our experience on the server-side. It’s hard to talk about the finished process because browsers and devices change so rapidly that we have to keep our finger on the pulse and analyze trends all the time.
next time:
So what is our difficulty in employing a good front-end developer in 2020? Case is simple if the team is joined by a person who has encountered other technologies in his work so far, who worked in the full spectrum of application development. The problem began when we’re talking with a programmer whose tech stack is only JavaScript or even worse — on a specific framework such as React or Angular, but I will talk about it in the next part.
- Łukasz Roth, Co-founder & CTO at Bitnoise
PL
Jak znaleźć i zatrudnić front-end developera?
Kiedy patrzymy wstecz, wydaje się, że to zupełnie inna epoka, tymczasem to była zaledwie dekada temu. Jeśli interesuje Was prawdziwy przypadek z przykładami wziętymi z życia, sprawdźcie naszą historię.
#1: Ewolucja front-endu, od Ajax i Prototype, przez Jquery, MooTools do AngularJs i Reacta.
Internet, jakiego nie pamiętamy
Bitnoise jako software house wystartował w innej epoce Internetu, a przez lata technologie wywróciły się do góry nogami co najmniej kilkukrotnie. W 2008/2009 roku osobna rola frontend developera praktycznie nie istniała, a każdy programista w naszym rosnącym zespole podchodził do problemów kompleksowo.
Większość osób, które są z nami od tamtych czasów, pamięta, że zadania czy też user stories nie dzieliły się z perspektywy frontend/backend tylko opierały się na kontekście. Programista tworzący konkretny moduł funkcjonalny odpowiadał za przygotowanie struktur danych w bazie, przygotowanie logiki biznesowej po stronie serwera oraz za wysłanie poprawnie sformatowanego szablonu html prosto z serwera.
Był to czas takich frameworków, jak Ruby on Rails, Symfony 1.x, CakePHP czy Django. Nasze dążenie do czystego kodu, dobrych wzorców wytwarzania oprogramowania i tworzenia projektów, które uda się utrzymywać latami zaowocowało z jednej strony bardzo dobrej jakości projektami jako całości, z drugiej strony rosnącym niesmakiem związanym z brakiem zgrabnych struktur w javascripcie.
Dominowała wówczas idea, aby pierwszy widok wyświetlić bezpośrednio z serwera natomiast wszystkie mniejsze lub większe zmiany w obrębie dostępnego widoku przebudowywać za pomocą protokołu AJAX. Bardzo szybko zaprzyjaźniliśmy się też z popularyzującą się biblioteką Prototype.
Boom przeglądarek
Rosnące możliwości przeglądarek internetowych oraz przytłaczające nas wymagania klientów odnośnie dynamiki aplikacji, animacji i płynności interfejsów zmusiły nas do poszukiwania nowych rozwiązań. Utknęliśmy w momencie, w którym mieliśmy świetnej jakości kod w PHP/Python, pokryty testami, pisany w myśl idei domain-driven design oraz spaghetti w JavaScripcie.
W swoich poszukiwaniach przeszliśmy drogę fascynacji jQuery — szybko zobaczyliśmy szansę na pisanie pluginów, które dawały pewną formę modularyzacji oraz starały się wnosić namiastkę idei DRY do warstwy UI. Pracowaliśmy też przy dużych i ciężkich projektach w oparciu o MooTools, w którym to idea klas analogicznych do znanego nam kodu backendowego była łatwa do adaptacji i pozwalała nam wnosić znane i lubiane wzorce z backendu do frontendu.
Kamieniem milowym w naszej organizacji okazało się pojawienie się Backbone i Marionette — były to pierwsze momenty gdzie ciężar logiki biznesowej zaczęliśmy sprawnie przenosić na frontend w ustrukturyzowany sposób. Był to moment kiedy w zespole zaczęły w naturalny sposób wyłaniać się osoby, które zaczęły specjalizować się we frontendzie, javascripcie. Nasz kod w UI nareszcie zaczął nosić znamiona jakości.
W końcu!
Jesteśmy gotowi na front-end developera
Dalsza droga to już lawina zdarzeń. Popularyzacja urządzeń mobilnych wymusiła na nas zmianę myślenia o stylach CSS, bardzo szybko zaadoptowaliśmy w organizacji LESS, później SASS oraz modularyzację styli. Rosnąca potrzeba separacji frontendu od backendu spowodowała zmianę myślenia o aplikacjach jako o monolicie. Nowe projekty zaczęły powstawać w formie osobnego API oraz jednej lub wielu aplikacjach frontendowych.
Naszym pierwszym skokiem w SPA był Angularjs 1.* można o nim mówić wiele rzeczy ale to ten framework pokazał nam jak dobrej jakości kod można napisać w javascripcie oraz jak tworzyć duże i łatwe w utrzymaniu aplikacje oparte w 100% o ideę pełnoprawnej aplikacji w przeglądarce, która tylko w miarę własnych potrzeb odpytuje serwer.
To jest też moment w naszej historii kiedy w Bitnoise wyrasta nowa rola — frontend developer bądź też javascript developer. Byliśmy w momencie, gdzie jedna osoba nie jest już w stanie utrzymywać i rozwijać aplikacji zarówno po stronie serwera, jaki po stronie przeglądarki/smartfona. Co ciekawe, nadal w zespołach mamy ludzi o kompetencjach full-stack, natomiast każdy z nich przeszedł z nami drogę od serwera po przeglądarkę.
Gdzie jesteśmy obecnie z naszym stackiem technologicznym?
TypeScript, React ecosystem, React Native, Angular, Ionic, Jest, Karma, PWA (…)
Z latami udało nam się wypracować wzorce i standardy czerpiąc garściami z naszych doświadczeń po stronie serwera. Ciężko mówić o skończonej drodze, gdyż przeglądarki i urządzenia zmieniają się tak szybko, że musimy cały czas trzymać rękę na pulsie i analizować trendy.
W następnym odcinku:
Na czym zatem polega nasza trudność w zatrudnieniu dobrego front-end developera w roku 2020? Sprawa jest prosta jeśli do zespołu dołącza osoba, która w swojej dotychczasowej pracy spotkała się z innymi technologiami, pracowała w pełnym spektrum tworzenia aplikacji. Problem zaczyna się gdy do rozmowy przystępuje programista, którego tech stack to tylko i wyłącznie JavaScript lub konkretny framework jak React lub Angular ale o tym opowiem w kolejnej części.
Łukasz Roth, współzałożyciel i CTO w Bitnoise
