Can we make it more generic?

I remember many horrible mistakes. I think we can learn a lot from one that looked innocent at the beginning and then turned into a monster.

We had a small function:


It searched through the event log, looked for “error” events and then it was looking for “error fixed” events. If it could not find one, we returned the event as an unfixed error.

One day we decided that we must make it more generic, because someone may need to use it for different purposes. After all, it was an event log. You can store anything you want, not only errors.

Because of that, we changed the friendly name of the function to:

    eventType: String, anotherEventType: String

First of all, I have to apologize. I am sorry for creating such an abomination. It is wrong on so many levels.

Would you like to help fight youth unemployment while getting mentoring experience?

Develhope is looking for tutors (part-time, freelancers) for their upcoming Data Engineer Courses.

The role of a tutor is to be the point of contact for students, guiding them throughout the 6-month learning program. The mentor supports learners through 1:1 meetings, giving feedback on assignments, and responding to messages in Discord channels—no live teaching sessions.

Expected availability: 15h/week. You can schedule the 1:1 sessions whenever you want, but the sessions must happen between 9 - 18 (9 am - 6 pm) CEST Monday-Friday.

Check out their job description.

(free advertisement, no affiliate links)

The name is extremely long. I used to write very long names. A few years ago, when I was still using Windows XP, I learned about the path length limit because of a long class name. I hit the Windows XP path length limit… repeatedly.

The second problem is the fact that the function is “stringly-typed.” Event types are just strings. If you want to know why I think it is a horrible idea, read this blog post.

By changing the function name, we increased cognitive overload. We wanted to make it so generic that we diluted the meaning. It used to be easy to read and understand. The new name of the function makes you think. There is nothing wrong with calling a function “get unfixed errors” if you use it only for that purpose.

We exposed the implementation details in a righteous attempt to increase code reuse. Nobody needs to know if we store errors as events. The sad fact is that we use this function only to find unfixed errors. We don’t even care about other types of events.

No reason

Who wanted the generic version of this function? Nobody! Nobody cares whether the function looks for events without subsequent events of another type. People wanted to use it only to find unfixed errors.

Let’s face reality. We write generic code to look cool. Abstractions are tools. We like creating tools. We like it because people like us use our tools. Other programmers may appreciate your cleverness. The users never do it. They admire the work done by UX designers.

We, the programmers, need to focus on solving the problems we have, not the problem we wish we had. We must not create needless abstractions only because we think they may be useful one day or because we want to brag about the cool library we wrote.

Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you want to contact me, send me a message on LinkedIn or Twitter.

Bartosz Mikulski
Bartosz Mikulski * MLOps Engineer / data engineer * conference speaker * co-founder of Software Craft Poznan & Poznan Scala User Group

Subscribe to the newsletter and get access to my free email course on building trustworthy data pipelines.