Tech Side of Success in Education

When I meet team members for the first time, I don’t know them, right? To know them better, I look at how they perform a few tasks and if they are able to accomplish them within a 2-week sprint. Another thing that matters is how they communicate with one another and what they do together to bring out the feature within the deadline. And if something is difficult for them, I look at how they shift tasks from a Junior to Senior Developer.

I myself try to make everyone more comfortable, too. There can be small things here and there that need a bit of tweaking and more time in case of emergency. If there’s a complex and important task to be released next week, I’d make sure developers have 20% fewer tasks in general so that if something goes bad, developers could fix it in no hurry. I think such an approach makes everyone a bit happier and we get more things done in the end.

Anadea's educational software development team made a great contribution. It’s amazing to see the way developers build the platform sticking to the deadlines and making sure things go right. And the team roles are very clear: we have Technical Lead, Business Analyst, Scrum Master, and developers.

If something was not communicated well, a Business Analyst came and broke it down for the team in clear terms, and Tech Lead explained things if there was something way too technical. So as far as I can tell, it’s very much the team’s contribution to what our hybrid learning platform is like today.

For some businesses, such mistakes cost millions and millions of dollars.

And of course, you need to look at things from the customer’s perspective. If the code is bad and things don't work, customers simply won’t return to the platform. That’s it, bad code affects pretty much every side of the business.

It's technically really difficult to estimate the code quality. Sometimes there are 100 lines of code, 98 of which comply with the internal standards and 2 don’t. My advice is to automate all that can be automated. What I do is let programmers know that something’s going wrong in these 2 lines and needs to be fixed, and for that, I use the SonarCloud platform.

It goes through the code and then tells the developer to redo their changes. In sum, the Senior doesn't have to look at the code to find issues as the program finds them and reports back to a business owner.

When building your platform, it’s all about trusting your gut - you’re just hoping that you're choosing the right developer for the job. You can use platforms where they have to do coding exercises so that you know that the developer is okay based on their results. The next step would be interviewing. In the dev’s CV, you can see the number of years of their experience, and there’s a big difference between two and, let’s say, six to eight years of programming.

In the first case, a developer has been probably building only basic functionality, while in the second case, they’ve built multiple things. Then, you’ll need to understand if the person fits the project if they share your team’s vibe, morale. So if all three work out, I’d say that is a really good starting point, if no other issues arise.

Efficient, maybe that's the word. Engaged - they never mind hard work! And, eventually, trustworthy.