Meet the Kroo Team: Full Stack Developer

Meet the Kroo Team: Full Stack Developer

14 January 2022 | by Kroo Marketing Team

Here at Kroo we’re passionate about our people, they are, after all, what we’re made of. We’re inspired by our team’s commitment to growth, for embracing change and building a bank that’s an agent for good.

We’ve interviewed a key member of our development team to give some insight on what it's like to contribute and be a part of the Kroo team. Read on to hear from William Murphy, a full stack developer here at Kroo!

Can you tell us a little bit about yourself and explain your role at Kroo?

I’m a full stack software engineer here at Kroo! I’ve  been developing for 15 years and have been working for various startups for the past 6-7 years in London.

What are you working on right now and what technologies/languages are involved?

As a full stack developer you work with a range of technologies, such as react native for both mobile and web applications. Our back-end is in Clojure with postgres, Kafka for data storage and we deploy our microservices using docker in AWS. We also do a fair bit of work configuring in Terraform.

Typically I’m working on different features for our end users such as bill splitting, account registration but right now I’m working on ensuring our mobile app security is state of the art. You can see there’s lots of different areas to work on here at Kroo!

How do you keep your skills sharp and up to date?

When I have the time and energy I like to work on side projects and go to tech talks. I know some developers don’t do these things, but when I’m able I like to play around with different languages

I principally learn by building and being exposed to new technologies and learning from other members of the team as to how they do things.

“We do a lot of knowledge sharing here at Kroo and that helps to develop my skills on a daily basis.”

What were you doing before Kroo?

Before Kroo I worked for a bunch of startups. Most recently I was developing software to help make Apache Kafka easier for companies to manage.

Why did you choose to start a clojure role?

Clojure was an interesting language to me, partly because I’ve done some functional languages before and I was really interested to learn more about how I can develop my functional language knowledge further.

It also runs on the JVM platform which is such a popular platform. This means you can use a lot of things from Java tools and libraries for Clojure.

How long did it take to learn? What was that process like?

The learning process was predominantly done on the job through pair programming. Pair programming allows someone to both help you and teach you in a very hands-on kind of way so you’re not on your own.

The clojure we are using for our microservices is relatively simple and it’s moreso our infrastructure which uses more advanced clojure techniques. For the most part it’s relatively simple. This means you can get started quite quickly by working on the microservices in the beginning and you can get to more advanced clojure with the infrastructure.

What do you like about clojure?

Being a functional language, Clojure makes concurrency easier and it’s generally easier to understand the code. Compared to the Java code that I was using 10 years ago, clojure is simpler and easier to follow after you’ve cut your teeth on a few bits of code.

Whilst the syntax looks different to most mainstream languages, you do get the hang of it quickly and I know a lot of engineers here at Kroo find it easier to read.

Why is Kroo such a big advocate of pair programming?

Because it works well. It’s great for knowledge sharing. Less emphasis on working with code review tools and, even for a small amount of code, the reviewer won’t often have the context as to what you're doing.

Whereas when you’re pair programming, you can review the code in real-time and work together which has the double benefit of knowledge sharing and learning at the same time.

Whilst we use the knowledge sharing tools like wikis, brown bag sessions and slack, we found that pair programming is a much more organic way to share knowledge of the system between team members.