The wild days are over

Warning*: this post is not about success. This post is about an ongoing process. It can be updated later as a disaster. hopefully, and it seems as, somehow it works.

---

Changing habits is hard. Taking well-settled developers, that are used to a cowboy-programming culture, and shifting them into an organized system, is a challenge. Most importantly, doing it without drawing the motivation and the well-being of the staff. That by itself is the most critical issue.

To enjoy writing, Ill exaggerate a bit: As a member of a struggling start-up, the team was consistently understaffed, with a hectic road-map. There had been periods when there been only three FE developers, but on three different countries, while the lead (me) was the BE developer, the in-house FE developer, the integrator, and the point on insanity. There been long periods where was no product, and features were defined just by a general wish. Thank goodness, the QA was someone with super-powers (I’ll write about recruiting inexperienced staff from none high-tech domains sometimes else). But there was no chance we would have the capacity to invest in quality, standards, or testing frameworks. Generally speaking, it was endless hysterical sprints into satisfying the next potential customer

So in that hectic culture, the situation was described best as…

But once the start-up did an exit, and been acquired by a global company, the situation had changed: there was a (rickety) roadmap, there was a product, a designer, the team had grown. More than that, we had the privilege and obligation to provide a codebase for a long-lasting stable product. And the obligation towards the staff: shift from hysterical sprints into a stable and healthy culture.

The goal was trivial: reliable docs, standardization of knowledge transfer, updated technology, coding standards, code reviews, full testing coverage, CI/CD, and so on. Basically, just be as it’s supposed to be.

But my starting point, as a FE team lead, was a very large and complicated APP, on outdated technology, with a small team of experienced programmers that are used to improvise the requirements, the design, and the layout. Have one big branch, that includes the feature and all the issues found on the way. The developer was used to have a look that everything seems ok, and send it to the one QA team member. Then the QA needed to understand everything without any doc around. Having only some limited e2e test as a safety net.

So, how do we making this happen?

First, living the plural tense. Everyone needs to be aligned with the goal. Everyone needs to understand the need. That the effort is profitable both to the individual and the company. And the individual more than the company, since the company can survive for a short period on an unhealthy foundation. But everyone and everything will flourish when each individual is on his best. This is why it’s a common goal, discussed, agreed, and understood by everyone.

Even if I’ll do my best effort, I won’t have the time to do all the possible mistakes myself. Each step needs to be considered based on research, challenged by a specific situation. Plenty of cool ideas been postponed since they just didn’t seem to work. Others, that works like a charm somewhere, just don’t suit our needs.

While reflecting the goal, it’s easy to spot the difference between the team members. The one that is eager to charge forward, and the other that’s more concern. The open-minded and the more solid person. Since I’m working with people, not resources, each member needs a different language and motivation. Each one is suitable for a different type of task, can handle it in a different way, on different milestones.

Changing habits is difficult and takes time. Doing it without any consultant or expressed guide means that plenty of mistakes done on the way. Been patient but consistent, knowing when to stop and rethink, compromise, and when to insist, is an art no one perfects, especially not be. But yet…

This brings me back to point one: living the plural tense. Asking for feedback to spotting the creaks and the resistance. Understanding the cause, tuning the process, or reflecting the purpose. Asking for better solutions, or explaining the details. Adjusting on the way to whatever works. Noticing the stiffed areas and rethinking there approach and timing.

How all this is reflecting itself into practical action points? like…

• Endlessly sharing the dream. Yes, I repeat telling the shared dream until I’m sick of hearing it, and then I continue. Continue until I hear the dream told by others.
• Adopting best practices, like commits best practice. Something that created a fascinating and wonderful daily protein of inner discussions about coding standards.
• Arguing about new challenges: Having POC’s while trying to invent the wheel.
• Demanding new standards like unit tests, even if that are still theoretical goals.
• Spotting opportunities and passions, like seeing a CSS passion in someone’s eyes.
• Demand a more stiff understanding and planning before coding, by shifting the responsibility of the design doc to the programmer. And along with that, solving the mess comes from misunderstanding, open issues, changes, or undocumented discussions.
• Using feature-flags to push towards CI/CD. And by that removing long bottlenecks, dependencies, and code conflicts.
• Placing the responsibility of the quality on the developer, by changing the definition of the QA from the “checker” to a “consultant”.
• Providing a safe culture for growth, shared knowledge, mistakes, and fun.
• Explaining, convincing, motivating, and mostly listening.

Well, this is what I’m trying to do, so this is what I’m writing about. Will it work? I’ll keep this blog updated, so keep reading.

To summarise it up I’ll use the expression told by the QA while presenting the two charts to the team: “The wild days are over”.

* Warning II: this post was supposed to be a technical post, about the new API/Integration testing framework I’m working on. But it ended without even mentioning it. With: Yarn, Jest, WebDriverIo, wdio/sync, mocha, babel, plenty of refactoring, and other buzz words.

The chard was created by the wonderful excalidraw.