The 3 Nemeses

Last week, I was having a beer with a co-worker and we were talking about the new engineer joining the team the next morning.

The new dev just got out of school and it’s her first job, so we wondered: what can we share with the young recruit? What are the mistakes we’ve made that she should not repeat?

We thought it could be fun to describe these mistakes as 3 nemeses that live inside all of us (devs).

Nemesis 1: John-Dev

“It works!”

John-Dev loves when the feature he’s been working on for hours finally works!!

It’s a moment of glory, of intense pleasure. John-Dev is so happy that he tells everyone that this amazing feature is Done.

He is so happy he can now move on to the next feature.

But John-dev forgot that his dev-environment is not the real world. The real world is 💚production💚. And between your computer and the end user’s computer, well… There is a world.

Because this is what happens in-between:

• John-dev’s pull-request got rejected — he was introducing a huge regression
• After the merge and the deployment on staging, he realizes that there is a bug he could not see (oops he does not have a production-like database) and has to fix it. Easily, he finds the bug “Lol I could have seen it”. Just another pull-request and we’re done.
• The next week, after the push to production, the feature is finally here, the users will finally use it! John-dev has completely forgotten the feature. He did it like 2 days ago, he moved on. But — oh damn — the third party API he was using is just a little bit different than the one from the sandbox environment 🙃. He forgot to add the header X-OopsThirdApiWasNotThatClearInTheDocumentation. John-Dev thinks, “I known exactly what it is” and in a matter of seconds, the pull-request is open with the fix.

What went wrong?

John-dev made a lot of mistakes!

But that’s not the problem here. We all make mistakes and we will keep on making mistakes. The perfect deployment of a feature may hopefully happen one-day. But the day after, for sure, we will make a new mistake.

The problem is that John-dev said “It works” 2 weeks before it worked, and he said it was working all along as well. Who will trust John-dev now?

From now on, the whole team will be afraid that when John-Dev works on something, they will have to check themselves if the job is actually done.

What to do ?

Be precise about what is done, and beware of your self-confidence, be humble.

Nemesis 2: The Silent Hero, Master of Shades

Almost done. I’m moving forward.

The Silent Hero works behind the scene. He does not show his work, mostly because it is not done yet. As you know some features are very complex and need deep concentration for multiple days. It would take too long to explain for the Silent Hero, he just needs “more time”.

When coding a big feature, the Silent Hero dives alone into the battle. He can do it by himself, he sees the path.

But if you take a look above his shoulder, this is what happens:

• During the daily the mysterious Silent Hero remains discrete. When asked how is his sprint going so far, it just answers “I will not merge yet, as the code is not as glorious as it shall”, small adjustments must be made. “Trust me” he says.
• After 2 days of small adjustments the merge request is opened. The Silent Hero splits his work by commits of course. 1 commit per day. git commit -am "feature(AwesomeStuff): the achievement of Tuesday". So easy to read.
• Oops — merge conflicts. “I will take it!” he says. “Give me an hour”.
• After an hour, all merge conflicts resolved but… Bugs. Bugs everywhere. The Hero’s journey is not finished just yet. Just another day.
• The Silent Hero learns from his mistakes: He now rebases every morning. What a pleasure to start your day with a rebase. It’s like reading a pull request while coding and debugging 😋. Heaven on earth.
• It’s finally merged but it comes with a surprise: The mighty Feature Toggling. Feature Toggling could be used to deploy under-development features, but its true power resides in the application of the John-Dev-Silent-Hero theorem: “If it is feature-toggled in production and if it works in dev ⇒ it will work in production”.
• The day finally comes when the Epic feature ready to be released. But wait! An unexpected bug occurs! Everybody is stunned and unable to react, the Hero meditates “I have dreamt of this day”. Everyone asks “what is happening?”. the Hero, in its reinsuring voice “This is my burden, I will deal with this alone”

What went wrong?

The Hero does not allow his team to challenge him. How can the team improve the code?

The Hero, while working alone, based all of his work on a library/pattern/architecture/naming strategy/vocabulary/technology that is not project standard. Now that the feature is developed we would need to change the basis of the code, we won’t. How do you ensure project standards?

The team will now be dependent of the Hero. What happens when the Hero is in holidays?

Nemesis 3: DoctorJS

It is more complex than you think.

DoctorJS does not talk about users, features or product. His stakes are much higher.

During the daily, while his coworkers discuss:

1. “Notifications”
2. “Third-party integration”
3. “Login”
4. “Search”

DoctorJS mumbles letters and words like:

1. “WebSocket ports… Nginx”
2. “Webhook payloads”
3. “XSS CRSF JWT OAuth2 RFC”
4. “Elasticsearch index”

But if you pay good enough attention, this is what you’ll hear :

• During the demo in front of the whole company (non-tech included)
• DoctorJS proudly says: “the webSockets are enabled!”
• Everyone “But what is it Doctor?”
• DoctorJS: “It is a bilateral connection between a client and a server”
• During the weekly product meeting:
• The product says: “Users need to be able to search with keywords”
• DoctorJS says: “OK I’m installing Elasticsearch, it is the standard technology”
• Rest of the team: “What kind of search? Where?”
• Product: “The search should look into the Label, Description and the Title fields”
• DoctorJS: “We should use an index, like Elasticsearch”

What went wrong?

No-one cares about the technical parts of the feature during a demo. NO-ONE.

As they should because — at that particular moment — it is not important.

The important part is that we can send real-time information/notifications to our users. By talking tech stuff we lose the audience and we do not challenge the features. Without external feedback, how do we improve the product?

No-one cares about the technical parts of the feature when discussing how the feature should work. It is just noise. The developer’s responsibility is to offer all the available technics and time it involves. By talking about technology, the debate is centered on which type of index we should use, while the problem now is that users cannot search.

The important questions at this moment are “where to put the search bar” or “what it is supposed to do”.

DoctorJS has forgotten that you can do a filter in the browser javascripts (🤮), then do a search feature with SQL queries (😬), and that, maybe, in 6 months, IF we need awesome performance to reach our market fit, only then, then we’ll think about indexing.

By adding complexity to things that should remain simple: How do you give the means to your team to prioritize the features?

Give us feedback! In the next article I’ll talk about Friar Tuck, and the Misunderstood Artist. Please share your bias, cliché, situation or nemesis, from the tech and non-tech point of view:)