Absolutely floored in a Net Eng. discussion today

I wanted to share this experience with everyone.

Today, I ran into someone and began some small talk. I mentioned how I'm happy to be here at the company I am at, talked about routing TCP/IP volume I and we discussed projects. Little did I know until AFTER the fact, but this guy is a Sr. Network Engineer within my company. As many of you would guess, being a Sr. guy/gal in Redmond, WA "probably" means you are one of the best on the planet.

He wanted to white board with me, I was excited - yeah, lets talk about Configurations and Protocols!

I was humbled and knocked down a few dozen pegs - a good thing!

...

We began to discuss how to do a code upgrade. Oh man, I jamp in - told him my methods of procedure, commands to upgrade code, the technical nat jab. He stopped me and said "that's not engineering, that's a technician talking". I've done this so many times so it took me off my game,

Cricket, cricket, attempt at recovery.

We then discussed how to load balance across interfaces between distro and core. Laid down the protocols, commands and technical nit gri- "thats not being an engineer man, thats being a tech break/fix". "Well -uh, uh, um..."

Cricket, cricket, stumbled out of it.

After some more discussion, he told me his honest opinion that he see's me as a technician, a config guru, a copy-paste-show command-debug guy. He assessed this based on my approach to answering "WHY" questions with "HOW" answers - promptly sharing his "answers" and approaches. I asked for advice on being more design, engineer oriented but I didn't get a solid answer because there really isn't a way to teach that experience. It really dawned on me that it really is a completely different mindset to be Engineering & Designing versus everything else. I really never stepped back to think about it - but it's true!

...

I then learned this guy has been doing Sr. Engineering and Architecture alone longer than my entire span of experience. It really humbled me. Is my ego and pride hurt? Considerably (it sucks), but I feel it's a great way for some reflection.

Never been so eager to study, read, listed and go forward.

And so is life. Nothing wrong with knowing the in's and out's of a protocol, but maybe it's time to start considering it from a project, deployment lifecycle and technical justification perspective as opposed to what configurations, tweaks and tricks I can do to "gear head" a solution.

~

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

lsud00d

That's awesome man, great to see you got some very powerful take-away in such a short amount of time.

I agree that there are key differences between not just engineer and technician, but analyst, admin, design/architect. Nuances separate things that go beyond just a title, however it's very cool to meet people who exemplify these roles AND if they let you prod, or they prod you...it's really something you cannot put a dollar amount on.

subsooner711

darkerz wrote:

I wanted to share this experience with everyone....snip
~

I guess I don't understand how he is able to so quickly point out you are a config guru, debug guy, and then not clearly explain why, or give you the advice you need to improve.

darkerz

subsooner711 wrote: »

I guess I don't understand how he is able to so quickly point out you are a config guru, debug guy, and then not clearly explain why, or give you the advice you need to improve.

I definitely understand why he came to his conclusions, what is important is - so do I. What I left out was his alternative approach to the theoretical s we threw around, the emphasis on justification, risk tolerance, design considerations, RFC knowledge vs. configuration, best practices, etc.

I couldn't put the entire 30-40 minutes into a forum post, but it was my first encounter with the Sr. facing folks here. It dawned on me, specifically, that their approach is entirely different than mine.

Could I accomplish a project, objective, ticket, etc. my way? Yes, but there is a difference between that and creating a solution for a business group that pushes 5 million / hour through one broadcast domain alone.

How to implement OSPF versus why, when, how is a good way to put it.

It was a neat experience.

Dieg0M

You might be an engineer but you didn't show it in your conversation. In order to demonstrate to someone that you are an engineer, you must not only demonstrate that you are knowledgeable, but also that you can use your ingenuity to apply this knowledge. The conversation shouldn't be oriented so much in HOW to implement something but WHY to implement it this way.

subsooner711

Gotcha...It just struck me funny that he could tell you those things, but not give you the advice you asked for. Maybe I just interpreted incorrectly.

RouteMyPacket

Exactly why it's important to be humble and keep yourself grounded in reality. There is a point where you go from "Oh, we could do this here..and this here" to "We need to do this here so this over here doesn't happen and it keeps things modular bla bla"

You should try to work with him as much as possible.

networker050184

I used to think I was a genius because I could configure all the protocols and knew all the cool CLI tid bits and trick. Then I got on the design/architecture team and realized that knowing the commands really has little to do with being able to accomplish real design and engineering. Anyone can google a command reference. Being able to plan out a three year sustainable and expandable network with little down time is a whole different ball game.

Polynomial

Every job has a different mindset to be honest. I'd be more concerned about showing eagerness to learn then trying to show what you know. It honestly is better received.

I was once told that you have to account for what you don't know you don't know. Changes the way you think.

darkerz

Dieg0M wrote: »

You might be an engineer but you didn't show it in your conversation. In order to demonstrate to someone that you are an engineer, you must not only demonstrate that you are knowledgeable, but also that you can use your ingenuity to apply this knowledge. The conversation shouldn't be oriented so much in HOW to implement something but WHY to implement it this way.

I sure hope I'm an Engineer, I'm definitely paid like one and they let me do very naughty things with unusually expensive boxes, cables & bits.

You hit it on the spot- the knowledge, experience and "book learnin" is all there but I lacked the ability to formulate and demonstrate it with business acumen. The "WHY" gaps were what he really pointed out. I wanted to share the story, because I have never been so directly confronted on how weak / the complete lack of a strong, meaningful, bull proof "WHY' to go with "HOW".

networker050184 wrote: »

I used to think I was a genius because I could configure all the protocols and knew all the cool CLI tid bits and trick. Then I got on the design/architecture team and realized that knowing the commands really has little to do with being able to accomplish real design and engineering. Anyone can google a command reference. Being able to plan out a three year sustainable and expandable network with little down time is a whole different ball game.

It's why I love this forum. I can ask questions and share war stories, then learn from others. Our cumulitive experiences and knowledge will seep into our everyday lives and future interviews.

RouteMyPacket wrote: »

Exactly why it's important to be humble and keep yourself grounded in reality. There is a point where you go from "Oh, we could do this here..and this here" to "We need to do this here so this over here doesn't happen and it keeps things modular bla bla"

You should try to work with him as much as possible.

Absolutely, I make it no secret I love being a gear-head but would inevitably want to lead efforts, projects & designs to improve the network.

I really appreciate everyones commentary and feedback. I know many of you are in very customer facing, management facing Engineering positions with gear'minded engineers & techs under you, so I love the feedback and suggestions.

Polynomial

darkerz wrote: »

I really appreciate everyones commentary and feedback. I know many of you are in very customer facing, management facing Engineering positions with gear'minded engineers & techs under you, so I love the feedback and suggestions.

I feel like the only person on this forum who wants to be the CIO someday.

I want IT management friends =(

EdTheLad

The guy seems a little up himself to me. It sounds like you work in configuration and implementation and he works a pre sales role trying to design a network. When i mean trying to design i'm putting emphasis on trying. I work as a test engineer which means i deal with design engineers everyday, most of the time their designs don't work as they don't understand the nitty gritty of how protocols work together. This happens as the design engineer moves further from the config aspect and more to a higher overview. Now if i heard one say how i'm a technician because i configure etc i'd probably punch him in his face. Maybe the guy you spoke with was rusty on the protocols etc you were chatting about and used the technician line to avoid going more in depth while at the same time making himself look superior, anyway some people are ******!

darkerz

EdTheLad wrote: »

The guy seems a little up himself to me. It sounds like you work in configuration and implementation and he works a pre sales role trying to design a network. When i mean trying to design i'm putting emphasis on trying. I work as a test engineer which means i deal with design engineers everyday, most of the time their designs don't work as they don't understand the nitty gritty of how protocols work together. This happens as the design engineer moves further from the config aspect and more to a higher overview. Now if i heard one say how i'm a technician because i configure etc i'd probably punch him in his face. Maybe the guy you spoke with was rusty on the protocols etc you were chatting about and used the technician line to avoid going more in depth while at the same time making himself look superior, anyway some people are ******!

Well, he was. Also, the technician line was insulting but it was a defensive response to not knowing the config, protocol and "how" process as well as I do.

That being said, if I want to be where he is in 2-5 years, I need to take out the petty & rude points (IT people aren't the most socially intelligent at times) and absorb the strong, reflective points.

A lot of interesting interpretations of my exchange, I appreciate everyones input thusfar!

~

N2IT

@ Poly nonsense I have 3 years of management experience and currently work as a BA developing SQL code and reports. I am pacing myself to make the next jump eventually, which should be an engagement manager role. Then eventually a director from there who knows the positions become very slim.

FloOz

I feel like this is a common thing for younger engineers. We are all about trying to get our hands dirty with configurations that we forget sometimes to look at the big picture and what actually goes into designing a highly available/scalable network. Yes we can read about it in the books but honestly that doesn't compare to actual full scale network designs in the real world.

thenjduke

Sorry but this guy has some manners to learn. He was a technician at one time and designing and engineering has alot to do with remembering that code and how to fix things because after you design the stuff and during a go live you are the one that fixes. After it is handed off to the support department they are going to come to you if they can not fix it and this is where you are a engineer/designer/ and technician. He needs to remember where he started.

jibbajabba

I am confused. You didn't know him and after some smalltalk he asked for a whiteboard session and only after it you knew what he is or does ?

If someone would ask me for a whiteboard session without me knowing him I would rather question the purpose of all that - but I guess that's just me (*)

(*) I must be missing something bleeding obvious here

bryguy

darkerz wrote: »

... a technician, a config guru, a copy-paste-show command-debug guy.

I think that probably describes a majority of us "techies" out there... Nothing wrong with that. In my last position, I had the title of "Senior Network Engineer" Did I do any actual engineering? No, that was reserved for a principal architects. Being the guy who racks and stacks, runs cable, and assigns IP addresses and configures VLANS isn't something to be ashamed of. We're the same guys who are awake at 3:00 a.m in the morning troubleshooting the network when a VPN tunnel goes down between HQ and the remote site.

Params7

So a person who has been skillfully networking for 20 years floors a person (OP) with quarter of his working experience. Doesn't look like he's growing humble with age though.

TBickle

IMHO, just because you have 18 years of experience doing something, doesn't mean you've been doing it right.

When I first started at my current place of employment, a lot of the veterans there would boast that they had been with my employer for 15+ years. Initially, i thought they had amassed this huge skillset and knew everything. That bubble burst a week later when I found out some couldn't even subnet and most had know clue about anything that didn't pertain to our network. That's what happens when you spend a lifetime relying on Cisco Business Partners to do all your design and configurations, and then Cisco TAC for all your troubleshooting.

Iristheangel

It also can be the way he asked the question. Saying "Let's talk about XYZ protocols" instead of asking "Why would you choose OSPF over EIGRP" or ""Which methods would you use to load balance and why would you pick one over the other?" or some question like that is going to illicit a different response.

It doesn't sound like he was entirely clear with what he was asking or expecting as a response and when you didn't respond the way he figured you should in his head, he tagged you a break/fix config guy. While that might be true or not true, the framing of the questions is very important or else everyone is doomed to fail this guy's standards.

Xyro

To me, it is irrelevant what this guy's true level of knowledge is but instead what you think/thought it was and how you responded to the situation. You came away from the situation with humility & an eagerness to learn more. This is what is important. I fully enjoyed your account of the occurrence and I envy you for it. I wish I could meet people like this, perhaps someday I will.

Jackace

I have to agree with some of the other people on this one. Sure this guy might have learned how to talk to business people about networks, but that alone won't make you a good network engineer. Sure the business people like that, but in my experience those people make a lot of design errors that me the implementation network engineer have to fix or work around. It is almost a weekly experience for me to get a design handed to me and it not work as they have it designed. I'm not saying this guy in particular has these problems, but it has been my experience that many of the design only types do have these problems.

darkerz

Jackace wrote: »

I have to agree with some of the other people on this one. Sure this guy might have learned how to talk to business people about networks, but that alone won't make you a good network engineer. Sure the business people like that, but in my experience those people make a lot of design errors that me the implementation network engineer have to fix or work around. It is almost a weekly experience for me to get a design handed to me and it not work as they have it designed. I'm not saying this guy in particular has these problems, but it has been my experience that many of the design only types do have these problems.

After much thought and reflection, I realized that I am a damn good engineer. The guy was having a bad day / ego / lack of humility, who knows, but it was unfair for him to have gone after me. Do I need to work on my business acumen and "Why this?" capabilities, sure. Who doesn't. I don't talk to non-networker's in my current role, so I have room for refinement.

This last week, right before the weekend... A request from their design group came in. One of their guys was ultra gutsy, even wrote out an entire configuration for amending a major BGP IPv4 prefix list, amending a few route maps and putting in some new weight & AS Path modifications. I found dozens of serious mistakes, subnetting errors and in general "wrongs". I had to fix it.

...

It put a smile on my face when I found out who wrote the MOP and configuration (our dear friend from the topic post).

I might have a learning path to being a better "Non-Tech" translator to managers and business groups, but Deployment, Implementation and Operations keep the world spinning.

Fired up and reading Routing TCP/IP Volume I, Second Edition this weekend. CCIE here I come.

I really appreciate everyone's encouragement and feedback, thank you! Ops & Implementation folk unite.

Architect192

Jackace wrote: »

I have to agree with some of the other people on this one. Sure this guy might have learned how to talk to business people about networks, but that alone won't make you a good network engineer. Sure the business people like that, but in my experience those people make a lot of design errors that me the implementation network engineer have to fix or work around. It is almost a weekly experience for me to get a design handed to me and it not work as they have it designed. I'm not saying this guy in particular has these problems, but it has been my experience that many of the design only types do have these problems.

Double edged sword... Most hands-on guys don't have the "big picture" mindset. And a lot of experienced architects are too far from operations to make sure things work as designed. I worked as a sysadmin for years, then moved into architecture/integration, so I still keep my hands in it and make sure that what I design, works

And I do make mistakes, but I get to see them, correct them, and not make them again! Everytime I interview, I tell them that I don't want to be a paper pusher, handing down "designs" to operations and never knowing if it worked or not, or if the ops guys changed stuff around to make it work and never told me. I want to be involved from beginning to end.

-hype

darkerz wrote: »

It put a smile on my face when I found out who wrote the MOP and configuration (our dear friend from the topic post). I might have a learning path to being a better "Non-Tech" translator to managers and business groups, but Deployment, Implementation and Operations keep the world spinning.

Fired up and reading Routing TCP/IP Volume I, Second Edition this weekend. CCIE here I come.

I really appreciate everyone's encouragement and feedback, thank you! Ops & Implementation folk unite.

LoL, serves him right!

Did you rub it in his face? Or at least talk to him about the matter? I would, maybe then he will give you your kudos.

Polynomial

-hype wrote: »

Did you rub it in his face? Or at least talk to him about the matter? I would, maybe then he will give you your kudos.

This is the exact opposite of what you should do. Even if you talk to him you'll come off as passive aggressive.

gadav478

Awesome account, OP. Silence is golden. Take the gems you found valuable in your conversation with this guy and use them to make you better. Make sure you smile as you walk past him in the hallway

darkerz

-hype wrote: »

LoL, serves him right!

Did you rub it in his face? Or at least talk to him about the matter? I would, maybe then he will give you your kudos.

I did my job, that's all there is to it.

No reason I'd be passive or even direct "dick" to the guy. It's hard for me to judge people on their ability to do "A, B and C", I have to trust the universe will work itself out as long as I keep up the pace, be humble and sincere in my abilities.

I'm more interested in breaking my GNS3 labs and getting more project work in the door these days.

RouteMyPacket

darkerz wrote: »

A request from their design group came in. One of their guys was ultra gutsy, even wrote out an entire configuration for amending a major BGP IPv4 prefix list, amending a few route maps and putting in some new weight & AS Path modifications. I found dozens of serious mistakes, subnetting errors and in general "wrongs". I had to fix it.

It put a smile on my face when I found out who wrote the MOP and configuration (our dear friend from the topic post). I might have a learning path to being a better "Non-Tech" translator to managers and business groups, but Deployment, Implementation and Operations keep the world spinning.

Fired up and reading Routing TCP/IP Volume I, Second Edition this weekend. CCIE here I come.

I really appreciate everyone's encouragement and feedback, thank you! Ops & Implementation folk unite.

Wow, hahaha

Awesome!

pamccabe

Great to hear darkerz! I see your posts quite a bit and you are a knowledgeable guy. Guys like me look up to posters like you so we can learn a thing or two. I wouldn't put too much into how someone talked to you on a given day. You don't know what he goes through in life. He might have had a terrible day. Just keep on the path that makes you happy.