Hiring managers and companies choose algorithms and hiring fads because they don't know how to be really certain of who to hire, so they'll settle for either assuming someone else's expertise will save them, or for some rubric that "everyone is doing" so it "can't be that bad".

When I first became a hiring manager, I was working for a public university. Our salaries were limited, being staff rather than faculty and being public servants, to between 1/3 and 1/2 the going salary for equivalent cybersecurity professionals in the private sector. I did not have the option to hire the people everyone else was trying to hire. I also faced one of the key risks of working in a public institution: once you keep someone past their probationary period, it is very, very hard to fire them. So, it's important not to get it wrong. I learned some things that I have carried forward into every hiring manager or senior leadership role since:

1. I base hiring practices on Manager Tools behavioral interviewing systems (https://manager-tools.com). No affiliation, they've just made my work life better.

2. I became really good at understanding what my team or organization really needs. Most hirers focus way too much on "years of experience" and specific technologies than is usually wise. As my favorite former supervisor said, "I can teach a smart person cybersecurity, but I can't teach a dumb [or unmotivated] cybersecurity person to be smart."

3. I became really good at developing people, and ensuring that the managers under me were as well. We couldn't lay someone off just because their technical specialty became irrelevant, so we couldn't afford to hire people who weren't lifelong learners, or to fail as coaches to ensure that learning was always taking place.

4. I cast as wide a net as my HR and regulatory overlords would let me (and now, as a business leader, I cast a huge net). I look for things that aren't just useful at the moment, but are useful long term, in my candidates. I don't care about pedigree.

I end up paying less for good employees due to simple supply and demand: I often go for the diamonds in the rough that don't have 10 competing offers.

I end up having really good employees who generally stay with me long term, because I apply long-term thinking in hiring, and structure my teams around constant learning and development.

I dodge a LOT of bullets... people who have just the right pedigree to look like great hires worth a lot of money, but who'll disappoint me until the day they leave.

When it's a tight labor market -- too few candidates for roles I care about -- I'm tapping a hiring market that other managers aren't aware enough of, and still finding talent while they have roles that sit open for months.

*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.

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.

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.

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.

Honesty really is the only good policy.

Lucas starts high school next year, and his middle school (what some would call "junior high") is trying very hard to convince me and him that autistic people can't succeed in startups. The lengths they are going to to push him away from the local entrepreneurship high school just...stagger me.

I'm fighting them. He's a bright kid, and his social difficulties are nearly invisible when attending or teaching at a tech con, or in other environments less adversarial than his current school situation. However, I'm worried about his morale because so many adults in his life seem to truly believe that I'm delusional and autistic people shouldn't reach for this sort of life. It makes me sad.

I have been around startups a long time, and met many cool autistic adults. If you are one or know one, please drop a comment that I can show my son about something cool you or they have done.

Or, check out his beekeeping blog at https://bloomingtonbees.com -- it's not currently accepting comments, but he's been known to check his traffic. ;) Lucas is currently working on a beekeeping start-up, with an eye to other agricultural projects in the future.

Comments URL: https://news.ycombinator.com/item?id=15881514

Points: 29

# Comments: 9

https://www.oreilly.com/ideas/the-internet-is-going-to-fall-...

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.

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

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.

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.

* 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.

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.

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!

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.

"Even if they lacked computers, they were taking apart alarm clocks, repairing pencil sharpeners or tinkering with ham radios. Some of them built pumpkin launchers or LEGO trains."

There are many early maker/hacker experiences that don't require access to or interest in computers. The point was that, at some point early on, every hacker (maybe there's an outlier or three, but I'd be shocked if there were twenty) had some experience digging in and building or fixing or changing something.

For me, it started a long time before my exposure to computers. I grew up in a rural area. As early as toddlerhood, I was learning to cook, sew, make candles, weave on a loom, etc. I was making as early as I could hold things and be relied on to keep them out of my mouth. It never occurred to me to throw something away without trying to fix it first, because if something broke, my parents would fix it, and I'd watch or help.

It's not about computers and youth, it's about making/fixing/tinkering and youth.

I got a certain amount of crap from others for "letting" him be so into a girl thing, and I remember getting crap as a kid because most of the figures I looked up to are men. Is it hypocritical of me to be both frustrated by the lack of stuff about girl techies and irritated that our society pushes kids to pick such things only from same-gendered examples?