I’m hoping you all might be able to help me build a “job description” for someone who would make a great Moqui developer. What kind of experience would be required vs helpful? Should they have a university degree? How many years of experience? Required technical skills? Anything we should avoid? Etc.
We want to continue building Moqui-based solutions for customers and want to identify a viable path forward. While we will likely continue working with our current vendor’s developers (we have a fantastic relationship with them), we suspect having talent in-house will be required in the future as projects scale. Additionally, when we get to the point of having an entire in-house team, it might be nice to look back and say, “this is where we started.” This type of information could also be useful for other companies looking to build with Moqui, thus encouraging the continued growth of this community.
Thoughts?
Sometimes an inexperienced person might be in the position to implement Moqui and make a huge impact for their business. There’s nothing wrong with that!
I can’t say I’d recommend an inexperienced person. A degree is here nor there…so long as their programming principles are sound.
We’ve had a hard time sourcing good Moqui developers…most of them just want to write groovy, which works but is considerably less maintainable…Moqui really takes care of so many things itself when you use the XML interface. We even had a developer that would write XML or find some existing XML service…and then copy the groovy out of the service detail in the service reference.
Anyway, a strong programming background and a lack of a “there is only one way to do things and I’m going to do it this way” attitude would be high on my list.
Someone that is familiar with the universal data models would be great…as new developers really think they need a new table for everything. We have maybe a million lines of Moqui code, and we have maybe 10 additional tables, and 10-20 extended entities.
Groovy and Java experience are not minuses; but, like I say, the tendencies we’ve seen is programmers don’t use the XML interface…and who even remembers what a method with 9 arguments does?
To fully understand who to hire for Moqui development it’s helpful to understand what actually goes on in Moqui and what most common tasks will be. Some of the types of technology that are needed for Moqui development are:
What I’d look for when hiring Moqui Developers is experience with the following:
- Web Applications like html, css, javascript, HTTP, RestFul APIs, Web Servers (Apache, Nginx)
- Web Application Frameworks like Spring, Express, DJango, Ruby on Rails, etc.
- Object Oriented and Type Based Programming Language Experience like Java, Groovy, C++, Python, Go, Rust or others (especially JVM based languages).
- Dealt with complex software like more than 10,000 lines of code
- Software tools like Docker, Gradle, IntelliJ, Git
- Active Github / Gitlab Profile
@NickDragon hope this helps. This certainly isn’t a complete list and non of these are absolutely necessary, but this is what I’d look for.
@NickDragon thanks for posting, this is a hot topic in the community. I agree with @sbessire on willingness to use XML and understanding what is already there in the data model and how to use it.
My two cents is that if I were hiring someone today I would be looking for people with techno/functional ERP experience. Understanding of the domain goes a long way in speeding up the learning curve and anyone who has worked with other ERP systems will understand customers, orders, invoices, products, etc. This might also be a way to get around the tech problem. People that have worked in environments like SAP, Oracle, Netsuite, etc. use the tools available in those systems and will have different expectations about tools. The primary skill set they bring to the table is ERP, not general / custom software development.
There will always be a need for specialized skills to build apps that interface with Moqui. Brainfood has shown some examples of their work in our community calls and if you go the direction of headless commerce you can build a UI using whatever you want. As long as well defined APIs are exposed to those developers you can maintain a clean separation of responsibility and they do not need to know or care what is under the hood.
You all nailed the point behind this question. I know we’re not going to find many folks who have experience programming in Moqui, but I’m trying to figure out what programming/technical knowledge is important for someone well equipped to learn.
A couple of you eluded to a willingness to use XML. Is that something people are getting away from?
Universal Data Models is also something that caught my attention. Thanks for pointing that out.
If anyone else has anything to add I’d love to hear a few more perspectives.
The points from Michael are pretty much inline with my answer to this question, on general Moqui development without any further details (like build an internal/ERP sort of app, build a transactional website, build integrations, customize existing internal or ecom apps, etc). In other words, someone who is familiar with webapps (HTML, JS, CSS; HTTP, REST) that are backed by a relational database (SQL, normalized data models, etc). That is sort a basic minimum, familiar with those things in some language and framework… even if not Java/Groovy and Moqui.
On the using XML thing, that is probably referring mostly to the XML Actions in Moqui, which is basically a bunch of XML elements for common operations that get translated into Groovy to execute. The reason for XML Actions is they are less error prone for common things, and fit better into other XML files like Screen and Service definition XML files. That brings up the next layer up that using XML might be about: XML Screen and Service definitions.
As other have mentioned, these are tools that dramatically increase developer productivity for the types of user interfaces and logic they are designed to address, but are often quite different from what developers are used to. Some developers balk at these because it is something new that they have to learn, and it isn’t from a massive company like Google, Oracle, Microsoft, etc so they don’t trust it and want to learn it.
This is sometimes an attitude problem as much as anything else, especially in a job market with so many open positions where a developer can find a job doing something they are more experienced and comfortable with, something easier and less complicated that doesn’t involve learning new things… or if learning new things is involved they are things that the developer sees in tech media (which is dominated by large companies).
That side of the tech industry is unfortunate, that so much is dominated by large corporations that peddle a lot of nonsense that most companies don’t need, but many developers are also reasonable and interested in more efficiently creating solutions, including the learning required for that and the opportunity to put in effort over time to make producing results more and more efficient. Maybe as much as anything to look for in people to hire this is the most useful for a prospective recruit to offer in terms of what will lead to high productivity and quality results.