Live data from Hacker News

I'm not burned out, I'm pissed off

myname.website

291–300 of 335 posts

Re: I'm not burned out, I'm pissed off

#291

Earlier quoted context omitted.

> Furthermore your average engineer wouldn't eat a ham sandwich handed to them on the street by a stranger We would however eat one provided by a café that our colleagues recommended.

That's true, and a good point, but a big part of that trust comes from the knowledge that no one can run a café without some kind of oversight and inspection on food safety. I probably wouldn't eat a sandwich from a bootleg café.

I would if the alternative was to grow all my own food.

Re: I'm not burned out, I'm pissed off

#292
post #287
post #230

Earlier quoted context omitted.

Not really security, but regarding software in general, Mud is one of the reasons I gravitated torwards pure FP languages. It doesn't solve everything, but the added guarantees help shift some of the cognitive burden away from having to dig into every method to have to see what's going on, and I can spend that mental budget elsewhere.

This reminds me that "but think of the children" mantra. From my observation programmers often tend to justify / promote their languages/tools/etc under pretense of solving security problems.

"Not really security"

Re: I'm not burned out, I'm pissed off

#293
post #289

1) Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE. This is how to not lose your mind when constantly addressing sec issues that others (devs) are entirely responsible for fixing. 2) Department of No doesn't have to be a thing, it just takes some emotional intelligence and pragmatism. 'Always saying no' is as much the fault of the sec eng as it is the system. If you hav…

I've worked in a shop where InfoSec tried to be the Department of Yes. They were very effective at that - they basically never said "No" to anything. The downside was that they weren't actually able to say "No" to the things that they really needed to be able to change. A lack of accountability for decisions meant that people could ignore InfoSec consequence-free. All told, I've learned that security needs to have th…

That's my fault for not clarifying, good point.

Not being Dept No != Being Dept Yes.

It's really not about fluffing them up with admiration (they'll see through that soon enough). It's more about figuring out what the overarching mission of the enterprise is, that in turn dev, ops, sales, hr/accounting, biz dev, and sec all have to work towards (and largely want to, under the frame of doing a good job, and assuming it's not a toxic, failing workplace), and explaining for security under that premise. This gets you a (1) way to couch sec in the 'doing a good job' language, and (2) gives you firepower with mgmt if you're told to fuck off by XYZ dev, as ultimately: business mission wins. So make your sec = business mission.

Avoiding 'No' is about approaching how you sell, implement and get buy-in for lasting behavior/process change. It takes a tremendous amount of work that goes beyond a hacker news comment box, but leadership + organizational awareness are pretty key in that regard.

Re: I'm not burned out, I'm pissed off

#294

1) Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE. This is how to not lose your mind when constantly addressing sec issues that others (devs) are entirely responsible for fixing. 2) Department of No doesn't have to be a thing, it just takes some emotional intelligence and pragmatism. 'Always saying no' is as much the fault of the sec eng as it is the system. If you hav…

I agree with everything you said. To expand on point 3, when you are pitching a security change, know your audience. Most people hear security change and they think another inconvenient pain in the ass that I'm going to have to deal with. That changes if you can show them benefits to people or to the business that are not security related. For example, traditional approach: Boss: You are advocating spending a lot of…

Yeah nailing it. If a sec eng can master the departmental wants of ops/dev/sales/etc., and figure out how (or just a way, even a vague one) how security enables those wants, and then mix in that MBA speak, the job is so much easier.

Re: I'm not burned out, I'm pissed off

#295

1) Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE. This is how to not lose your mind when constantly addressing sec issues that others (devs) are entirely responsible for fixing. 2) Department of No doesn't have to be a thing, it just takes some emotional intelligence and pragmatism. 'Always saying no' is as much the fault of the sec eng as it is the system. If you hav…

>Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE I think this depends on what kind of infosec work you plan to be doing. I have been a security engineer for the past 4ish years, and while I do have some programming/scripting skills it certainly isn't at the level of a SWE. Most of the projects I work on I end up doing pentesting, risk assessments, remediation for compli…

There's obviously a lot of mileage left still to be 'good at a scripting language' but not a SWE. Frankly I'm not there yet but getting there.

I see getting spun up to SWE-levels of programming as a mix of a intelligently defensive career move as shift-left becomes more of a thing in sec and SDN is "replacing" traditional networking, it gives you a ton of bona fides with devs as you can code your own solution or at least work 1-1 with a dev as a lot of problems originate in their area ("I'm asking you to do this work, but I'll do it with you all the way" counts for a lot), and then lastly ensures you can't get wool pulled over your eyes by devs/etc.

Sec and Ops have always had a pretty common language, and for a really good reason. As everything gets so code-heavy (see: SREs in Ops land), seems like Sec and Dev need that meshing.

Re: I'm not burned out, I'm pissed off

#296

1) Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE. This is how to not lose your mind when constantly addressing sec issues that others (devs) are entirely responsible for fixing. 2) Department of No doesn't have to be a thing, it just takes some emotional intelligence and pragmatism. 'Always saying no' is as much the fault of the sec eng as it is the system. If you hav…

3) makes me believe even deeper that most work life is about satisfying other people. You feel motivated because you feel capable of making X other persons happy.

Re: I'm not burned out, I'm pissed off

#297
post #40

Earlier quoted context omitted.

> Important note for HN readers: 'driving the price up' is a net benefit for programmers. Well no, if it is hard to get software written people just won't bother. Most programmers will benefit from a commoditise-the-complement strategy where everyone is using software and need to hire programmers to tweak it to their exact needs. The money is in support & hardware. Trying to primarily compete on software price is pre…

I think there is some economic theory that states the price of products will tend towards the marginal cost over time. I haven't seen anything that makes me think software is any different. I don't think there is much profit in hardware, most companies seem to work on razor thin margins.

> I don't think there is much profit in hardware, most companies seem to work on razor thin margins.

Consider that Apple is America's most profitable corporation. They do squeeze people with software restrictions; and it is a core part of their strategy. But the focus of Apple has never been 'our software is rare', it has always been 'faster processor, thinner phone, better screen'. The artificial restrictions on the software aren't at all beneficial to the software or the programmers; they are part of a strategy to make the hardware more valuable. It is a strategic element to help their hardware resist the commodification of smartphones.

If they had inferior hardware then the restricted software strategy would see them crushed under the booted heal of groups like Samsung.

Re: I'm not burned out, I'm pissed off

#298

Earlier quoted context omitted.

Make sure you change your password every 30 days, too. That way I have to write it down, or use a sequential password just in order to be able to remember it.

"Your password is too similar to one of your previous 24 passwords" -- an actual error message I've gotten before.

Google started doing this. I spent an hour changing my password literally 100 times to clear their cache of the password I intended to set. It's insanity.

Re: I'm not burned out, I'm pissed off

#299

Earlier quoted context omitted.

This. 100% this. Any product of real complexity _must_ have a single person or very small group of people overseeing it. This is doubly true if you're product is using micro-services. The product my current employer is working on suffers immensely from a lack of central leadership to the point where each of the pieces of the application have different (and sometimes contradictory!) ideas of what the world looks like.…

Any product of real complexity is too big for any one person to hold in their head with sufficient detail. That's why we have modularity. (Microservices are just one kind of module boundary). In my experience, central leaders want to impose grand sweeping worldviews that just aren't true when you get into the weeds of particular use cases. The Director gets a pretty architecture diagram but the engineers actually bui…

I think we would be able to deliver business value a lot easier if everyone was consistent in the major ways. As it is, everyone has their own idea of what constitutes a dropdown.

Re: I'm not burned out, I'm pissed off

#300
post #212

Earlier quoted context omitted.

You kind of need to accept that it sucks for you to want to make it better. If you thought it was already perfect there would be no reason to.

The problem is interpreting what "it" means when someone says "it sucks." All software and the internet, like GP uses it? I don't think that's a fruitful line of thinking.

From experience I know it’s not all, but very close to 99%
Post reply on HN