Battling developer shortage with educational cooperation

Without today’s juniors there wouldn’t be tomorrow’s seniors. This very much holds true within any specialist field, but it still feels like the truth about healthy workforce structure has been forgotten in today’s knowledge work.

As a company that cooperates a lot with public sector organizations, it must be said that sometimes it’s exceedingly difficult to get newcomers to the software development field actually hired into projects. Project teams are picked based on CVs in close fought competitive tendering with winning bids invariably going to teams made up of 10 year veterans with black belts in coding. You can’t get beginners hired to gather valuable experience even if their fees were next to nothing.

The board of the Code from Finland association, lead by their chairman Janne Kalliola, laudably pointed out in their opinion piece in Helsingin Sanomat that strict competitive tendering criteria are exacerbating the developer shortage and are holding back the growth of the industry.

Even though experience is valuable and valued, the programming industry needs new skilled workers now more than ever. The way we are trying to affect the industry is through educational cooperation and by hiring junior software developers ourselves.

Cooperation with the Helsinki Business College

A versatile content management system like Drupal, which is aimed at large clients, requires a constant source of experts. Fresh software developers are often enthusiastic open source contributors, and their careers will benefit from Drupal’s large international community. Being an active open source developer could well act as a stepping stone to an international career in programming.

In Finland, Drupal programming education is offered by our longstanding partner, the Helsinki Business College. Our collaboration during the years has been varied: we’ve taught in their courses, coached teachers in the use of Drupal, organized company visits and taken in interns whenever possible. When things work out, we are happy to offer permanent jobs to the interns. Many HBC students have graduated to working life through us.

In January of 2022 we will take the next step in our collaboration as we become the cooperation partner for the React & Drupal Full Stack Web Developer study program at HBC. We want to take active part in familiarizing students with the everyday life within the software industry, as well as the Drupal community and naturally with us as a company.

As a partner we will help HBC to specify the practice project carried out during the studies, and I will work as the project’s product owner for the development teams. At the end of the study period we hope to snag as many skilled developers as possible as interns, which will hopefully lead to them becoming gainfully employed developers in the industry.

Maintenance work provides all-round experience

Even though the public sector’s attitude towards novice developers is hardly enthusiastic, competitive tendering shenanigans won’t be the end of anyone’s career. The comprehensive maintenance and small scale development services we offer are of key importance when it comes to getting junior coders employed. Most of our interns will find themselves under the care of our Magical Support team and will later be employed as part of the team.

We at Druid don’t consider the maintenance services we provide as a necessary evil but rather a significant source of our revenue. Over 95% of our clients move to maintenance at the end of an implementation project, and the amount of work done under the maintenance contract is often manifold compared to the original project.

Our multilingual and multi-skilled team is responsible for ensuring that our clients’ websites remain functional, secure, and up-to-date in terms of features. The technical skills required in these tasks range from the comprehensive knowledge of large Drupal systems to creating modern JavaScript and React code. Is there a better place for a newcomer to the industry to get a feel of the diversity of working life?

We at Druid have helped bring to life a number of success stories whose main star has been a motivated fledgling software developer. Those are the stories we yearn for. That’s why we want to offer a solid stepping stone to working life to as many people as possible.

8 things we learned at Druid

Last week we said goodbye to our wonderful interns Florence and Bea. During their four month internship with us, they built a demo application with JavaScript for car repair shops and their customers – and did an absolutely brilliant job.

The app lets users choose the nearest car repair shop, book an appointment for car maintenance, keep in touch with the shop through in-app chat and see the progress stage of their car as it’s being repaired. The app was built with the user in mind, focusing on the user’s convenience.

Before Bea and Florence embarked on new adventures, we asked them to write about their learnings and experiences from the project and beyond. It turned out they had a lot to share – so let’s dive right in!

1. Progressive Web Apps (PWA)

PWAs have been in the app ecosystem for some time and you may have probably used one without knowing. They are web apps with an enhanced capability in modern web browsers.

Among many of the features we discovered are its installability, offline mode experience, linkability, native-app feel, re-engaging nature and a single codebase that can be used on different devices. It was interesting to know that companies like Uber, Trivago, AliExpress, Spotify, Starbucks and Pinterest are already using PWAs as their web service platform.

Although it was a new concept for us, a lot of research enlightened us on how we could apply it in the project we wanted to build. We built a PWA with Create React App (CRA) which was incredibly convenient because CRA has a template for building PWAs.

2. Teamwork

Team synergy was by far one of the most important factors that influenced the outcome of our project. This encompasses a lot of factors ranging from setting project expectations to good and clear communication.

We tried as much as possible to be on the same page in the building process of the project. From the technical perspective, we set up a system where we could review each other’s codes before merging changes to our main branch. That meant we had to ensure we were writing readable and understandable codes. In order to ensure uniformity in our codebase, we had rules set in ESLINT.

After working independently to solve complex problems for more than half-way into the internship, we decided to try pair coding at some point. To be honest, we wished we had started with pair coding much earlier, because we realised how knowledge sharing contributed to arriving at solutions quickly.

3. Who needs a server these days?

You may have heard about “serverless backend”, which means running your server-side code without having to maintain your own server. The solution is tempting, because it cuts the costs (on-demand, so you don’t pay for idle time of the server), it’s easy to scale and lowers administrative overhead.

AWS Lambda is a popular choice, but managing service discovery, API gateways, and keeping your app and the functions in sync can be overwhelming – that’s where Netlify functions come to the rescue. We chose to use them in our project, because they are a make-it-easier layer over Lambda functions, which means we could use them without an AWS account; also, keeping everything up to date was a breeze.

With the serverless functions in a correctly named folder in the project, we were deploying our React frontend together with the serverless backend at the same time and Netlify did the dirty work handling all the rest. Add to that the continuous deployment straight from our GitHub repository, including previews of pull requests updates, and you got yourself a recipe for painless deployment handling!

4. Mercure for real-time features

For our app we needed real-time communication to create our in-app chat and to update the UI of the end user when the admin changes the state of the user’s appointment. We decided to use Mercure, an open protocol not using Web Sockets, but instead built on top of HTTP and SSE (Server-Sent Events).

With the Mercure Hub set up (using Docker image for local development and deployed to Druid’s server for production), we needed to do two things in our app: publish updates and subscribe to them.

Publishing happens when someone sends a new chat message or the admin changes the appointment state – a regular POST request is sent from our frontend to the serverless backend, where the data is saved to the database and Mercure update is published to the Hub.

Then the Hub’s job is to pass this update down the correct channels, so that only the users subscribed to it get the information. Subscribers are browsers; for example when an end user opens their appointment view, the app subscribes to updates about their appointment (change of stage or price estimate) and to updates of their chat (and only theirs, so that they don’t get somebody else’s messages by mistake).

To subscribe, we used EventSource, which is kind of a keep-alive connection to the server (the Mercure Hub in our case) and differs from Web Sockets in that EventSource is one-way communication, it can only listen to updates, not send any – which is all we needed.

5. Web push notifications

Like any new feature that was implemented without prior knowledge of how it should work, implementing push notification was mostly learning by doing. Push notifications are messages sent to user’s devices from a website via a browser. And with the offline feature of PWAs, users do not miss notifications even when they are not online.

Looking at our app’s use case, push notification capabilities were useful for notifying users whenever there was a change in information. For eCommerce and marketers it’s an amazing way to re-engage with web visitors whenever there are new products, releases, etc. It was relevant to build this feature, especially as PWAs are becoming more popular and being supported by more browsers.

6. User experience

We needed to keep the end user in mind as we worked on our app. Have you noticed the unexpected shifting of elements like videos, buttons or fonts on a web page while the page is still loading? Exactly, that can cause a poor user experience and is referred to as Cumulative Layout Shift (CLS). It’s a Google metric which is used to measure the user’s experience on a web page.

CLS is usually a good way to detect coding issues which could be resolved to improve usability on your site. These may be tiny details that could slip through during development and may seem “irrelevant”, but they definitely count! What is the point in building an app that lacks usability? Knowing about CLS and its importance highlighted user experience as an important skill to have as it makes us better developers.

7. Scrummy Scrum

Agile methodologies have become the default way of working in the software development field, so to nobody’s surprise we used the Scrum method in our project. We learnt about this style at school, but only working on a long-term project unveils the true power of Scrum.

Thanks to the regular feedback sessions in retrospective meetings, with every iteration there were less conflicts or misunderstandings, with every sprint we worked better and more efficiently. For every ticket in the backlog we assigned points to estimate the time and effort needed to complete the task, which helped us understand deeper the goals, expectations and each other’s views.

We also made mistakes like not deploying every sprint – it came back to bite us in the last few weeks of the project as we ended up with several issues accumulated in production. Debugging and understanding which error is caused by which part of the code failing was unnecessarily complicated, so lesson learnt!

8. Teal is the new black

There’s so much more in the management philosophies landscape than the traditional, hierarchical way of big bosses, small bosses and the workers. Druid is slowly but steadily undergoing a Teal transformation, aiming at a flatter management structure.

Many tasks at the company are being taken care of by swarms – a group of people interested in the issue or topic around which the swarm was formed. The doers declare their readiness to put time and effort into the subject, the helpers can offer a little less time, and the followers are interested in the works, but for one reason or another can’t promise much help.

In our time at Druid we had a chance to observe among other things the work of the salary week swarm who took care of designing and executing salary negotiations. The best thing about swarms is they can be formed as issues or tasks arise, and torn down when they solve what they were born to do or when they become inactive and die out.

Another part of the Teal way that we found interesting is the advice process helping in decision making. When there is a decision to be made, one person volunteers to be the decision maker and asks for advice, especially from people directly affected by the decision and from experts on the topic. Others can then give advice (not their opinion, but strictly advice), but the final choice of course of action is made by the decision-maker – that also includes full responsibility for the outcome.