Yeah, in my case, the decision to hire me had been made, but HR would of course onboard me. I got kind of blindsided as the person who asked me wasn't the person who would be making the decision, she was basically a proxy. I asked what the range was and I got some generic "it depends".... I checked most of the boxes for skills but I don't have a degree and for some reason that's off-putting to large companies. Anyways yeah it didn't feel right to be pushy so early
- Posts
- 5
- Comments
- 354
- Joined
- 3 yr. ago
- Posts
- 5
- Comments
- 354
- Joined
- 3 yr. ago
https://www.tiktok.com/t/ZT86J7mpN/
That was basically how the meeting went lol
https://www.tiktok.com/t/ZT86J7mpN/ This is basically a shot for shot remake of how the meeting went down
I appreciate the advice. I'm certainly happy with the raise, just trying to think ahead
I've heard from some friends/family that are trying to break into entry level cybersecurity or programming roles and it's extremely difficult right now, why do you think there seems to be such a high demand for skilled workers but seemingly no demand for entry level?
lmao I was thinking the same. Like damn I gotta start working some on some defense contractor stuff
That's great, can you elaborate what you mean by ops>devops? Do you support infrastructure or applications? I know devops is kind of a catch-all term now for automation, did you work on understanding cloud deployments from the POV of the servers/application or from infra?
I only ask because some of what I do is considered "devops" in the sense that I'm working on network automation, but a lot of times when I hear people discuss devops they're talking about supporting applications
I think you're right. Despite my bandwagon fandom, I Believe Go is more appropriate for my needs. I think a compiled language with more intuitive parallelism is what I need
Thank you, great response. Based on your opinion and another, I believe I will focus on learning Go. I mostly need the benefits of compiled languages in order to easily distribute, as well as easier parallelism, as I've always found that to be a pain in the ass with Python. Not sure if Threading, Concurrency, or Asyncio are the "best" way to handle threading of non CPU intensive tasks, such as sending a request and waiting for a response. But I know that it seems since Python has taken so long to attempt to allow easier bypassing of the GIL, you get a lot of decent ways of doing something, but no great ways.
yes, I've seen how mangled python code can be, some of the code that our automation team uses barely makes use of functions or classes, which has made working on other people's python code a nightmare. There's one application that is thousands of lines long that I'm pretty sure I could condense into a few hundred lines.
Perhaps that's a drawback of people who use python, they are not typically focused on the scalability of their code until it is actually used in prod. I believe for this reason, I would prefer a language that is compiled.
Last question, is using Rust on Windows as difficult as it seems at face value? It looked like to me that for using rust, it's preferable to use linux or mac, as they don't require you to install a compiler. For some reason, my org requires me to submit an exception for being able to install rust on my work computer. Is there anything that is inherently risky about using Rust, or is it because once the code is compiled, it cannot be reverse engineered?
wow, great response. thank you. I'll give it a shot!
To be fair, most of the work that you have to do in a NOC is total bullshit. About 30% of the time you will be working on technical issues, and for most other people in the NOC, that would mean escalating the technical issues to me. Unfortunately, I had to earn the stripes, which means I had to work harder than everyone else, which meant doing their work as well as handling all escalations. Eventually, I was promoted to a supervisor for my efforts, but I did not want to be in a managerial role.
The real bulk of NOC work that is tiresome is the amount of alarms that are unnecessary. Managing SNMP is a nightmare, and configuring it properly involves a deep level of engineering knowledge. You can either tune the alarm board to only show certain alarms(which means parsing through many alarms to find out what is necessary and what isn't), or you make sure that devices that are onboarded are configured locally for what SNMP traps they will alert for. Typically, the devices' SNMP settings are not configured, so all alarms get sent to the SNMP server, and the SNMP server was never tuned to know which alarms it should show or it shouldn't, so there are alarms which don't really "mean anything" and alarms that "could potentially mean something if it's correlated with this other alarm," but most of the work is sifting through so much shit, to then have to troubleshoot a network issue for a network that was never documented in the first place.
I know I am just a random nobody to you, but I'm not satisfied with this response. If you have exhausted all options, then you need to be working on updating your resume. Your boss might not have enough juice to push this through for you, and in that case, it's probably better that you find a new job. I don't think you've exhausted all options, I think you came face to face with the reality of the corporate workforce, the reality is that most people are trying to get by with "good enough." They are afraid of the implications of you outworking them and making them look worthless, or you automating something so much that it cuts the departmental budget. If what you're saying is true, and you can reduce hundreds of man hours, then you should fight for your ideas. Know that fighting for your ideas doesn't mean that you will be praised from day one. People will poke and prod, criticize, kick the tires, make excuses, etc. Stand by your work and always come back to the table.
"Okay, I heard your proposal on how to validate data integrity in the event that we become a multi-vendor environment. I understand that parsing/wrangling data can be challenging. However, in the event that our environment adopts XYZ infrastructure, I am using tried and tested industry standard modeled languages. All major vendors support this language model, so it would not require a complete re-engineering.
life is too short to work for shitty bosses man. But don't spend time feeling sorry for yourself.
Look, I can't advise you to do one thing or another, but I'll give you some career advice that has worked well for me: don't ask permission. Most of the time, the documentation is out there on how to get what you want and you can do it yourself. I won't have my work be wasted by someone else's laziness. And if your direct report doesn't like the idea, tell him you want to discuss it with his boss. Make your case to someone who cares. You have every right to make use of whatever tools will help you do a better job.
What does making your case look like? It looks like making PowerPoint presentations, detailing a cost(man hours, oversight responsibilities, etc), detailing desired results, showing what impact this will have on the team, showing how long it will take to train your average joe on using these scripts, showing how much time can be saved.
Your boss might be chilling because he's waiting out the clock on his career. You're not. Stand by your ideas, people will stand by you. But you will have to fight for your ideas, and you need to be comfortable doing that. I'm not saying it's not hard, it is soul crushing to get your ideas shot down. But you can push through.
Sounds like something you could fix with a repository. Teach your coworkers how to use git
I work in networking, a job that traditionally has been managed by a terminal and vendor-specific syntax. I used to hate the thought of automation when I was younger, why would something as important as networking be automated? I've made my career on being the clutch guy, troubleshooting complex problems, I love the art of understanding every cog in the machine and being able to visualize it. Then I started learning Python, and learning it was extremely difficult for me. It felt like an eternity between the time I poured myself into learning Python until the time I could actually make things people would want to use.
I was a supervisor working in a NOC. A NOC that had many beaurocratic requirements which got in the way of break/fix operational support, such as having to manually write an email to every customer that had an alarm, and calling every point of contact for that customer, as well as notifying the field techs of outages in their areas, and managing real operational issues. So many times I had to let real work slip through my hands because there were so many calls, so many cases, so many things to do.
Like most NOCs, we viewed alarms from SNMP. When something failed to ping, it would generate a loss of comms alarm. I had this idea to automatically notify the field tech for the specified area when a customer site was downed for more than 30 minutes, and that was a very complex thing to do, it required that I clean a lot of data... I spent days converting things like date strings into proper formatting. Once I presented it, I was told that we couldn't do this, because some political agreement made it to where the NOC was required to provide "positive contact" to other groups. I wrote it, tested it as proof of concept, specd out costs(MRC for the API I was using to send text messages was extremely cheap, it would cost the company about 6 dollars per month). Just like that, it was dead.
My director then wanted me to do something similar for our phone systems. Since our queue depended on user agent availability(your presence status), my boss wanted me to write a program to notify him if someone was unavailable for too long and the reason why. Yes, he wanted to know if someone took more than a few minutes to take a shit or get coffee.
That's when I learned, boomers only care about micro management, not efficiency.
I recommend getting very familiar with pythons help(), dir() and type() functions. The help function almost always includes examples for the methods you're trying to use, tells you what arguments it expects, and what arguments are passed by default. The type function can help you understand the inheritance of OOP and what type of object you're looking at, and dir on that object will tell you what attributes/methods are defined for your object type.
Other than that, find some good books. I'm a big fan of Michael Driscoll's Python 101 and 201 books.
I can understand parents. My mom was an office admin before computers and she could type 130+ wpm on a typewriter, but she struggles with things like this. Bless her, I'm happy to help her whenever she needs. My dad was a DOS beast in his day but he can't help himself from adding sketchy browser extensions.
Now, when I run into peer "engineers" that use computers like this.... That I cannot forgive
This meme is kind of wrong though, because it's mixing the OSI model with the TCP/IP model, which are different representations of the same thing, but in either model the "link layer", ie layer 2 switching would never hand over to the "internet" layer without going through network first. So if you're confused, it's because it's wrong.
Application, transport, session, transport, network, data, physical (OSI) Application, transport, internet, network (TCP/IP)
You can talk about what you've previously worked on that excited you, what kind of role or technologies you believe you'd excel in, and how you feel you're ready to transition into a role with more responsibilities. You can tell the truth without speaking negatively about your employer. Even the worst job is something to be grateful for, you got experience and were allowed to (for a time) grow into your responsibilities. The need to complain comes from a desire to "get even" so it always looks very negative.
Also, four years is a long time to spend at a company that isn't helping you meet your goals. Part of maturing professionally is knowing how to ask for more responsibilities, how to make sure you're credited/rewarded as well as communicating properly with your leadership so they can help you meet your goals.
If you get some "down the road" platitude, then start thinking about other options. If you've been excelling in your duties for more than a year and you're no longer being challenged, that's about when it's time to move on.
These days, you should probably be either getting promoted or changing jobs every 2 years at most, 1 to 1.5 years depending on how ambitious you are and how strongly you can demonstrate your skills.
Good luck