Rapid Application Development (RAD) right now is red hot. Thanks to a resurgence of interest in RAD, the Mendix Community continues to grow rapidly. If you are interested in combining your business knowledge with a touch of IT, it might be time to hop on the RAD train.
To get onboard you need a valid ticket. Specifically, a ticket certifying you as a Mendix Developer. Let me help you a start the journey by explaining why it is important to approach learning Mendix in a structured fashion.
A proficient (Expert) Mendix Developer should have the following: Mendix Knowledge, Mendix Skills, Technical Skills and Soft Skills.
In part one of this post, I will focus on Mendix Knowledge and Mendix Skills.
As with any other acquired skill, developers need to attain a base level of knowledge before putting it in practice. However, obtaining the right level of Mendix knowledge needed to put into practice can be challenging.
All thought this course provides you all the in’s and out’s you need to get started, there is a pitfall which is overseen by many. This famous graphs points out a nice pitfall we all have experienced. (If you haven’t; you are either a genius, you haven’t learnt anything in life or you are still a beginner or a hazard, I do opt for the latter.)
This graph points out the knowledge you think you have vs. the knowledge you actually have. When you have the idea that you have the right knowledge in the pocket, the trigger to investigate and learn new things reduces. Until the moment you realize that your imagination and reality have a certain offset.
This is especially true when it comes to a great platform such as Mendix, which provides a lot of out-of-the-box working components. It becomes tempting to think you can build anything in Mendix with your recent learnings. The sky’s the limit and everything is awesome—until the moment you reach a certain height and your data and microflows start melting in the architects strong presence.
I strongly believe that self-paced learning is the best way to start gaining knowledge. But make sure you have someone who challenges you, reviews your work based on your learning and shows you the knowledge yet to be discovered. In effect, they serve as your mirror during the Hazard phase of your ongoing professional development.
Here’s an example of how the process should work: During a recent Mendix Competence Bootcamp presentation a participant shared a nice microflow. The microflow validated that homework due dates matched the teachers’ working days assigned to the affected Class (YearGroup). After creating this microflow and testing it on its behavior, all signs were green. It worked as expected; days were determined correctly and validation messages were given correctly in all scenarios. So, passed the user acceptance testing?
I won’t discuss the exact details of this microflow, but let’s compare the two microflows below. The first one is the original microflow working as expected. The second behaves precisely the same way. The user will experience at least the same validation behavior, except that this microflow is an optimized microflow, executing the validations in a more logical (and data effective) order and the involved data is limited to what is really required.
Without discussing the exact details, you cannot model the second microflow if you don’t have the skills to use the tools in the right way. This can be achieved only by getting the right knowledge and being coached on how to do it right, also known as feedback.
Note: For those interested, use the below links to open the Mendix model-shares and compare them.
The previous example is based mainly on knowing how to optimize the workflow. But to apply it correctly, you need the next element of becoming a proficient Mendix developer: skills. The value of this investment is often underrated.
Knowledge is like the hammer for a craftsman. It is a tool. The craft is having a hammer in your toolbox. It’s all about the ability to know when and how to use it. The same applies to the Mendix Knowledge for a Mendix developer: After taking the Rapid Developer learning path, the developer must learn how to use the tools and options in the most correct and effective way.
Let me take you through three important ingredients of building skills: practice, failure and feedback.
Practice Makes Perfect
Everybody knows the saying, “Skills comes with practice.” The challenge is in knowing how much and when to practice. Building skills can’t be accomplished by practicing something once or at a low rate of repetition. The best way of building your skills is by practicing repeatedly in a condensed amount of time. Pick tasks relating to the same skill and practice it repetitively. Take the time to really understand what contributes to the success of finishing the task. Was it the way you modeled it (technique) or the way you approached the solution (process)? In time, you discover that the technique is less important than the process.
"To improve your performance, you need to practice frequently, and get lots of feedback to make sure you are practicing correctly.”
At first, failure is often seen as a negative. The truth is, failure is part of learning to improve. Failure is the starting point. If everything goes well, there is little incentive to grasp why it is going well. If stuff breaks, you need to find the root cause to fix it. Those are the moments when you learn the most. When you take time to grasp the root cause thoroughly and how to fix it, you will never forget how it was done or make the same mistake again.
It’s very important to have the ability to fail without consequences. Blowing up the application, caused by a wrongly placed commit, is a great way to learn. You will never ever do that again. In a project simulation, this can be done without doing any real harm.
Last, but not least, ensure that you get a lot of feedback. Allow an expert developer to review your work. This feedback is key to your success. Without this feedback, having a working application isn’t the proof in the pudding you might think it is. It might work for now, but what if something unanticipated goes wrong later? Use the experience and knowledge of an expert to answer that one most important question: Did I solve the puzzle correctly?
How to Practice, Fail and Get Feedback
Learning on the job is often the way building skills get addressed. There is a project with requirements, and a team to collaborate, and they’ll assist you by letting you practice and gain feedback. Hopefully, your effort will directly add value to the project. Just remember, the goals of a learner and a project are, by definition, not aligned.
Learner: I need to practice/deepen certain skill sets.
Project: You need to focus on delivering new awesome applications and features quickly—not necessarily related to the skills you need to practice. And, by the way, we have deadlines to meet.
This tension between learner and the project doesn’t always fit well with the learning curve goals of a beginner. If you want to increase the speed of your building skills, then get out of the project and allow yourself to focus on practicing. Start a project based on a real-life scenario with real-life requirements, but focused on practicing and not meeting the project goals and deadlines. If something is more difficult to grasp, just do it again. Pick another assignment, a different setting with the same learning/practice goals. Model, test, fail, learn, repeat (and ensure you get feedback!!).
So, learning on the job is not wrong. But, it needs to happen at the right moment. First, build a basic level of skills. When your basic skills are at the right level, you can directly add value after joining a project team. Because then you have a right level of skills available to build upon.
If you want to know more about how we create a fail-safe project setting at Mansystems Academy where feedback is provided, take a look at http://mansystemsacademy.nl or contact me directly @ firstname.lastname@example.org.