Becoming a Magento developer

There are more than plenty of available career paths for programmers (not only Magento developers). Some of us find it easy to switch jobs for financial or personal reasons. They dive right into their new tasks, unafraid to face new challenges, technologies or learning a new framework, workflow, etc. from scratch. They don’t mind changes. If they like it in their new job, they’ll stay. If not, they’ll leave, onward to find a more suitable place. 

Others, in turn, approach the matter differently. While their reasons for switching jobs are similar, they prefer to do their research before taking any steps. Learn more about technologies they’d be working with or just compare the new work environment with their current one. Asses skills and knowledge to catch up with. Generally speaking, they need more proof that a particular job will be right for them. To get this proof, they ask multiple questions, small and large. Let’s try to find out what these questions should be for a future Magento 2 developer, try to answer some of them and shed some light on the reality of working with Magento. 

What is Magento (2)? 

Is this Magento?

On the official website, you can learn that Magento is a composite e-commerce solution, and probably every e-store owner will agree. However, we need to look at it from a Magento developer’s standpoint. So, what exactly is this Adobe product?

Generally speaking, it is a robust framework with a large number of dedicated modules. Or, less seriously, a CMS with extra topping. Apart from the core application, the installation includes dozens of additional modules adding up to the aforementioned composite solution. Obviously, we can manage them as we please and limit the platform’s functionality to a regular CMS, a digital warehouse or a CRM. 

I heard Magento won’t work without cache. Is that true? 

Nope. Magento will work without cache, except there is one little problem. It will work really slowly. So in theory, you can disable cache but it’s an extreme approach, used mostly for creating applications. One of the main reasons for Magento to rely so heavily on cache is the way it handles its config files. In practice, all code changes and customizations you’ll ever make will use them – from indicating interfaces implementation in a container, through overwriting injecting arguments, to ACL definition, CRON tasks, event watchers and several other configurations (also concerning pages’ layout or passing parameters to the client-side – JavaScript). These config files are rather lengthy XML files and can be found in almost every module. Thereby, Magento has to make sure they are interpreted correctly and in the right order. As you can guess, it’s not an easy process. This solution allows freedom in the way you modify third-party modules but by no means can be called efficient. Fortunately (or not), there is a mechanism of caching these files, once their final version is resolved. 

Cache – what’s with that? 

Everything is cached. The app works really fast when it’s enabled. But when it’s cleared, you can see how much it costs to refresh. Depending on your machine, the delay can easily be more than 10 seconds. Does it affect the Magento developer’s work? Yes, it does. If the cache is not refreshed, it can lead to confusion, like “I did everything right; why is it not working?”. And when you do remember to refresh, you need to wait to see your changes. That’s a common problem you’re likely to face when you work with the framework for the first time. And to be honest, there is no remedy; cache is an integral part of the app. The only thing that Magento developers can do about it is to work out a habit of clearing it only and exactly when it’s necessary. With time, it will come naturally and you’re likely to stop cursing cache through your teeth. It’s worth learning that cache is divided into sections and it’s not always necessary to clear them all. It speeds up your work and helps keep you concentrated. 

They say Magento is strange and unintuitive

Some say that Magento is evil. That you can’t find your way around it. That it will stab you in the back when you turn away. But what’s the truth? Is it really so different from all other popular frameworks? Yes. Is it bad? Well, if you insist on always working with the same mindset and other approaches intimidate you, then you indeed may find Magento to be a source of all evil in this world.

But if you’re ready to embrace changes, then you won’t. At first glance, it may be hard to find your way around the code or project structure. You’ll encounter nuances you won’t find anywhere else. Or at least not in a form you’ll find them in Magento 2. But no approach is inherently bad just by being outside the safe waters you’re used to. Apart from a few exceptions, these are still the same concepts and ideas, SOLID, DRY, composition and a handful of rules, served in a specific Magento way or implemented in a slightly different way. The best thing you can do is to work with it for a while and replace “why would anyone do it like that” with “there’s a method in this madness”. 

But there’s a hook. You have to remember that a great deal of Magento 2 code is taken directly from its predecessor, Magento 1. The Magento creators believe in composition over inheritance and you can tell it when looking at Magento source code. Unfortunately, not the entire code has been properly adjusted to the new standards. And these areas will likely be responsible for the majority of confusion when trying to understand it all. 

What about debugging? Is Magento architecture fuss-free?

Well, there is no rule. Obviously, nothing stops you from running a debugging process in Magento. It will work just fine. But debugging itself and its results can vary greatly depending on the area you’re inspecting. If it’s your own module that adds new functionality, then you’re probably safe. You’ll know where to set potential breakpoints because you know your code flow.

It gets trickier when you try to track the execution order of the core classes. Why, you ask? Well, Magento has a unique mechanism of extending the code – plugins. Namely, you can plug into a method in another class to change its input parameters or a return value. You can decorate it or completely overwrite it if you wish so.

So where’s the problem? Often, when debugging, instead of going directly to a called method, you will go to the Interceptor – a class generated by Magento that calls all defined plugins for a given method. It’s not very intuitive and forces you to carefully click through all extensions of a method to reach the right one (unless it’s been overwritten). 

And what is the entry level for a Magento developer? 

While you can divide Magento development into backend and frontend, you will need to delve into both before you’re able to work with Magento 2 efficiently. Sometimes, to make a frontend change you’ll need to make several changes on the server side if a JavaScript or CSS modification alone proves insufficient. A similar rule goes the other way; many backend changes may require adjustments on the front. That’s why, before you start working with Magento, there are a few things you should know outside of just PHP:

Also, and depending on the company and position you’re applying for, you may need:

  • good knowledge of GIT and experience working with repos,
  • ability to work in the UNIX environment (command line, sh/bash).

Summary – a year as a Magento developer

I’ve been working on Magento in Magently for almost 1,5 years. Ever since my duties and focus shifted to the backend which I guess reflects in the problems approached in this article. But let’s go back in time and take a look at my first steps in the company. 

At first, I would mostly work on the frontend. I was getting my way around the the themes, layouts and all other things a customer sees when visiting the store. Working on these areas has a specific flow to it. Mainly, because of the way the logic is implemented. Styles extension system, overwriting templates, resolving the blocks displaying order (and where should they be displayed) are not easy to grasp. And cache, that has a lot to do with blocks and layouts, isn’t helpful at all. I still find it problematic at times; perhaps because I don’t have to work with them so much anymore. But perhaps with a good workflow and more experience, it would cease to be an issue. 

Other things, in turn, have all changed for good. I remember blaming cache for all problems I encountered when implementing a functionality. “I did everything right, why is it not working?! It’s cache again!”. Needless to say, it would usually turn out to be an oversight on my side; a human error, if you will. With time, I managed to master the workflow and shove the irritation aside. I’m not saying it solved all my Magento problems (as I mentioned, Magento 2 is often Magento 1 code after a paint job), but it definitely helped. 

That’s it! If you have any more questions about making the first steps as a Magento developer, let me know in the comments. 

Also read: How I became a web developer