“A good engineer is a lazy engineer,” some will say. And to a certain extent, it’s true: Laziness is a great quality if you’re automating repetitive tasks. But laziness flies in the face of learning new technologies and getting new work done. Somewhere between Junior Systems Administrator and Senior DevOps Engineer, laziness no longer becomes an advantage.

Let’s discuss the five laws aspiring DevOps engineers should follow if they want to become great DevOps engineers.

1. Forget ‘I don’t know’

The first thing great engineers should do is to banish the phrase, “I don’t know” from their vocabularies. The impression that the phrase “I don’t know” makes is the verbal equivalent of throwing your hands up in defeat (before you ever get started). Banishing the phrase is difficult to do. But saying, “I’ll have to do some research,” or “I know someone that might be able to point me in the right direction,” sounds much better. The point is: If you’re discussing something as a possible task, chances are good that you’re going to end up doing it. The fact you or anyone else in the room does not know anything about it is irrelevant.

Treat every task as an opportunity to learn. Dedicate the time necessary to become the resident expert in the task at hand. Prove to yourself that you can teach an old dog new tricks. Prove to your peers that you can enable the team to go further. Seek out new knowledge and improve upon the things you build and maintain. Do not be afraid to dive headlong into something you know nothing about. Your thirst for knowledge should be unquenchable. You might not know it today but you can know it tomorrow.

2. RTFM

Documentation is everywhere. Solutions to complex problems are at our fingertips. Make an effort to not ask your peers how something works without reading its documentation first.

Your peers spent time writing that documentation for a reason. Time is life’s most precious resource. Don’t waste theirs. If you have questions after reading the documentation, then feel free to ask. The same goes for man pages. Developers spent time creating those documents. OS vendors put the tooling in place for you to install and read them. The more effort spent on something, the more important reading becomes.

In the absence of documentation, read the code. It’s bound to contain comments or notes on decisions that affected how it works. At the very least, make sure you understand the contents of the code repository. If the repo is not following the methodology of a twelve-factor app make sure you understand where it falls short. When you do end up asking questions, make sure you do so in a positive manner. Being positive is sometimes difficult to do. As an outsider you are missing the context that lead to the decision. Never forget that iterative improvement is the modus operandi. RTFM!

3. Search before asking

How many times have you read how to do something—then needed to ask how to do it? The answer is likely, “zero.” You probably have team members that can answer most of your questions. On the rare instance in which you must consult your manager, make sure you have at least searched for possible answers. A long time ago, someone told me, “Don’t bring me problems. Present solutions to me.” It’s quite a simple statement that has such a deep meaning in DevOps. If you are discussing a problem, you’ll likely play a part in its solution. Instead of going to your leadership with a problem. Present the problem and your solution to it.

The solution to your problem will not fall out of the sky. Solving new problems requires searching for new answers. We live in an amazing time: a vast majority of human intellect is available to us with a few keystrokes. If you are turning to leadership without at least searching for an answer, you have failed them.

You are in your role to do work that your leadership has determined they need someone other than themselves to solve. The least you can do is self-manage solutions to problems.

4. Anything is possible. Never say never. Trust but verify.

Too often I see amongst team members a feeling that something isn’t possible. The beautiful thing about working in DevOps is that physics is the only limit in your environment. You can’t send more electrons over connections than what’s physically possible. You can’t store more blocks on a hard disk than what’s physically possible. You’re also limited by time (business deadlines and time are the most usual limiter). This means you have an amazing capacity to do anything to which you apply your effort. Anything is possible in this space with proper time, coordination, and effort. You and your team members should remind yourselves of that on a regular basis.

You exist because of technical debt. Whether and how that debt exists after your time on the project is up to you.

When it comes to complex, distributed systems—or even simple scripts—you should never assume anything. Remember, anything is possible. This means great solutions can end up in production as well as poor ones. Almost every place I have worked has had a team that has made an assumption about the way their systems work. There are various reasons why these assumptions exist. There are various reasons why these assumptions exist, but the fact that no one has ever performed a deep dive to ensure the systems work the way they assume they do should be perplexing. You should always trust your teammates; Yet if something feels weird or doesn’t work as expected, you need to verify whether the assumption is actually true.

5. Acknowledge technical debt

Technical debt is the result of decisions that made sense at the time someone made them. But those decisions are likely causing issues now because they no longer make sense. What got the product out the door a year ago under a tight deadline is likely going to hinder you from doing the same thing this year. If you are on a DevOps team, you are either helping to eliminate technical debt or you are pushing it to production. Often times you have to be the voice of reason in the planning sessions saying why something won’t work long term. This can make you an outcast if you are not careful. Treat these moments as opportunities to teach others around you something new. Do not act surprised people don’t understand why what they are discussing will add complexity later on. It is your job to understand the complexity of the systems and stacks you are supporting (not theirs). Put your foot down if you have to. Keep in mind though, if you are having to put your foot down chances are you need to align yourself closer to the beginning of the project’s feedback loops.

You exist because of technical debt. Whether and how that debt exists after your time on the project is up to you.

Conclusion

An unquenchable thirst for fundamental systems knowledge is necessary for success in DevOps. Great DevOps engineers constantly seek answers to questions and solutions to problems. To become one of them, make preventing future technical debts a constant focus of your work. Never stop learning. Laziness just won’t get you there.

This article is part of Opensource.com’s forthcoming guide to open organizations and IT culture. Register to be notified when it’s released.