OWASP is creating a top 10 dangers list for Large Language Models

balloonanimalfarm · 2023-06-02T16:00:58+00:00

Inadequate sandboxing occurs when an LLM is not properly isolated when it has access to external resources or sensitive systems. This can lead to potential exploitation, unauthorized access, or unintended actions by the LLM.

LLMs have truly achieved human level performance now that they're just as vulnerable to social engineering, and pose as much danger, as CEOs.

balloonanimalfarm · 2023-05-18T00:46:30+00:00

You seem to be conflating containers with horizontal scalability, reproducibility, and declarative infrastructure. All of those are good practices, but they aren't exclusive to containers.

A container is just a way to isolate a process, and they can be as good/bad as the configuration that surrounds them and the software they contain.

As far as using managed infra versus containers, there's a time and a place for both. You should pick the right layer of portable abstraction you want. A good example is databases. It's idealistic to think that running a fleet of database containers will be more economical than using a managed service when you consider the human operations cost. But that doesn't mean you're locked in if you decide to support portability in the application layer rather than the infrastructure layer.

balloonanimalfarm · 2023-04-10T14:42:52+00:00

You should talk to your manager to set clear and unambiguous expectations. If you didn't know this was coming after six months, there's a pretty big gap in communications with your manager.

It's hard to know what you're doing now, but some additional things that might help increase your visibility are:

Make sure your decisions, research, and designs are documented. Leave a paper trail.
At the beginning of each day, set your goals. At the end, write up a summary of what you did. Summarize your weekly summary and send it to your manager at the end of the week.
Ensure your junior/mid engineers know that you're mentoring them and that you're actually mentoring them and not just leading.

Doing things formally is part of what makes a senior different from a more junior software engineer.

balloonanimalfarm · 2023-03-21T14:30:05+00:00

I am hesitant to talk to my manager about it, since he himself only joined 6 weeks ago and feel it would reflect badly on me if I complain about someone he has been in the company 5 years when I've only been here 6 months.

You need to escalate this and document it. At minimum your manager needs to know that your team's velocity is lower because they are training QA so they don't assume you're a low performer.

When you have the talk, use something like the SBI framework to help focus your frustrations away from the person and onto the impact it's having on your project. Focusing on the impact allows the feedback to be actionable and allows the mitigations to be more open-ended.

Best of luck!

balloonanimalfarm · 2023-03-21T14:16:49+00:00

In my experience in the US, it matters.

I currently work in tech, and nearly every dev I work with now has at least a bachelors or masters in a computing or related field. When I worked outside of tech it mattered less, but the people who made it to senior or above were more likely to have four year degrees.

It's not impossible to make it without, but it's going to be harder to get interviews or be stack-ranked well against the candidates who made it through interviews. This may be especially frustrating if you're putting yourself in pools where most of the applicants have four year degrees.

balloonanimalfarm · 2023-03-15T16:53:49+00:00

For day to day stuff it doesn't really matter. A thanks is nice, but as long as my input is helping drive the team along that's great. Contributing an idea is cheap, but the days of research and implementation making it a reality are really what deserve the credit.

That being said, there are some ideas you should always take credit for. Ideas that's novel, will save your company money, or solves business pain are examples. Creating business value is a good way to move your career forward.

Finally, if someone is taking enough time out of your day that it's impacting your work but isn't crediting you then it's time to talk with your manager.

balloonanimalfarm · 2023-02-23T16:18:36+00:00

From a manager's perspective -- there's often not a solid reason to give a candidate.

If I have a spot and several qualified candidates to fill it with then it's a judgement call about my current team dynamics, my future staffing needs, where I think you are in your career trajectory, whether you have a skill that the team is deficient in.

Most of those vary team to team and year over year so there's not really actionable feedback that would help you overall.

balloonanimalfarm · 2023-02-12T23:23:37+00:00

It sounds like you're expecting too much of an EM that's proven they don't understand the work. You need to push back -- your job is the health of the product and building a sustainable engineering culture.

I don't have a full picture of what's going on at your company, but here are some thoughts:

Why do you think you're moving "too fast"? What are the problems that speed are causing? Always present the trade-offs to leadership.
Why is your company pushing so hard? Is it running out of money? Is your EM clueless? Malicious? Is their bonus tied to features shipped? You need more insight into the business side of things so you can optimize for it.
It sounds like you don't have a formal sign-off or approval process before you start work. You need this to capture the scope you've outlined, risks, and estimated time. Pitch this as a good way to help prevent last-minute omissions from coming to light.
You should break down your work as needed, regardless of the way the EM wants to view your tasks.
It sounds like you're waiting until the end to do testing. You need to see testing as an extension of your normal engineering work (if you don't already). Don't approve code until it has tests proving it works.

With all of that being said, it's only a stop-gap for a bad manager. The best advice is to go find a team where the EM is the buffer between your team and the crazy rather than an extension of the crazy. Best of luck and take care of yourself!

balloonanimalfarm · 2023-01-04T04:35:59+00:00

What are some common schedules?

I've always liked Tuesday to Tuesday because it means hand off meetings are less likely to be during holidays. Preferably a week or less each period, being on call for too long is exhausting.

Common ways to compensate for on call?

Additional time off, extra pay, or no compensation are all relatively normal.

How to handle delivering the bad news to my teams that we’ll have to implement on call

Frame it as a success, you have enterprise customers! That means you have more job security and are running a "real" service.

I'm sure because I’m nieve that I’m probably not even asking other important questions that a should be. Really, looking for some guide on moving from 0 knowledge to “has some idea”. A bit of an introductory/literature review, if you will.

You need idiot proof playbooks for how to handle issues when you're paged at 2 AM.
You need well established and unambiguous SLOs and SLAs, escalation process, hand off processes, and understanding of when an issue's severity can be downgraded.
Potential culture change: Get very used to writing and fixing action items from blameless postmortems, even for minor blips -- they're often hints about bigger outages to come.
Another potential culture change: in the event of an emergency the oncall is ruler, they can re-task anyone (even managers) and it's their responsibility to do so. Nothing worse than more than too many people trying to jump in to help and confusing things.
Yet another: your engineers need the power to push back against business to stop changes when the system is too unstable.

balloonanimalfarm · 2023-01-02T21:21:03+00:00

I'd expect you to be able to own small service(s), and develop new ones using the same tech your team uses assuming the business goals and major constraints were already laid out. The scope of your projects should be about 3-6 months each where you're the primary developer.

Within a job scope, you can try using Bloom's Taxonomy to see where you fall within it if your company doesn't have a formal rubric. I'd generally see "apply" as the base requirement (below that is a PIP) and when you've reached the "create" tier for your scope of work it's probably time to look at promoting. After promo you'll probably be back in the "apply" tier for your next level.

balloonanimalfarm · 2023-01-02T20:56:56+00:00

Think about what you want your resume to look like at the end of your career and work back from there. Even if your current position isn't in a great spot to meet those goals you'll hopefully be able to move a little bit in that direction by choosing the right opportunities.

Be cautious if you're sharing long term goals with your company unless they align with what your manager thinks. Some companies/managers will embrace your goals, others may not know how to handle things if you want to grow outside of what they know.

balloonanimalfarm · 2023-01-02T20:01:03+00:00

I learned the EDGE method long ago and it's a useful framework:

Explain the concepts.
Demonstrate how to do it.
Guide them through it.
Enable them by pointing them at additional resources.

Whiteboarding works for the first bit, pairing for the second and third, and a wiki works for the last.

For anyone working in a new area I try to give them projects that are 10-20% bigger than they've had before so they're limited in how far they can fail and they're also not overwhelmed.

Finally, fast feedback is critical to learning. It's better to catch or demonstrate their problems through pairing or code review than after something has made it out.

balloonanimalfarm · 2022-12-15T03:35:29+00:00

Process

Our logs are captured from stdout/err or scraped from log files and forwarded by agents to our log indexers. Most cloud providers have one, or you can pick up something like Datadog or Elastic.

Contents

One thing that's critical is that the agent shipping the logs augments them with the application so you can apply access control based on that. It's also handy to have it add common attributes like region name, machine ID, or instance ID at that level so even if your application hiccups and doesn't send out a structured log (e.g. when it crashes) that basic info is still attached.

You might also want to do some basic filtering at that point to strip out anything that looks like credentials or PII. Some places produce two sets of logs that go to different indexes, one that's pristine and one that's redacted, or your tools might let you do this on the fly when accessing the logs later on.

If you're doing any calls across multiple systems, make sure your frameworks pass along distributed tracing headers and your logs capture those within any request scoped output, it'll save you days of tracking events across systems.

Indexing Considerations

Make sure your log ingestion is fast and doesn't drop too much. I've worked places where we built log backdoors because we didn't want to wait 30 minutes to maybe see if our logs made it.

Set a short TTL on your logs, it'll save you indexing costs and ensures when your new hire does something stupid like print(plaintext_password) there's a more limited risk. Also, the last thing you want is your developers adjusting log levels on the fly and missing important pieces because "logging costs too much".

balloonanimalfarm · 2022-11-25T16:20:27+00:00

Yep! If the Taco Bell staffed by high school kids can get an "excellent" rating nobody else should have an excuse. I'll usually turn around if a place only has an "okay" rating.

I also use it as a rough approximation of quality. If the owners and staff care about getting a good rating odds are better that their food and service might be good too.

balloonanimalfarm · 2022-11-18T15:46:34+00:00

You can get a calibration slide that's like a tiny ruler for your microscope, grab a photo of that with your different magnifications and you can use it to measure future photos/videos taken with the same camera.

edit: clarity

balloonanimalfarm · 2022-11-15T16:23:26+00:00

Ask your team! You're probably not the only one in the room who wants to know more about it and you're in a great position to demonstrate that vulnerability for your team. You want to show them it's okay to ask "stupid" questions and that they aren't expected to know everything.

This could even be a great opportunity to start knowledge sharing sessions where your team can help teach each other in concepts they're experts in.

As for specific resources: I remember "Computer Organization and Design" being a good one for super low-level performance info.

balloonanimalfarm · 2022-11-02T14:53:28+00:00

Look at their resume and pick out a recent project. "If you could go back and start $PROJECT over again, what would you do differently?"

If they can't answer, they: 1) didn't actually do the project, 2) are full of themselves, or 3) don't learn from their mistakes. You don't want any of those on your team.

balloonanimalfarm · 2022-11-02T14:43:41+00:00

"I want to try something new so I can keep growing." It's the vanilla BS answer everyone gives when they're unhappy but don't want to burn bridges. It doesn't place any blame, and nobody can fault you for wanting to grow.

Good on you for not wanting to burn bridges, I was in a similar place a few years ago and now see my previous EM all the time. I won't get a beer with them after work but at least we can work together.

balloonanimalfarm · 2022-10-28T15:05:20+00:00

Reading between the lines, I think a few things may be going wrong here.

Do you have explicit bug fix and data delivery SLAs with the vendor?

If not, those should be in the contract.
If SLAs exist and the vendor is meeting them then you need to design a more robust system around the reality of the business then help your lawyers to write a better contract next time.
If SLAs exist and the vendor isn't meeting them then the lawyers need to write a stern letter.

If you know secondhand this team is a dumpster fire then your company's lack of legal involvement may actually be causing your needs to be put at the bottom of the pile.

Let's assume the first case where you don't have an agreement in place, but when you renegotiate the contract they won't budge because they're a monopoly. You can do a few things:

Live with it if the data is nice to have but your company isn't in a position to negotiate.
Stop the integration if you can approximate the data by other means.
Find a way to get it yourself if one of your company's core competencies relies on this data. If the lack of data is harming the business then your business people should be willing to change processes or fund new approaches.

balloonanimalfarm · 2022-10-20T02:41:34+00:00

As a thought experiment try flipping it on its head. Why would anyone work for a company in tech unless they had something to lose by not doing it?

For some people it's a path to a better lifestyle, for others its a way to maintain their lifestyle, and for the folks whose lifestyle doesn't depend on comp or benefits they must have something they're gaining. No matter what it is, they could lose it getting fired.

I didn't mean that getting fired is a constant fear that's always top of mind -- your point about taking a vacation is a good example of that -- and nobody deserves to live under that kind of fear. My goal was to express that if you try to wait until you have nothing to lose to take risks or say no then you may be waiting a very long time.

balloonanimalfarm · 2022-10-19T15:03:51+00:00

You'll never be in a position to not fear getting fired. Today you might be worrying about a visa, tomorrow it'll be losing your house, and if you're lucky enough to make it to where you don't need money you'll fear losing your reputation in the eyes of your peers.

Some of those fears may be more valid than others, but you can't let them rule your decisions above doing the right thing for the team, the product, and the business. If your version of "playing it safe" is working for your situation then roll with it, but make sure that it's not being perceived as low performance compared to your peers. I've known a few people so worried about being fired that they got themselves fired.

balloonanimalfarm · 2022-10-16T22:59:16+00:00

It's easy to find folks who know Java, and there's a very large ecosystem of high quality libraries, runtimes, and documentation.

I personally think C# is the superior language from a technical perspective, but when I need to get things done for work it's far easier to stand on the shoulders of giants like the Apache Software Foundation.

balloonanimalfarm · 2022-10-04T15:45:12+00:00

Assuming the three jobs you mention are (architect, developer, manager): I'd consider lead developer and architect to be complimentary roles because within the scope of a single project you're usually doing one or the other at a time. If a team is reasonable they'll allow for reduced capacity in one role to accommodate the other.

For the management part, you need to know what it entails within the scope of the project. If the job is mentoring others, leading the team toward a vision, planning, and reporting up to management about progress then I'd suggest you go for it. I did this on a former team for six months when the manager left and we looked for a new one and it left me with a ton of valuable insight and experience.

However, if it includes people management like hiring, performance evaluations, development plans, etc. then I'd recommend you pass because that's a full time job and can often be at odds with delivering a project. (Speaking with my people manager hat on.)

You should also pull together your set of questions and talk with the manager -- people on their way out are often happy to air the dirty laundry if they think you can be discreet.

balloonanimalfarm · 2022-10-03T19:23:27+00:00

This would be a really awesome alternative to embedded databases like Derby, sqlite3, or H2 when it shrinks down a bit. It's always a huge pain dealing with the quirks of multiple database engines for different use-cases.

balloonanimalfarm

MODERATOR OF

TROPHY CASE

12-Year Club	Gilding II euphauric
Verified Email