Q&A with Aref Lazrek: What makes a CobbleWeb full-stack engineer tick?

It’s one thing for a company to tell you what a wonderful work environment they offer, but the reality is we all prefer hearing it from the horse’s mouth. Our series of Q&As with CobbleWeb team members does just that – it offers deep insights into what made them join CobbleWeb, the rewards and challenges of the job, and how they see their futures unfolding.

This week we chat to Aref, a senior full-stack engineer at CobbleWeb, who shares some thoughts on transitioning from PHP to JavaScript, the challenges of fully-remote teams, and the importance of close collaboration and a sound project management process.

He highlights some of the projects he has worked on, including a carbon credits platform, which involved learning more about DevOps and AWS deployment. We also discuss the company’s flexible, trust-based culture and the opportunity to grow beyond technical roles.

---

Hello Aref. Thanks for joining me for this chat about your CobbleWeb journey. Let’s kick off with a bit of background. Where are you based and what is your current role at CobbleWeb? 

I’m a full-stack engineer based in Tunisia.

How long have you been with CobbleWeb?

About three years.

That’s a decent amount of time with one company. How does that compare with your total software development career?

I’ve been a software engineer for about seven years.

Early career

Why did you choose it as a career? What was the appeal for you? 

I started building websites from a young age. I have many friends and family who work in the industry, which sparked my interest. So I started building some small websites when I was about 14 years old. 

Did you kick off with the normal route? You know the usual suspects: HTML, CSS, PHP and a little bit of JavaScript? 

Yeah, in those early days HTML was enough for me to build a static website for a company during the summer school holidays. After I started collaborating with some friends, I was able to learn more about PHP and started to build more dynamic websites with CMS like WordPress, Jumla, and Drupal. 

You kind of kicked off where I stopped. I managed to do one WordPress custom theme and then I realised writing is more my area than programming. Did you study computer science at all or are you mostly self taught? 

Yeah, I started studying, but stopped when I received a job offer. After two years I went back to university and got my degree just before I joined CW.

Interesting. So, did you feel comfortable, you know, going the study route while you were working full time? 

Fortunately, the university over here offered part-time study options with classes and exams at night or over weekends. 

Well done. It takes lots of focus to juggle studies and a job. 

Remote Work Culture

Speaking of challenges, let’s talk about remote work culture. I mean, you’re based in Tunisia, the northernmost point in Africa, and I’m in Cape Town, at the extreme southern tip. So we are chatting right across the whole continent now, which is a great example of the remote culture at CobbleWeb. 

So, how do you feel about our remote culture and how does it compare to your previous project and work experience?

This is actually my first real remote experience. I worked remotely for a few months with a local company five years ago, but it didn’t go well because the company culture wasn’t 100% geared to remote.They struggled to keep everyone in the loop when project details were discussed, which caused issues. So they decided to rather work from an office.

When I joined CW I was a bit worried that there would be the same issues again. Some companies that are fully remote still have issues. One of the potential issues I was apprehensive about was the trust issue.

Fortunately CW is 100% remote, so the culture is really different. The tools and processes we use help you work well without worrying about any unnecessary issues. 

Aref, when you say ‘trust issues’, what exactly do you mean by that? 

Some companies have a very severe approach with tools that take regular screenshots of your work and so on.

A bit too much micromanagement? 

Exactly. At CobbleWeb there’s less of that and more focus on actually getting stuff done.

Project Management Process

Remote work culture is one aspect of working on the typical CW project, but I think what is also very important is the actual project management process. In your opinion, how would you say the CW project management process differs from your previous work experience? 

I think the way we approach projects is very much in line with startup culture where everyone is involved, everyone can comment, and there’s always open discussions. 

You find yourself  involved in all phases of the project, which offers much more professional value than being treated like a machine that just executes tickets. It surprised me in the beginning, because based on my previous experience companies don’t usually have that flexibility in their approach to projects.

So that’s a big difference here. It was a learning curve, but I’ve adapted to it, and I think it’s a big plus of working at CobbleWeb.

Is there anything in particular about the project management process that you would highlight, especially for a new person joining? What would you say they should expect from the process? 

I think it could be a bit challenging for newcomers who used to work with large teams with complex hierarchies or who had little exposure to startup culture, where they were only involved in coding.

What would be a good way for them to approach that challenge? To bridge the gap, basically?

I would say that they need to understand the workflow and how they can commit to that.

I don’t want to put words in your mouth, but almost like, ‘jump in and get involved’.

Yeah. And then also to see the value of what you’re doing, because sometimes newcomers think it’s just extra work for them. Some will say, “I’m just an engineer, shouldn’t the project manager or product owner do this?”

Previous Experience

That kind of links to my next question. What was your main focus before joining CobbleWeb? What kind of projects were you working on previously?

The agency I was working for built software products for other companies. My main project was a kids educational game for a startup. The platform was a mobile app and my focus was mostly on the backend.

What was the outcome of that particular project?

The project was a bit special because the front-end was being developed by a separate team with a different tech stack. That meant the independent backend we were building could be re-used for other projects. It was scalable, clearly documented, and easy to implement without touching code, in line with popular APIs like Google Places API.

What insights from that project were you able to carry over when you started working with CobbleWeb? What could you apply from what you learned in that previous project?

I would say scalability.  As the users were getting more and more, the most important thing was to support the higher traffic. 

That’s very true because gaming platforms and marketplaces both have a huge focus on scalability.

Exactly. For example, there were usage spikes during exam times that had to be accommodated. Overcoming that challenge was good preparation for CW projects.

Transition to JavaScript and Technical Challenges

Thanks, that gives a good idea of where you’re coming from. But let’s now move on to the nitty gritty – the actual CobbleWeb projects that you’ve been working on. Like you said, you’ve been with CobbleWeb now for three years.

From your perspective as a senior software engineer, can you tell us a little bit about a client project that you found particularly interesting. And with ‘interesting’, I mean what made it challenging or presented a bit of a learning curve?

The most advanced challenge was Switch2Zero, a carbon credits platform. There were two main reasons for this. It was the first full-stack JavaScript project we have done from scratch.

We had to find the right framework, tech stack, tools, etc. So the transition was a bit challenging. On a personal level, up till that point I’ve always worked with PHP-based backends combined with JavaScript frontends. But at the back of my mind I knew PHP is getting outdated and being used less.

I’ve picked up on that myself. Those stats that come out every now and again ranking the popularity of the different software languages clearly show that PHP’s popularity has gone down. 

Exactly. For me as an engineer that is a bit precarious, because many big companies including the FAANG companies have stopped using PHP.

Transitioning to a new technology can obviously be quite a challenge. You are used to working with PHP. You’re comfortable with it. You can solve problems with it. Now there’s a major project that the client is investing a lot of money in. So there’s a lot at stake. How did you manage to overcome that challenge?

The good thing, as usual, is that the company culture at CobbleWeb was very helpful. The selection of the tech stack was a team effort that involved analysis of various frameworks and open discussion among the team members about the best options for that particular project. The client was happy with our decision, because we could demonstrate the value right from the beginning.

That was a good experience for me, because I was waiting for an opportunity to move on to JavaScript. I also appreciated the fact that we could put in place some rules to control code quality and consistency. Up till then I was working on existing projects where such frameworks were already in place. 

The transition wasn’t without its challenges though.The client had very high expectations as they come from a banking culture where products are built in a very strict dogmatic way. But it was good to be thrown in at the deep end.

That’s an interesting observation with regards to the different learning curves that you have with a new project versus an existing project. With the existing project you’ve got certain parameters that kind of restrict you a little bit with how much you can change or explore. With a new project, obviously, there’s a bit more room to manoeuvre.

Involvement in Technical and Functional Specifications

Moving on, how would you describe your involvement in the technical and functional specifications?

Sometimes, like with Switch2Zero, the client is quite involved. In their case they provided detailed technical specifications for the project. Which can be a great opportunity for learning if the client has a strong technical team as well. 

So would you say with that specific project, there was a close collaboration between our team and theirs? 

Definitely.

But in general, how would you rate your involvement in helping to form a decision about technical or functional specifications? 

I think my input is usually evenly distributed. In a two-man project I would probably rate my impact at 50%.

Other areas of professional growth: Project Management & User Journeys

We’ve spoken a bit about the technical challenges you had to face, but in which other areas do you feel you’ve grown?

I think the most important area would be project management. Previously, I wasn’t really involved in that. The culture at CW helps you to learn more in that respect. 

And also in terms of technical analysis and specification, you act more as a product owner here. In my previous experience, the client would give us everything. There was not much discussion around decisions, unless something had to be clarified.

How much pressure would you say is on you as a software engineer to keep in mind the business goals of a project?

The background is that I’ve worked with software agencies before where I felt that my project was being inboxed/outboxed. In other words, functionalities are just being executed without actually analysing what the impact is going to be on the project’s viability. 

I think we are always trying to improve business outcomes based on analysis and our previous experience. We will often make suggestions that have an impact on those goals.

And what about user journeys? Have you learned anything about user journeys and UX?

For sure. Because we are involved in all the steps and collaborate with the designer on a regular basis. In my previous experience we only contacted the designer if there were issues or adjustments.

In fact, I had the opportunity to discuss the design of a new delivery platform, MealMap, we launched recently.

Reasons for Staying with CobbleWeb

Time to ask you the million dollar question. There is a perception that software engineers do a lot of job hopping for a variety of reasons:  upskilling, better pay, etcetera.

What would you say are the top reasons why you have stuck with CobbleWeb for the past three years?

In the first place, the company culture. I feel comfortable working with all team members and I like the way management operates. It boils down to flexibility. The company is open to improvements in the way things are done. It’s not a case of, “No, this is the way we’ve always done things. Stick to it.”

There will of course always be some room for improvement. But I’m happy as long as everyone is open to fixing them with fact-based solutions. 

How do you feel about the fact that CobbleWeb specialises in a very specific area of ecommerce – online marketplaces? 

Marketplaces form such a big portion of ecommerce these days that it doesn’t really limit us. Since we focus on custom development we are not restricted to which projects we can take on. All of the projects are quite different from each other.

Project Highlights

I promised you I’m going leave another technical question for last. What was the most interesting technical aspect that you had to research first in order to solve a challenge?

I can think of two instances. With Switch2Zero I had to learn more about DevOps and AWS deployment. For example, I learned how to use Terraform, AWS’s infrastructure-as-code tool, to automate cloud infrastructure tasks such as provisioning and configuration of resources.

Then the food delivery app, MealMap, required IoT integration between front of house points-of-sale and the restaurant kitchen printers. The printers use a custom embedded OS, so we had to get to grips with their SDK first.

Well, you and the team have obviously done a very good job, because I coincidentally read the MealMap client’s glowing review on Clutch. According to them CobbleWeb delivered to a very high standard. So well done!

Thanks!

Advice for new team members

Aref, let’s finish off. What would your advice be for a new software engineer joining CobbleWeb? 

They need to be prepared to adopt the company culture from the beginning. Otherwise they may struggle. .

What would you say is different in CW culture if you had to identify 1 or 2 things?

They need to be prepared to wear multiple hats, not just being a software developer. There will be a bit of project management, some design thinking, as well as being involved in compiling specifications.

These cross-functional demands should not be seen as unnecessary additional work, but rather an investment. They will see the value of this when they do the actual coding. 

Great point. Your career growth trajectory is usually much faster and higher when you are exposed to other disciplines. Aref, I appreciate you taking time out to share some great insights. It sounds like you’re doing really well and hopefully there’s lots more interesting projects on your way.