Become a Terrible Data Engineer.

Simple steps anyone can follow to become the worst you.

Photo by Sander Sammy on Unsplash

Bored? Looking for a little spice in life? Have the desire to destroy some things? Well, look no further, I have the answer for you. Become a terrible Data Engineer, be the worst you can be. That just gets the blood pumping a little bit, be a nice change of pace.

I mean who doesn’t want to be a destroyer of teams? Things in life move too fast, want to grind all progress to a halt? No, maybe you just want more bugs and errors to fix, especially on the weekend and at night, forgetting the smooth-running processes that never fail, so boring.

Today I’m going to teach you how to be a terrible Data Engineering, so listen up, put down your phone, and let’s be as bad as we can be.

Thanks to Delta for sponsoring this newsletter! I personally use Delta Lake on a daily basis, and I believe this technology represents the future of Data Engineering. Check out their website below.

To be a Bad Data Engineer

Do you need a roadmap to become a bad Data Engineering? Well, you’re welcome. Of course, if you are of the mindset you want to do the opposite, for some reason, you could in theory become a good Data Engineer.

Do this to be bad.

It’s really quite simple, after all, being a bad Data Engineer. It takes very little effort and will probably cater to your leanings. Being bad is always easier than being good, being good requires real effort. Who has time?

Do these things and be a bad Data Engineer.

• Get distracted, and work as many tasks/tickets as possible … AT THE SAME TIME!

  • extra credit if you can context switch multiple times per hour.

• Take OOP to the next level. Multiple layers of inheritance, obfuscate, and shuffle things around. Make it impossible to find or debug anything.

• Make your functions and methods as large as possible.

• Make your function do as many things as possible. (side-effects)

• NO tests are allowed at all. NO unit tests that run locally.

• Delete your development environment, or don’t make one.

• Delete every README you can find. No documentation about anything.

• Be a Jerk. Clutter PRs with nit-picky comments.

That should get you started anyways.

Photo by Icons8 Team on Unsplash

Boiling it down. What Bad Engineers are Made of.

Ok Ok, maybe that list of stuff was a little too specific for you. I get it, you want a more boiled-down version that gets to the essence of what it really means to be a one-of-a-kind bad Data Engineer.

Again, I think I can help you.

We could probably come up with a few high-level groupings that can help you fit all your bad actions into a few specific ideals.

1. Hard to work with.

2. Spurn best Engineering practices

I told you I would make it easy.

Hard to Work With.

Being hard to work with is an art that must be practiced and can be refined and perfected. You can approach this problem from many angles, and the best hard person to work with is hard to work with in every area of life.

It can be PR reviews, new ideas, meetings, or code reviews, to be the worst you have to destroy them all. And, this will lead to the destruction of the Engineering culture, which is the pinnacle of achievement for Bad Data Engineers.

Spurn Engineering Best Practices.

Closely related to being hard to work with is the concept of Engineering Best Practices, which must be avoided at all costs. Not only are they to be avoided, but the opposite must take place. This is a critical step in being a Bad Data Engineer. If you allow Engineering Best Practices to take place or get a foothold, bad things will happen. Morale would approve, the culture would start to change, and many other tragedies.

It is utterly important that from a technical perspective, you do everything possible to break down structure, order, and things that are generally known to increase reliability and reduce problems.

You must turn your nose up at all things automation, clean coding styles, and practices, or any kind of tests whatsoever. Again, all these terrible things tend to bring peace and calmness to otherwise chaotic environments. Avoid them.

Conclusion of being a Bad Data Engineer.

It’s hard to list every single thing it requires to be a Bad Data Engineer, the list would never end. But, this should give us all a good start. What’s important to note is that being a Bad Data Engineer encompasses both technical and non-technical skills.

It’s important to realize that bad technical descisions impact the Engineering culture, and a single Bad Engineer can deploy an amazing amount of damage to both technical systems and persons.

Go against the grain, be bad. Never focus, hate all things new, grind PRs to a halt, destroy meetings, and avoid commonly held best practices at all costs. If you can do these things, you will be all means enable a culture of chaos, breakages, crisis, bitter and angry people, and many other wonderful things that are hard to describe.

Go forth and destroy.