• 0 Posts
  • 57 Comments
Joined 1 year ago
cake
Cake day: July 23rd, 2023

help-circle


  • thesmokingman@programming.devtoProgramming@programming.devSafe C++
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    edit-2
    5 days ago

    Right now, we have to compile the compiler for this ourselves. Pardon my skepticism; I’m not sure this is mature enough.

    Edit: I’m talking about the project not the idea. Sean Baxter has shown up everywhere for awhile talking about this. I think his idea has a ton of maturity. I don’t know that the project itself has enough maturity to mainline yet.



  • I have heard the same rhetoric about IDEs, autocomplete (Intellisense, Jedi, etc.), DevOps, and frameworks. The kernel of truth across all of them is the separation between a dev and good dev. It is getting easier and easier to have something built for you using AI in your IDE in a framework that abstracts all the things away dumped into a prebuilt pipeline that deploys your artifacts for you. A dev can do that. A good dev understands the tools and knows when to dig into things.

    I have yet to see a decrease in the number of good devs I meet even though IDEs slowly replaced text editors (and editors became strong enough to become IDEs). Frameworks have enabled more good devs to focus on business logic. DevOps provides solid guard rails for everything.

    I don’t know if there’s an increase in the number of superficial devs. I haven’t interviewed junior dev candidates in awhile. I do know the market is flooded right now so I’d argue there might be other factors.

    Also overall I do agree with the idea that letting copilot do everything for you means you don’t understand anything. Shit was the same way when cookbooks were common.





  • I mean anything is a good fit for future, science fiction AI if we imagine hard enough.

    What you describe as “blatant malicious code” is probably only things like very specific C&C domains or instruction sets. We already have very efficient string matching tools for those, though, and they don’t burn power at an atrocious rate.

    You’ve given us an example so PoC||GTFO. Major code AI tools like Copilot struggle to explain test files with a variety of styles, skips, and comments, so I think you have your work cut out for you.



  • There are competing interests here: normal consumers and script kiddies. If I build an API that follows good design, RFCs, pretty specs, all of that, my normal users have a very good time. Since script kiddies brute force off examples from those areas, so do they. If I return 200s for everything without a response body unless authenticated and doing something legit, I can defeat a huge majority of script kiddies (really leaving denial of service). When I worked in video games and healthcare, this was a very good idea to do because an educated API consumer and a sufficiently advanced attacker both have no trouble while the very small amount of gate keeping locks out a ton of annoying traffic. Outside of these high traffic domains, normal design is usually fine unless you catch someone’s attention.






  • Speaking from 10+ YoE developing metrics, dashboards, uptime, all that shit and another 5+ on top of that at an exec level managing all that, this is bullshit. There is a disconnect between the automated systems that tell us something is down and the people that want to tell the outside world something is down. If you are a small company, there’s a decent chance you’ve launched your product without proper alerting and monitoring so you have to manually manage outages. If you are GitHub or AWS size, you know exactly when shit hits the fan because you have contracts that depend on that and you’re going to need some justification for downtime. Assuming a healthy environment, you’re doing a blameless postmortem but you’ve done millions of those at that scale and part of resolving them is ensuring you know before it happens again. Internally you know when there is an outage; exposing that externally is always about making yourself look good not customer experience.

    What you’re describing is the incident management process. That also doesn’t require management input because you’re not going to wait for some fucking suit to respond to a Slack message. Your alarms have severities that give you agency. Again, small businesses sure you might not, but at large scale, especially with anyone holding anything like a SOC2, you have procedures in place and you’re stopping the bleeding. You will have some level of leadership that steps in and translates what the individual contributors are doing to business speak; that doesn’t prevent you from telling your customers shit is fucked up.

    The only time a company actually needs to properly evaluate what’s going on before announcing is a security incident. There’s a huge difference between “my honeypot blew up” and “the database in this region is fucked so customers can’t write anything to it; they probably can’t use our product.” My honeypot blowing up might be an indication I’m fucked or that the attackers blew up the honeypot instead of anything else. Can’t send traffic to a region? Literally no reason the customer would be able to so why am I not telling them?

    I read your response as either someone who knows nothing about the field or someone on the business side who doesn’t actually understand how single panes of glass work. If that’s not the case, I apologize. This is a huge pet peeve for basically anyone in the SRE/DevOps space who consumes these shitty status pages.


  • This is a common problem. Same thing happens with AWS outages too. Business people get to manually flip the switches here. It’s completely divorced from proper monitoring. An internal alert triggers, engineers start looking at it, and only when someone approves publishing the outage does it actually appear on the status page. Outages for places like GitHub and AWS are tied to SLAs that are tied to payouts or discounts for huge customers so there’s an immense incentive to not declare an outage even though everything is on fire. I have yelled at AWS, GitHub, Azure, and a few smaller vendors for this exact bullshit. One time we had a Textract outage for over six hours before AWS finally decided to declare one. We were fucking screaming at our TAM by the end because no one in our collective networks could use it but they refused to declare an outage.



  • If you are able to find a US govt job and can make it through the whatever period you need to be a contractor until you get hired on as a federal employee, this should cover you. I have a contact in a similar situation except cluster headaches. It’s going to pay less than private sector and you might have to learn some new skills for the right role. IIRC Softrams just landed a huge federal contract and hires warm bodies; might be a great place to start.

    I’ve got a lot of contacts on the market right now struggling to land a gig that wouldn’t have struggled a few years ago. Do you have DevOps skills? Any security qualifications? Get both. Are you working on certs? Do some. Have you hired a resume service? Do so. The last two are things I normally think are kinda bullshit but they are edges that seem to matter right now.

    As for a recruiting firm, I feel like all the good recruiters I’ve worked with would have advocated for me. That’s a total fucking crapshoot tho. I’ve worked with plenty that have shafted me. I don’t think there’s a specific firm for this problem.


  • My stance has been that, just as long as I’m interviewing with someone, I’m happy to do it, up to an undetermined time threshold. A screening interview, a tech screen, and then a bunch of panels is what I expect from a solid firm. Just as long as I’m interviewing with someone, I have a lot of opportunities to learn myself. I will also occasionally do a take home if and only if there’s a novel problem I want to solve related to that take home (eg I want to learn a library related to the task) but this is very rare.

    As a hiring manager, I try to keep things to a hiring screen, a tech screen, a team interview, and a culture interview. My team is small. I don’t want to spend more than three hours of someone’s time (partially because I can’t really afford to spend more than that myself per candidate or lose more team hours than that). My tech screens are related to the things I actually need people to do, not random problems you’ll never see.

    My assumption is that a good dev has lots of opportunity and I am in competition with everywhere else. I need to present the best possible candidate experience. Big companies with shitty employee experience telegraph that by presenting a shitty candidate experience, which is where the employee experience begins. You can’t have a good customer focus without starting from a good employee focus.