What’s it like to work in Docplanner Dev Team (Docplanner Tech)?

Hi! Recently, I decided to sit down and describe the atmosphere, technical details, and all the curiosities associated with working at Docplanner, known in Poland as ZnanyLekarz and in Spain as Doctoralia. I found that the recruitment advertisement is a great base to gather some information about us, but to get to know us better — you need something more. In this post, I’m trying to introduce you to all aspects related to even the smallest extent of co-creation of the product, or rather a group of products, hidden under the brand name Docplanner. I’m focusing on the part of the product that we develop in Poland, called the Marketplace. Enjoy your read!

Patryk Woziński
Docplanner Tech
9 min readJun 19, 2019

--

Who are the Devs at Docplanner?
Let’s start with the fact that the developers you meet in our office are not coders. No one is sitting here with their noses in laptops coding things like punch cards in the ’80s. Our development team consists of people who design and create software that is primarily designed to meet the principles of evolution. We want the software we create to be easy to maintain, develop, test, and above all, pleasant for everyday work. Hence, the lack of time pressure often encountered in many other places — of course, there are situations when you need to finish something for a specific date, but these are not rigid time frames, exceeding of which means execution, like the one of XXXX in “Game of Thrones” (no spoilers!). Here, the
business often originates from the technology department, and people understand that sometimes problems arise that result in exceeding a predetermined time.

What do we use every day?

Many job advertisements contain buzzwords — with us, reality reflects these words, and they function in the daily work of our developers.

First of all: what languages are accompanying us? It is mainly PHP that in the Polish team is the primary language in which we create new functionalities. We try to keep it always fresh, and we perfectly understand people who simply do not want to work in the old language like the versions below 7.1. With us, everything starts with the mentioned version 7.1, which operates in the monolithic part of our system, and all new parts are built based on the latest trend from under the sign of a purple elephant — we are talking about the stable 7.3. We are working on migrating the monolith to something newer, and the Development Quality team, in which I am working, is currently investigating prospects of such a migration. Apart from
the PHP itself, we use Golang, a technology in which we want to develop ourselves, so we have already created several functionalities based on Google’s language. We use these technologies when creating the Marketplace (in Poland). In Spain, to develop SaaS for doctors, our team uses C#.

Second: frameworks. It is a subject often overlooked or excessively elevated, but in our country, it is very clearly defined. For consistency sake, all projects where we use PHP we base on Symfony. It is Symfony in many different versions, but we try to update as much of them as possible. Yes, we still have Symfony 2.8, and yes, we are working on upgrading it to the latest version, but unfortunately, in the case of such a big application, it takes some time.
However, despite everything, we are aware of the need for an update. The latest projects are business agnostic from the framework or additional libraries used in them. We achieve this thanks to the appropriate separation of responsibilities and layers (infrastructure is cut off from the business). However, yes, looking at the infrastructure, we use the latest version of Symfony. For SaaS developed, we use .NET.

Third: databases. In our daily work, we use both MariaDB and PostgreSQL that are connected in several places. We are flexible, and we choose a tool to meet your needs. As proof, you can take MongoDB and ElasticSearch used as often as needed.

And fourth: the tools themselves are not as important as the paradigms associated with them. The code that we create is something cool, something we’re proud of. As PHP is our primary language, we also try to make the software we develop meet all the most restrictive requirements. That is why we have the training, technology meetings, or the promotion of a healthy approach to object programming, seasoned with Domain Driven Design. It is
important to us that the people who join us can adapt to the new system in a comfortable and friendly way — and thanks to the fulfillment of universal and well-known OOP rules, we can provide that. In this respect, we exchange the best practices with our colleagues from Barcelona.

How do our teams look like?
At Docplanner, we form the teams when we need to test new solutions or focus on a specific area of the system. In the Polish division, there is a primary distinction of product teams that are responsible for specific sets of functionalities in a given context. We distinguish teams such as Patient Acquisition, Patient Booking, Integrations, or the one working on
CRM/eCommerce solutions, as well as many others that have a clearly defined scope of responsibilities and are managed by Product Owners / Project Managers. We strive to make the teams we build autonomous so that they can deliver any new solutions independently of other groups and feel the real influence on Docplanner’s development.

What are the features of the ideal candidate applying for the position of developer?

Paradoxically, technical skills are not the most important for us, nay — we believe that sometimes it is better to hire a person who would need to be gently introduced to some sets of technologies by us, but one who would perfectly fit our values or product understanding. Above all, the most important for us is passion. We believe that in the case of programmers, it
is an absolute must, to think of work as something you do because it makes you tick. The second thing is communicativeness, an essential feature because we work on one, large system (regardless of whether we have small product teams or not). We expect you to be able to quickly find help in case of problems and to help others who need it.

Proactivity is a feature that gives a neat look onto the candidate; we love learning together, sharing knowledge, and organizing various product or technology events; and someone who comes out with the initiative is undoubtedly a person who’ll find oneself with us perfectly.

Looking at the candidate through the prism of technical skills, first of all, we want a developer to be skillful in object programming — an experience in PHP itself is not as important as the ability to create code that is easy to maintain and develop. As you probably know from the previous paragraph, Symfony is a framework that we use every day, but that’s something we can teach you if you’ve worked with other MVC frameworks. Of course, an ideal candidate is
a person who knows Symfony from the inside out. An additional advantage would be if our candidate had experience working with large applications operating globally on several continents. For us, deployment at night is not a solution to the problem, because when you are implementing your changes, someone in Latin American countries may be eating dinner with a toothache, so they are using our application to find a dentist for the next day.

How does recruitment look like and what’s so cool about it?

At the very beginning, I would like to adduce the words I have read in the book “Software Craftsmanship” by Sandro Mancuso — the recruitment processes that are based on one or two recruitment stages are something we should be afraid of. Often companies try to bring new candidates at a push, and they want almost anyone who at least embraces the basics — they are not interested in the values important to you or what kind of people you are.

It’s different at DocPlanner. The recruitment process consists of many stages, where each of them has a purpose and provides a particular value.

  • We start traditionally with gathering CVs and verifying them through our wonderful “panie kadrowe” (eng. HR Ladies), meaning the People Experience team; but they love when we call them that. ;)
  • The next step is a meeting at our office with the team leader and one of the mentioned HR Ladies. During such a meeting, we talk about your experience, what motivates you, and we slightly get into the technological path, where the leader asks a few questions to verify the fundamentals of your knowledge. At this stage, we also provide all the critical information related to work at ZnanyLekarz.
  • If we reach the third stage, something awesome awaits us! This thing is the trial day, about which our CTO Grzesiek wrote more here. Each trial day may be different; we tailor them to the candidates who come to us. A junior Backend Developer would obtain a different task, and a senior Frontend Developer would get something else. It all depends on who and what we want to check to be sure of the candidate. For some time now I have come up with a particular belief that the trial day is absolutely the
    best thing in recruitment that can happen to us, and if you think it’s a “waste of time” then you are hugely mistaken! Where else will you witness the atmosphere of work in the office that is between members of various teams, where will you take part in scrum-daily or look through some pieces of the application code you may work on in the future? It is during the trial day that you can see what the work in the company that interests you really looks like — it is priceless how much you can get out of something like that. Besides, you have the opportunity to ask different people about each and every aspect of the work that interests you. This stage is for both the recruit and recruiter a gargantuan dose of information!
  • Stage four! It’s no joke now; the only thing that is left is getting the references from your previous employers and colleagues. We always want to know what it was like to have the pleasure of working with you, and sharing this type of information is an additional dose of useful clues about you — in this stage, we often get some fun facts about the candidates and tips on what direction of development may be interesting for
    them.

Feedback — I think that you could say that DocPlanner is based on the exchange of feedback. Each stage ends with feedback, and we believe that the mutual dedication of time during recruitment deserves to be rewarded, so that both sides get something interesting — even when we finally cannot get someone on board. The trial day itself often consists of sub-stages with feedback: on the idea of solving a task, on the subject of the day itself as a source of some preliminary information, and also the one with the final decision.

We create a Dev-Community

Perhaps you have already come across information about our technological meetups under the Docplanner Tech brand. It is a series of meetings in which each meetup edition is associated with a specific area of software development. We have meetings about the product, backend, and frontend as well as those related to IT management. More information can be found on the website docplanner.tech dedicated to this event.

Where do we get the knowledge from?

The development of both technical skills and soft skills is critical to us. As I mentioned earlier – we have a series of our own meetings, but on top of that, we try to take an active part in various meetups, conferences, or workshops surrounding the technologies we use and those we would like to learn to use in our work. You can meet us at events such as PHPers, DDD-WAW, PHPers Summit, SymfonyLive, Code Europe, Boiling Frogs, DevOps Days, OpenSource Days, and a lot of other similar events. Look out for our DocPlanner Tech T-shirts!

Our team!

In addition to all the different meetings we take part in, we also strive to carry out training sessions. These trainings are both internal, like TechTalks, workshops with various technical and soft methodologies, but also external. Recently, we took part in a workshop with Matthias Verraes, who is a co-organizer of DDD Europe. Knowledge is power, and we know it!

So? Are you ready to join us? :)

To sum up: we care for great people with passion who at work give something more of themselves than a few lines of code — they inspire others, share knowledge, and want to participate in our community.

So, you have considered changing your job and wondered about our offer.

After reading all this, are you ready to join us? Excellent!

Any questions? Let me know! :)

This story was originally written in Polish.

--

--

Patryk Woziński
Docplanner Tech

Product Engineer with many years of experience in creating and designing web applications. #DDD freak