Advice For New Network Engineer

ImYourOnlyDJ

Hi all,
So it's not official yet but looks like I'm getting promoted into a Network Engineer position. I'm currently a technician (hybrid systems and network) for the same department so I'm already familiar with the environment. I just wanted to get some advice on how to start off strong and continue to become the best network engineer that I can be. I knocked out my CCNA a few months ago and obtained my CCENT, A+ and Net+ before that. I've just finished reading the Network Warrior and I've been studying for CCNP Switch ever since I passed the CCNA. My current plan is to keeping going to CCIE R&S along with some other Cisco certs and eventually get a MBA and switch over to the business side (like 15+ years down the road).

So any tips, advice, and book recommendations that will help me become a great network engineer would be appreciated.

networker050184

Biggest problem I see with new engineers is they never think long term. Think supportability, think scale, think about Joe Schmoe who will log in and troubleshoot it without knowing what you were thinking when you engineered it. Keep it simple. Too many times people come up with one off, complicated solutions to problems. Just because something technically works doesn't mean it should be done. Really the reason experienced is so highly valued in this industry. Think like a vet from the start and don't learn the hard way!


Good luck!

jdancer

If you don't know Wireshark, I suggest you learn it. It's great for packet capture and analysis.

Iristheangel

Here's a couple things:
1) Documentation - Write it, love it, update it often when needed. I liked to create templates to try to standardize upon. For example, if I'm going to be building out a site and then handing it over to ops to maintain after, I try to think what is the most relevant information I could write for them so if they get a call that something is down in the middle of the night, they can quickly troubleshoot. Plus if you're still working at the company, you ideally don't want them to call you with questions like "How is IDF 1 connected back to the MDF?" in the middle of the night. Here's a little template I made. Feel free to use it or modify it or just create one of your own: https://app.box.com/s/jibtu054po9z4o6y6iyullbrf66p8prj
2) Always be labbing - Got a new idea for something you think will work in production to solve a business problem? Prove it out. If you don't have the physical lab, use VIRL, GNS3, etc. Usually during Change Management meetings, you'll get ask how you know a change is going to solve a problem or work. Labbing it out, writing up a justification and taking screenshots will strongly help your case
3) This is one that most engineers cannot do: Learn to speak to the business. Ok... So you need those fancy new Nexus switches in our data center because they're new but what's wrong with our old 6500s running CatOS? Be able to explain the levels of exposure the company has in regards to compliance with old code, availability risks with unsupported hardware, risk of storage corruption without a reliable transport, etc. Management tends to not care or understand protocol speak so you need to tie it back to the business with other terms and make it important to them in that way
4) ABL = Always Be Learning (or Labbing) - This is the difference between an engineer that can move up ANYWHERE and one that *might* move up in that company but is limited everywhere else

That's all I have for now. The guys above covered it well

shodown

My 2 cents.

and an add on to the excellent information you have.

How does X solve this problem.

For example. If you are going to configure BGP what business problems does it solve? What are the short term and long term of using BGP vs option Y. These are the things that I think separate an admin from an engineer.

ImYourOnlyDJ

Thanks for all of the advice! A lot of what was mentioned I believe are areas of improvement in both myself and the department. I should elaborate that I'm a bit nervous about jumping into this role with limited networking experience (7 months production and about half of that only having read only access) and going right into an engineering role. Though sounds like at first I will be doing mostly break fix and simpler projects so I won't completely get thrown to the wolves. I'm just glad that they recognized my potential and eagerness to learn.

pevangel

Ask questions! So many new engineers are afraid to ask questions especially technical questions because they fear that they might look stupid. I'd rather take the small chance of looking stupid but learning something new, than pretending to know something but not having a clue.