I began my career as a software engineer, eventually moving up to architect before going to cybersecurity full-time, going from Senior Analyst to Chief Analyst to Deputy Director, followed by the sorts of executive roles I'm now in. There's a lot that my younger self didn't understand about office politics, and needed to know, so I'll try to help the rest of you be wiser than I once was.
*What office politics is and isn't:*
There are lots of definitions of "office politics". Younger-me thought that it meant a situation where those in power let ego and cliques get in the way of getting things done. While this can happen, it's not what office politics really is. Some of the engineers who have worked for me now once believed that office politics was "all the stuff that doesn't matter, like emails, meetings, conferences, and holiday parties"...I don't think most still believe this, as I try to be a good teacher.
An experienced SWE knows that technical work at any scale requires an infrastructure. If your ticket tracker, revision control system, test suite, and automation are not up to snuff, the code produced in that system is going to have serious problems. As a matter of fact, I've seen projects collapse under their own technical debt because they didn't take good care of that sort of infrastructure, and couldn't see the technical debt accumulating in their code base as a result.
It turns out that any organization, including those producing code, has a bunch of non-technical infrastructure, too: money and systems for managing it, relationships, decision-making systems, people-development systems, communication systems, legal and policy systems, marketing and sales, ethics and culture... if any of these is screwed up or neglected enough, it can derail the life of software engineers just as badly as a revision control system that lies to you, or a test suite that never throws an error. Office politics is a catch-all term for how these non-technical systems are operated and maintained: sometimes well, sometimes poorly.
*How much should office politics matter to a software engineer?*
Junior and mid-career ICs (individual contributors, aka people who don't manage anybody else) can safely ignore a lot of office politics. You'll need to grow into more should you start moving up toward a technical leadership role (e.g. architect, incident response lead, project manager) or a people leadership role (e.g. team lead, manager), but you can start with just these three things early in your SWE career:
1. Become a good communicator. Your commit messages, answers to tickets, documentation, and code comments are all part of the job of coding. If you have the right idea, but can't explain it well enough for your architect or team lead to buy in, that is your failure. Good engineering communication is dense and succinct, clear and precise, absolutely correct in spelling and grammar, and has solid reasoning that takes into account all the facts that matter, but none of the ones that don't. Don't be a catastrophist or a Pollyanna, especially around clients/customers. Not everyone will meet this standard, but if you do--or at least if you constantly work your way closer--you'll be a better programmer than technical skill alone can make you.
2. Build strong relationships. This doesn't mean being the life of the party, and it's not about charisma. It's about showing up (including to the office Christmas party), learning people's names, being cordial and professional (not the person who got drunk at the office Christmas party), being clear and direct (no passive-aggressive behavior), being trustworthy (no lying, no gossip, don't cheat, do more than the minimum), being reliable (keep your word, under-promise and over-deliver, manage your time well), never blame others for your shortcomings, and don't be the workplace grump. Learn what other people are dealing with so you can be a better colleague.
3. Take responsibility for your own growth. It's not your organization's job to build your career, but many junior SWEs expect it. Go to conferences. Read books. Take trainings. Read news relevant to your job and the industry you are in. Share what you learn with your team. Start giving talks and trainings. Build a professional network so that you can learn from others. Find a mentor if you can.
Beyond that, you can focus on learning and improving at the technical and self-management parts of the job.
*A bit about my experience:*
At age 20, I was a junior SWE. I cared about technology quality, not what the customer wanted or my boss believed. I think the leadership at my first SWE job only put up with me because I was cheap and I solved puzzles here and there in elegant ways they hadn't thought of. Despite flaming out of college, I had a chip on my shoulder based on years of FOSS development.
Life intervened. I had to take about 18 months off to be a stay-at-home mom, and then divorced suddenly. To get on my feet financially, I ended up starting my own company and freelancing. It gave me a new appreciation for everything that makes a tech job possible. Eventually, my little company grew, and I started getting more interesting gigs. One was with a pair of investors who wanted to use me to turn around SaaS companies they'd invested in, but which were failing. The investors had a finance background, not a tech one, so in my mid-20s I was their go-to for a cheap last ditch to save these investments by putting the right technologist in the mix.
I learned the hard way that technical problems of a certain magnitude are usually people problems wearing a hat. Bad hiring, personnel turnover, failures of communication and relationship building, lack of delegation, problems making and sticking to decisions, broken or ill-defined company culture, perverse incentives...the list goes on. Getting tech debt under control, fixing bad architecture decisions, and getting code delivered at a decent quality meant sorting out those people factors in the process. Some of the cybersecurity crises were especially interesting to me, so that's where my career went next.
It took the best boss I'd ever had six months to convince me to become a manager. I wanted to stay an engineer forever. However, after watching three incidents where engineering teams suffered due to bad management, I gave in. Office politics here I come...except, it wasn't as bad as I'd imagined. It turns out that if you have enough spine to be honest with people, and enough responsibility to be a bit proactive, and are willing to accept that management is a whole new career you have to learn, it's not that hard to do it well.
My manager introduced me to Manager Tools ( https://manager-tools.com -- no affiliation, just an extremely satisfied user), which was immensely helpful. Their advice is actionable, not pie-in-the-sky, and it doesn't include the kind of BS advice that leaves you feeling like you're trapped in Game of Thrones. I've been to several of their events and built an amazing network. Today, I'm leading one cybersecurity start-up as Managing Director, and I have another project still in stealth.
I've seen the good politics and the bad. Less of the bad politics was due to some sort of evil villain actor than most people imagine. Most is due to learned helplessness, poor decision-making skills, people being set up for failure, or being in the wrong job, or simply being untrained and believing the BS they read on LinkedIN (and yes, sometimes HN). Having the right mentor(s) makes a huge difference in how well you can take advantage of the good and fix, shield against, or leave the bad. I can't write something that will tell you how to deal with every possible situation you could run into. Building relationships with folks further ahead on the road than yourself gives you the opportunity to tap their experience when it's needed, for the situation you are actually in, rather than worrying about vague and sweeping statements about the importance of politics.
As others have noted, that's a pretty broad question. Are you interested in the theoretical or the practical? Do you prefer a scrappy, creative investigation or one within the walls of a big, well-resourced, legitimizing, and bureaucratic organization? How will you serve the needs of others (aka the only way to make money in this world)? What's your current background, professionally and educationally?
Feel free to DM me if you want... I work in cybersecurity at a major university. My role is primarily operational, but I also manage and conduct research. Before that, I was a more independent sort of security geek.
It's really not pretty obvious...says the non-degreed cybersecurity researcher at a major university in the US.
The majority of academia is further behind in cybersecurity than they think they are. Some bright spots are far ahead than they get credit for. A huge amount of impactful research is being done in the private sector or by hobbyists. Whatever the source or the organizational affiliation of the researcher, the best ones have a solid connection to what's really going on out there in the field, rather than living in a safe little researcher bubble disconnected from the real world.
If I hired someone, and found out that they lied during their interview about anything at all, they'd be fired, period. I could not trust someone who lies during an interview to make ethical decisions in the future. Honesty doesn't have to mean full disclosure. You can be honest while keeping some facts to yourself.
Here's a good example:
I was taking some time off for voluntary reason when I became ill. I was
lucky enough to be able to afford treatment and to delay my re-entry to the workforce until I became confident that my health wouldn't be a hindrance.
Just keep it simple and be honest.
I realize that there's a stigma attached to certain types of illnesses or disabilities, and it may seem tempting to make an excuse or cover rather than being honest. However, in addition to the likely inevitability of the deception being discovered, there's a worse possibility:
One young man I know (Calling him Bob, not his name) interviewed with a friend and colleague of mine (calling her Alice), but didn't get the job. I checked in with Alice to find out what happened, thinking that at least I could get Bob some useful feedback. It turns out that Bob had rated well on skills related to the job. However, he'd been so cagey about a six-month work history gap that the interviewing committee thought it likely that he'd worked some job not on his resume and was fired for cause, perhaps for stealing or sexual harassment or "something else big".
Bob was so afraid of the company finding out that he'd been in psych care after a major trauma, that he led them to believe he was a criminal.
OP has no responsibility to share about their illness. In this case they are perfectly within their right to tell some half truth (wanted to spend time with my family, study x subject, burnout etc) and your company might be in some legal hot water if you fired OP in response to finding out they were ill during that time..
Frankly I think it's unethical, and shows a lack of empathy, to punish someone for hiding an illness from an employer.
That's an odd lesson to take away from your anecdote about Bob. What Bob should have done was just told a white lie that wouldn't have raised any red flags or follow up questions, and left it at that.
There will always be a stigma around mental illness, it's human nature, not some social construct, and I would 100% lie to you about something like that and not feel the least bit bad about it.
Your story is really strange and your takeaway is the exact opposite of what it should be.
Alice just jumped to the conclusion that Bob was a criminal? How is that okay? The answer to your story isn't for Bob to reveal potentially embarrassing personal information in a job interview but for Alice not to assume that everyone with a gap in their resume is a criminal.
It's amazing* how many people here are willing to roast me over a third-hand account of my opinions, when I've already offered to answer questions directly.
* Not actually amazing, fairly typical of internet commentary, really.
To save effort on finding the relevant segment of a 17+ minute interview, I have attempted to transcribe a portion. See also https://www.oreilly.com/ideas/susan-sons-on-maintaining-and-... with some portions transcribed (inexactly); add ~20s to the times below to match the podcast timing.
(5:26) [O'Reilly interviewer] Mac Slocum: Related question on this: how can the Internet's infrastructure remain up to date and secure, particularly when it's distributed like this?
(5:33) Susan Sons: So the really terrifying thing about infrastructure software in particular is when you pay your ISP bill, that pays for all the cabling that runs to your home or business. That pays for the people that work at the ISP. That pays for their routing equipment and their power and their billing systems and their marketing and all of these wonderful things. It doesn't pay for the software that makes the Internet work. (5:54) That is maintained almost entirely by volunteers. And those volunteers are aging. [Um.] Most of them are older than my father. And [um,] we're not seeing a new cadre of people stepping up and taking over their projects, (6:10) so what we're seeing is ones and twos of volunteers who are hanging on and either burning out while trying to do this in addition to a full-time job, or are doing it instead of a full-time job, or should be retired, or are retired. [Um.] And it's just not giving the care it needs. (6:27) And in addition to this, these people aren't always up to date on the latest [um] techniques and security concerns of the day. And the next generation isn't coming up. I recently started a mentoring group called the #newguard that takes early and mid-career technologists and we cross-mentor and then we match them up with the old guard who are maintaining and who built this software to try to help solve that problem. But in the meantime there's still not enough funding going in this direction. And there's not enough churning happening. [Um.] And it's a really tough thing because there's a certain amount of what I call "functional arrogance" involved. [Um.] I don't have a certificate of "Susan is good enough to save the Internet" anywhere. I don't know who hands those out.
I found your remarks about succession planning at around the 5:50 mark of the linked video:
[The software that makes the Internet work] is maintained almost entirely by volunteers, and those volunteers are aging. Most of them are older than my father, and we're not seeing a new cadre of people stepping up and taking over their projects, so what we're seeing is ones and twos of volunteers who are hanging on and either burning out while trying to do this in addition to a full-time job, or are doing it instead of a full-time job, or should be retired, or are retired, and it's just not getting the care it needs. And in addition to this, these people aren't always up to date on the latest techniques and security concerns of the day, and the next generation isn't coming up.
In context "should be retired" sounds awfully prescriptive, but I can see how that could mean something like "these volunteers want to retire but feel obligated to continue their maintenance duties".
Then at the 7:00 mark, you say:
It's a really tough thing because there's a certain amount of what I call functional arrogance involved... There's a certain point where you just have to say, "I'm going to decide that I'm in charge of this"...
I dunno. I can see where that's going to rub people the wrong way while at the same time seeing the value in having some moxie. I get the impression, though, that Stenn wasn't too happy with this approach.
2:15 The entire build system depended on one build server located in Harlan Stenn's home. "But Harlan no longer had the root password to this system, couldn't update it, didn't know what scripts were running on it, and no one in in the world could build NTP without this server continuing to function."
3:25 It was death by a thousand cuts. "And I was seeing things that were not yet C99 compliant in 2015. The status of the code was over 16 years out of date in terms of C coding standards which means that you can't use modern tools for static analysis..."
4:30 "And in the mean time, security patches were being circulated secretly and then being leaked, and the leaked patches were being turned into exploits which we were seeing in the wild very quickly, when the security patches weren't being seen in the wild for a long time."
6:00 "...but it doesn't pay for the software that makes the Internet run. That maintained almost entirely by volunteers, and the volunteers are ageing, most of them are older than my father. And we're not seeing new [?] people stepping up..."
In the case of Network Time Foundation, the nonprofit wrapper for NTP classic, the problem was largely mismanagement of funding. NTF funded Harlan Stenn's work on NTP, but funded no other developers. It did, however, fund a fundraiser and two part-time administrative staff. The two administrative staff came to one FTE (full-time-equivalent) total, and I forget how much the fundraiser was working. In any case, the org had funded more FTE in overhead than in technical staff.
By contrast, the temporary rescue team funded a project-manager-slash-information-security-officer, three developers, and a bright intern who did a great deal of documentation work. Granted, these were not all full-time positions, and I was able to lean on my parent organization for administrative support, so while paperwork was minimal I didn't have to fund it directly.
NTPSec's staff has varied over time, but at the time I stepped down to hand the ISO role off to my successor, they had the following funded positions: a project manager, an ISO, two developers, and a sysadmin-slash-developer. (Note: not all of these were full-time positions, and some were funded by third parties rather than by NTPSec directly.)
Open source infrastructure software projects, when well run, do not spend over half their resources on non-development work. It's just not responsible. It's how you lose donor confidence, and how you fail to maintain good software engineering practice even when you have the resources to do better.
This has been a running theme in open source failures in the last few years: "it will be better if we throw more money at it!". Sometimes this is true: there are developers out there simply burning out for lack of resources and splitting their attention between OSS work and making a living. However, often, there is mismanagement at work, or the project doesn't have a good enough talent pool to pull from to use funds effectively when they do get funds. I love when the problems are purely technical, because it's a clean fix and everyone thanks me and I walk away quietly. When the underlying problems are social, they tend to fester, because nobody really wants to be in the hot seat over the disagreements that happened.
That's quite the stretch, to claim that the two part time administrators is anywhere near half the value of a full time software engineer.
If you take average wages, two part time administrative employees would cost you somewhere around $40,000 a year (2 * 12 * 30 * 52, rounded up). One software developer's value is conservatively $120,000 a year (likely more; $80,000 salary, $40,000 payroll taxes & benefits).
By those estimated numbers (I'm not in a position to look up the actual numbers right now, but they're probably available), that's only around 25% for administrative overhead, for a three person team. Not that bad for a foundation. And certainly nowhere near "half their resources" as you claim.
I'm glad that NTPSec appears to be relatively well funded, but knocking on NTF for being less well funded and having administrative work that they don't want to pawn off on an already overworked developer is pretty nasty business.
I highly recommend that you watch my interview with Mac Slocum (video here: https://www.oreilly.com/ideas/the-internet-is-going-to-fall-... ) to find out what I actually said, rather than listen to a reporter saying what someone else said I said. I was misquoted.
This is pretty much what happened. We spent a few months working with Mr. Stenn, and ultimately he did not agree to pursue strategies to correct the underlying problems that caused NTP's security and stability issues. Simply patching known vulns and moving on would have been a temporary solution: more vulns were lurking. NTPSec was born to give the code base another chance, to evolve with a different strategy. In the end, I tend to feel that this is a strength of OSS: different groups are free to do things different ways, and if people are paying attention, software quality should win out.
Since Eric and the rest of my team started working on the NTP code base in early 2015, we've eliminated over 50% of its vulnerabilities before they were disclosed simply by applying good software engineering practice where it hadn't been. In the year before my O'Reilly presentation, it was more like 80 or 85 percent. Everything we hadn't eliminated by disclosure or discovery time was fixed promptly.
There are other NTP protocol implementations besides NTP classic or NTPSec that are worth considering for some users. However, we felt that refactoring the reference implementation was necessary due to its use in many less-mainstream, but often highly-critical (in a life-critical or economically-critical or critical-to-scientific-research sense) applications. The non-NTP-related implementations don't always do what high speed trading houses need, or scientific installations built on aging but extremely precise equipment need, or controls system interfaces need, and on and on and on. We just didn't have a drop-in replacement available for all of the things that weren't web servers, workstations, and other commodity applications.
The "rift" article is now subscriber-only, so I can't respond there to its many inaccuracies (I was passed a PDF by someone who cached it, this is the only way I was able to read it). I was never contacted about it by the author, and I don't feel it was a fair treatment of the subject. That's okay. I learned a long time ago that fixing a mess will make some people thank you and some people angry with you. It wouldn't have become a mess by the time I found it if there weren't a cost to fixing it. People who fear controversy will have a hard time making a difference in the world.
I'm at work, but I'll do my best to answer any questions fired at me today on this thread. If there's something you want to know, ask!
NTPsec advocates keep saying "eliminated 50% of vulnerabilities <<<before they were disclosed>>>", as if there were another meaningful way to eliminate vulnerabilities from a codebase.
Can you provide a breakdown of the vulnerabilities NTPsec HAS and HAS NOT been vulnerable to, along with their severity (low: degrades time service, medium: provides a practical vector for corrupting integrity of time service, high: compromises integrity of the server itself) and whether they're exposed (a) in the default configuration, (b) in a configuration run widely on the Internet, or (c) in no configuration actually known to the project maintainers?
You clearly have the list somewhere, because everyone involved in the project has this statistic ready to quote.
If you don't have the severity and exposure breakdowns, that's OK. Post the list anyways. Maybe it'll be obvious what the severity and exposure is.
This business of counting vulnerabilities and claiming victories has been a problem for software security for two decades now. Ops people don't care about the vulnerability count, if the vulnerabilities left exposed in the codebase are the ones that get their servers popped.
I'm sorry if I wasn't clear, I meant "before they were disclosed to NTP classic or NTPSec". In other words, by simply improving on the software engineering practice, we eliminated classes of vulnerabilities without having to track them down individually. This is pretty common with ailing code bases, though often overlooked. I'm at work right now, so I don't have a comprehensive list handy. Going through NTP classic vulns and seeing how many never impacted NTPsec would recreate such a list.
The severity varies (many weren't that big, some were)... the point of claiming the victory is to demonstrate that I'm not just having a fuss about testing code, using static analysis tools, using an accessible code repository, refactoring for lower attack surface and better separation of concerns because they are beautiful in abstract. I like results. NTPSec, and before it the temporary "rescue" team, have been slowly chipping away at the big picture mess, making the code safer and more maintainable, because it's likely to remain in service for another decade or two.
Every time 14 vulns are disclosed and we are already immune to half of them, we get to put twice the effort on the half we do need to deal with, if even we need that much. We aren't just firefighting, NTPSec can develop proactively. That means something for our users.
lots of personnel overlap here...the main difference being pre- and post- fork and where the funding came from, probably not interesting to most people.
No, I understood your meaning. I'm saying: that's what every code refactoring does. I'm saying that since you can't claim credit for eliminating vulnerabilities that are already disclosed, the emphasis you place on precluding vulnerabilities is strange.
Can you provide that list of vulnerabilities now? You're obviously keeping track of them, that being part of the premise of the project. I know you don't have them broken down, but we can help with that.
How about this: before I put the effort in to generating the list myself, can you at least promise to confirm that I have the complete an accurate list once I do, and to fill in any gaps?
As a side note, I'd like to add a point that I highlighted in my O'Reilly Security Conference talk but previously forgot to mention here...
One of the coolest after-effects of this whole thing was that, after the fork, when NTP classic began feeling the pressure of competition, their speed in addressing security vulnerabilities increased incredibly. While I was sorry that it didn't happen on its own, I was pleased and impressed to discover what Mr. Stenn was capable of once his competitive hackles were raised.
Many people experience hurt feelings during a fork, and a fork represents a frustrating duplication of effort that I'd usually rather avoid. However, forking is a central tenet of the open source ethos for a reason. Competition can do incredible things. <3
If a primary purpose of forking ntpd was to give the original project a kick in the ass about fixing vulnerabilities, could it not be argued that your project has now served its purpose, and dollars could be better spent on building from the success of "NTP Classic" --- which, after all, is the version of NTP most likely to be deployed?
I would agree with you if NTP classic had fixed the total of its social and technological problems. Unfortunately, this is not the case. "Patching faster" is one small victory.
> In the podcast, Sons depicted NTP as a faltering project run by out-of-touch developers. According to Sons, the build system was on one server whose root password had been lost.
> Stenn denied many of Sons's statements outright. For example, asked about Sons's story about losing the root password, he dismissed it as "a complete fabrication."
Unless either you or Stenn is outright lying (neither of which seems likely, on priors), this seems like a strange misunderstanding to crop up. Do you know what's going on with this?
I know what his side of the story is on that specific password. I don't think it's adequate, but... I also don't know that it's helpful to keep arguing this two years later. Casual contributors couldn't build the latest dev version of NTP due to repository access and build system problems, and the lead (effectively only active, at that point) maintainer couldn't or wouldn't fix the situation.
While the password problem made a good rhetorical flourish--it illustrated how the scaffolding supporting NTP development had been allowed to rot--the fact is that the server was in Mr. Stenn's control and he could have rebooted it to rescue media at any time, fixing the problem in a few minutes. Yet, the server was never properly brought up to good maintenance practice. I suspect that the majority of people reading this know how to reset a root password, so the password doesn't really matter that much in the grand scheme. The server was just another thing being neglected.
As I described in my O'Reilly talk, technical problems of this magnitude stem from social problems. The project didn't have a culture of sound engineering practice. I did what I could to work with Mr. Stenn to offer support and resources to bring that practice to his project. I didn't want to lose the years of institutional knowledge he'd acquired working on NTP. That's costly to replace. However, I wasn't going to forgo sound engineering practice to keep him on board: over time, smart people could learn the ins and outs of even the most tangled code base. The costs of bad engineering practice just keep coming, and I cannot force people to do the right thing, only lay out the costs and benefits then see what they choose.
That, and throw a little storytelling prowess at the problem now and again, in the hope of motivating people.
From the article (and the end result) it seems the "strategies" you talk about that were rejected include a total rewrite and an abandonment of features and platform support.
You can eliminate vulns and improve stability a lot of ways. Total rewrite is definitely not the best way. Even if you're the best programmer in the world, rewrites often run into old bugs as well as new ones, and require a lot of testing and a lot of repeated effort.
And I can't speak for the other infosec nerds, but for me, name-dropping ESR does the opposite of inspiring confidence in a security-focused project. I wouldn't trust him to secure my shoelaces.
If the old codebase was really bad, perhaps eventual rewrite would have been useful. But what would help existing users more is fixing the existing product so they can upgrade in place and be more secure, and not forcing them to go through a whole product migration cycle just for better security.
The specific measures that were refused, from the rescue plan that Mr. Stenn rejected and my notes from that meeting:
* Moving NTP development from a private Bitkeeper repo which requires all people accessing it (10 at most without private license purchase, given that Network Time Foundation has only 10 licenses) to agree to a restrictive license that may interfere with their other development work, to a public git repository which is accessible by the public as a whole. Stenn felt that tarball releases were sufficient, and did not agree that giving the public an opportunity to see code prior to release was important.
* Releasing patches to NTP vulnerabilities to everyone at the same time. NTP had a practice (for which Mr. Stenn never explained to me the reason) of releasing vulnerability patches to a closed group months or more ahead of the public release. These patches were typically leaked fairly rapidly and turned into exploits which were then used against NTP deployments in the wild.
There were other disagreements, but these were the big two technical disagreements upon which Stenn walked away. They were not points upon which I was willing to compromise, especially given that neither I nor other people in a position to help NTP could possibly have signed Bitkeeper licenses while maintaining our primary employment. This was a massive roadblock for increasing contribution to NTP, from us or anyone else.
If you look at the slides from my O'Reilly presentation here: http://slides.com/hedgemage/savingtime you will see that even when the rescue proceeded without Stenn, we did not do a major refactor! Slide #20 outlines the original rescue, which had 4 points:
* migration to git
* replacing the build system (when Stenn had been on board, we'd intended to repair the build system in-place, but without the mystery scripts residing on his build box, we decided that a from-scratch replacement was more reliable and efficient than to reverse-engineer and repair)
* updating documentation so that new developers could be onboarded
* fixing what vulns we could given limited resources
That is it. Refactors came later when, after this "rescue" work, Mr. Stenn declined to use these work products and the NTPSec fork was born.
We did make every effort to avoid a fork, but in the end, I could only offer help, I could not force anyone to take it. Forking is, in the end, the OSS community's last protection from failing projects.
So why not maintain a patchset to be applied to the original and maintain it on your own repo? There's nothing you can do if someone is holding security patches from you, but you could certainly release your own to the public.
Honestly, both of those sound like very common issues which do not result in whole new product forks. Large projects maintain patchset and private security lists all the time. To me the ends don't justify the divergence.
It depends a lot more on her strengths and background than anything else.
If she's the right kind of thinker, parlaying a polisci background into infosec isn't that hard -- there's a LOT of activity around the infosec policy specialties right now. I'm a hacker by trade, but one of the two coworkers I work most closely with is an attourney. Having the "dynamic duo" of technologically-literate lawyer and legally-literate technologist on hand can be extremely useful.
OTOH, if she actually wants to go into technology rather than policy-around-technology, the fast track is to build things, work with experienced teams, and read a lot. I don't have or particularly feel I need a degree. The only place that not having one has ever caused me problems is academia, and even there it is just a political problem.
I've spent my life building, learning, and working with bright people. Some strategy highlights:
* Don't confine yourself to teams of fellow newbies. It may feel safer for your ego, but you won't learn as fast.
* Be willing to do scut work -- i.e. boring, repetitive tasks -- to endear yourself to projects you want to learn on. Showing you will do work is the best way to demonstrate to others that it's worth it to them to teach you. Show up and start cleaning up documentation. Give support on IRC. Do issue queue triage. Fix small bugs, then work your way up.
* Read. Constantly. Ask hackers you respect what they are reading.
* Try many things and figure out what your strengths are, then build on those strengths, rather than just trying for what others say is easy.
* If you are serious about programming, don't just learn one programming language. There's a skill ceiling that (as far as I can tell) cannot be broken until one has worked in several programming languages built on different paradigms.
* If you are serious about infosec, don't just spend your time around people who've learned to go through checklists or use tools by rote. Find people building and analyzing from first principles, and get in with them.
* Find a project that needs a volunteer to do the things you want to ultimately do for pay, then volunteer. Do an amazing job. You'll learn a lot (often scrambling to learn on the job), and you'll end up with some work to show up and some good references.
* Spend time networking (the social kind) and use it. Nobody knows everything. But, if you know enough people, you probably know how to find out just about anything. Be helpful to others and you'll always have people ready to help you when you need it.
* If your urge to get into the industry really outweighs other concerns, consider low-barrier jobs like NOC Monkey (sit at a datacenter during off-hours, stare at screens, call admins if there's an emergency) or Hell Desk (aka Help Desk or Tech Support) just to get into companies and see how they work, then work your way up or job hop. These jobs don't usually pay much, but they do give a lot of insight and usually aren't demanding enough that you can't also work the other strategies while you have them.
*What office politics is and isn't:*
There are lots of definitions of "office politics". Younger-me thought that it meant a situation where those in power let ego and cliques get in the way of getting things done. While this can happen, it's not what office politics really is. Some of the engineers who have worked for me now once believed that office politics was "all the stuff that doesn't matter, like emails, meetings, conferences, and holiday parties"...I don't think most still believe this, as I try to be a good teacher.
An experienced SWE knows that technical work at any scale requires an infrastructure. If your ticket tracker, revision control system, test suite, and automation are not up to snuff, the code produced in that system is going to have serious problems. As a matter of fact, I've seen projects collapse under their own technical debt because they didn't take good care of that sort of infrastructure, and couldn't see the technical debt accumulating in their code base as a result.
It turns out that any organization, including those producing code, has a bunch of non-technical infrastructure, too: money and systems for managing it, relationships, decision-making systems, people-development systems, communication systems, legal and policy systems, marketing and sales, ethics and culture... if any of these is screwed up or neglected enough, it can derail the life of software engineers just as badly as a revision control system that lies to you, or a test suite that never throws an error. Office politics is a catch-all term for how these non-technical systems are operated and maintained: sometimes well, sometimes poorly.
*How much should office politics matter to a software engineer?*
Junior and mid-career ICs (individual contributors, aka people who don't manage anybody else) can safely ignore a lot of office politics. You'll need to grow into more should you start moving up toward a technical leadership role (e.g. architect, incident response lead, project manager) or a people leadership role (e.g. team lead, manager), but you can start with just these three things early in your SWE career:
1. Become a good communicator. Your commit messages, answers to tickets, documentation, and code comments are all part of the job of coding. If you have the right idea, but can't explain it well enough for your architect or team lead to buy in, that is your failure. Good engineering communication is dense and succinct, clear and precise, absolutely correct in spelling and grammar, and has solid reasoning that takes into account all the facts that matter, but none of the ones that don't. Don't be a catastrophist or a Pollyanna, especially around clients/customers. Not everyone will meet this standard, but if you do--or at least if you constantly work your way closer--you'll be a better programmer than technical skill alone can make you.
2. Build strong relationships. This doesn't mean being the life of the party, and it's not about charisma. It's about showing up (including to the office Christmas party), learning people's names, being cordial and professional (not the person who got drunk at the office Christmas party), being clear and direct (no passive-aggressive behavior), being trustworthy (no lying, no gossip, don't cheat, do more than the minimum), being reliable (keep your word, under-promise and over-deliver, manage your time well), never blame others for your shortcomings, and don't be the workplace grump. Learn what other people are dealing with so you can be a better colleague.
3. Take responsibility for your own growth. It's not your organization's job to build your career, but many junior SWEs expect it. Go to conferences. Read books. Take trainings. Read news relevant to your job and the industry you are in. Share what you learn with your team. Start giving talks and trainings. Build a professional network so that you can learn from others. Find a mentor if you can.
Beyond that, you can focus on learning and improving at the technical and self-management parts of the job.
*A bit about my experience:*
At age 20, I was a junior SWE. I cared about technology quality, not what the customer wanted or my boss believed. I think the leadership at my first SWE job only put up with me because I was cheap and I solved puzzles here and there in elegant ways they hadn't thought of. Despite flaming out of college, I had a chip on my shoulder based on years of FOSS development.
Life intervened. I had to take about 18 months off to be a stay-at-home mom, and then divorced suddenly. To get on my feet financially, I ended up starting my own company and freelancing. It gave me a new appreciation for everything that makes a tech job possible. Eventually, my little company grew, and I started getting more interesting gigs. One was with a pair of investors who wanted to use me to turn around SaaS companies they'd invested in, but which were failing. The investors had a finance background, not a tech one, so in my mid-20s I was their go-to for a cheap last ditch to save these investments by putting the right technologist in the mix.
I learned the hard way that technical problems of a certain magnitude are usually people problems wearing a hat. Bad hiring, personnel turnover, failures of communication and relationship building, lack of delegation, problems making and sticking to decisions, broken or ill-defined company culture, perverse incentives...the list goes on. Getting tech debt under control, fixing bad architecture decisions, and getting code delivered at a decent quality meant sorting out those people factors in the process. Some of the cybersecurity crises were especially interesting to me, so that's where my career went next.
It took the best boss I'd ever had six months to convince me to become a manager. I wanted to stay an engineer forever. However, after watching three incidents where engineering teams suffered due to bad management, I gave in. Office politics here I come...except, it wasn't as bad as I'd imagined. It turns out that if you have enough spine to be honest with people, and enough responsibility to be a bit proactive, and are willing to accept that management is a whole new career you have to learn, it's not that hard to do it well.
My manager introduced me to Manager Tools ( https://manager-tools.com -- no affiliation, just an extremely satisfied user), which was immensely helpful. Their advice is actionable, not pie-in-the-sky, and it doesn't include the kind of BS advice that leaves you feeling like you're trapped in Game of Thrones. I've been to several of their events and built an amazing network. Today, I'm leading one cybersecurity start-up as Managing Director, and I have another project still in stealth.
I've seen the good politics and the bad. Less of the bad politics was due to some sort of evil villain actor than most people imagine. Most is due to learned helplessness, poor decision-making skills, people being set up for failure, or being in the wrong job, or simply being untrained and believing the BS they read on LinkedIN (and yes, sometimes HN). Having the right mentor(s) makes a huge difference in how well you can take advantage of the good and fix, shield against, or leave the bad. I can't write something that will tell you how to deal with every possible situation you could run into. Building relationships with folks further ahead on the road than yourself gives you the opportunity to tap their experience when it's needed, for the situation you are actually in, rather than worrying about vague and sweeping statements about the importance of politics.