Expert Thoughts: Hiring a Quality Magento Developer

The New Year is just around the corner, are you and team ready for your upcoming Magento 2 projects? We’d like to share our thoughts about hiring awesome Magento developers!

Every now and again, a client of ours communicates a desire to take some of their site development “in-house.” As the company matures, becomes comfortable with the technology, and their online environment stabilizes, they naturally progress to the point where they desire to do it themselves.

Simply, the client feels secure in knowing that we are still there to assist in their growth as a company, particularly in the competitive e-commerce arena. What’s more, we’ll even participate in the interview process.

However, when it comes to hiring experts in this field, we’d like to think we know what we’re doing, more so than most. So, as a gesture of corporate fraternity, we’d like to share our top five characteristics when hiring a high-quality (i.e., awesome!) Magento developer:

1. Engineers vs. Developers
2. Experienced in Magento 2
3. Ecosphere Participation
4. Partner Experience
5. Align Expectations

Engineers vs. Developers

In a hypothetical situation, a business executive might say something like, “paint the sky orange.”

Now, in this scenario, does the developer simply paint the sky orange? Or, should the Magento expert ponder that request and make recommendations as to what he or she thinks appropriate?

To keep the business out of serious trouble, the Magento specialist could respond with a thoughtful viewpoint based on his depth of experience in the field.

It’s also important that the developer is more than just a coder. Not only must he possess a thorough knowledge of software design patterns, but he also should have an awareness of deployment best practices as well as development best practices (PSRs) ― and know the complexities of Magento configuration. Magento has a lot of power in its Admin Panel, and oftentimes, development is not even necessary.

Magento 2 Experience

Nothing replaces experience. You may argue with me on this point, but I know I’m right…

Since its General Availability (GA) release occurred back in November 2015, Magento 2 is now approximately 36 months old, which is ample time for a Magento developer to have been part of a single project or even multiple Magento 2 projects.

What About Certifications?

Certifications for Magento 2 development have now been available for a few months. And, though certification is one benchmark, it’s not the true indicator of an expert Magento developer. The mark of expertise in Magento: the ability to reference a highly functional commerce site or two.

Could a Magento 1.x Developer Work in a Magento 2 Environment?

Absolutely, but, it’s quite a paradigm shift, and taking the Magento 2 Fundamentals class is highly recommended. Again, nothing beats practical experience (as I may have said before).

Magento 1.14 is slated for depreciation in June 2020, which means that the value of Magento 2 resources is on the rise, and, as a result, Magento 1-only developers are seeing a decrease in their value.

Ecosphere Participation

It’s important to hire someone who is excited about the technology, and one barometer of their enthusiasm is their level of participation in the Magento ecosphere.

Has the candidate attended Magento’s Imagine conference? Has he or she stayed active in local meetup groups? Or, has he had the privilege of writing an extension that’s available on Magento’s marketplace?

Even more impressive would be if the resource has been recognized by Magento for participation in the Community?

Partnership Experience

Another barometer of expertise is the developer’s relationships with other Magento partners, such as Emarsys, Klevu or Yotpo. Have any relationships been built externally to Magento, or have they been simply Magento only?

This isn’t a “make it or break it” type of qualification; but, more of one that suggests relationship building capabilities.

Align Expectations

Magento is more than just a complicated beast… it’s over 20,000 fun-filled files (and even more when including third-party extensions and custom code). No one resource is going to excel at it all. It’s certainly possible that a back-end developer may be able to work the front end (in a pinch), or vice versa. But, just because you have the capability to build a jet engine, it doesn’t follow that you can necessarily fly or pilot the plane.

So, be cautious if any one individual claims that he can “do it all.” Grand claims can lead to grand disappointments.

This is one reason we will continue to have success in our ability to manage a project with the most effective resources — the ability to cherry-pick from our pool of resources to find the best fit for the scope of the project.

Final Thoughts

So What’s the Ultimate Takeaway?

If you hire an inexperienced junior developer to develop your site, it will not be successful. And, while Magento is based on PHP, a PHP (non-Magento) developer will not create a viable site. We’ve seen this again and again: Your online business is not the place for someone to learn a new technology.

Hire the best and brightest — and your site development will be accelerated, which translates to a shorter time to market for your Magento site and commerce buildout.

Keep measuring and adjusting as needed. Any further questions? Feel free to contact us.

A Beginners Guide: Magento and Backend Integrations

For about 95% of our projects, there is some level of integration to a backend system.

The first step is to understand which data is to be utilized in your e-commerce environment.  The next step is to determine which system contains the master record of the data. Finally, the frequency at which the data needs to be synchronized across the systems.

While we don’t explicitly include reports (or BI) in this post; as it certainly deserves its on discussions, keep in mind data management will also need to be considered.

Eleven Points of Integration

There are several integration options available, including a simple FTP process, an MQ Series, Mulesoft, Dell Boomi, or Web Services. It’s often beneficial to use an integration methodology that is already being used, but it may make sense to change to a new technology. When deciding on which methodology to use, you and team need to consider the initial programming needs, ongoing support, and technical debt.

Our standard integration strategy looks eleven different integration points and related business logic and processes. The goals of each project determine which integration point is needed, and how it is used within the overall project. Typically, our project use four to six integration points, but we have had projects with only one or two, and projects using all eleven.

These points of integration are: 

• Catalog
• Customer and Addresses
• Inventory
• Price
• Tax
• Shipping
• Payment processing
• Order processing
• Order shipment (ASN’s)
• Order history
• Vertical specific (LMS or manufacturing data or other)

Identifying how those data points will be communicated between the ERP (Enterprise Resource Planning) and eCommerce systems will define your integration strategy.  

A good example of an integration point is inventory availability. The first business decision to be made is whether or not the eCommerce site should expose inventory availability to the shoppers and if so, in how much detail. Not every eCommerce site does, and those that do use a few different methods for sharing this information. Some sites show the actual number of products available, while others share a red, yellow, or green status to indicate availability. Another option is to simply provide ‘In Stock’ or ‘Out of Stock’ identification on the site. And, throw multiple warehouses into the mix and you have instant complexity.

These business decisions drive the type of integration required, and how timely those updates needs to be. 

Other non-ERP Integrations 

The integration between your eCommerce platform and other systems, like CRM, WMS, PIM, DAM, or other, probably won’t be as intensive as an ERP integration, but it’s still important to identify the relevant data. Focusing on the data, regardless of where it’s coming from or where it’s going, will help eliminate confusion and make sure all of your tools are working effectively.

Technical Debt 

Document all decisions! Document implementation details!

This is to help expedite future feature build, sustainment (managed services), and resource turn-over. It’s more expensive to create this type of documentation years down the road compared to proper artifacts development during the project.