So does the cheapest calculator?
1,021 karma · joined July 21, 2009
Founder: Test from the Top https://testfromthetop.com/ Better software testing through leadership.
AI can never touch the human interest angle of authors, the best it can do is hope to trick people temporarily, and that doesn't last long.
Ask yourself, how many "self-help" books are published by Anonymous?
Until AI is compiling straight to machine language, code needs to be readable.
Also the emphasis on greenfield projects? Starting is by FAR the easiest part. That's not impressive to me. When do we get to code greenfield for important systems? Reminds me of the equally absurd example of language choice. You think you get to choose? What?
Imagine all the code these agents are going to pump out that can never be reviewed in a reasonable time frame. The noise generated at the whim of bike-shedding vibe coders is going to drown all the senior reviewers soon enough. I'll call that Cowboy Coders on Steroids. Anyone with skills will be buried in reviews, won't have time for anything else, and I predict stricter code gen policies to compensate.
NONE of the bullshit jobs are going away, there will simply be bigger, more numerous bullshit.
No matter the extent you believe in the freedom of information, few believe anyone should then be free to profit from someone else's work without attribution.
You seem to think it would be okay for disney to market and charge for my own personal original characters and art, claiming them as their own original idea. Why is that?
> Lacto-ferment chillis with your choice of veg and/or fruit in a brine solution for a couple of weeks at room temperature.
Room temperature is no kind of standard. Optimal fermentation is up to about 75f max. I live in the south and most of the year room temp for me is at least 76. I've ruined several batches of lacto-fermented experiments before making that connection.
Don't get me started on vague salt measurements like "seawater" taste.
That applies to any interview test though, you don't need to contrive an absurd scenario to do it.
You don't have time to explain the job requirements or stack?
Artists have it rough and I don't blame them for being charmed by con artists.
Here's a tiny tip of the massive iceberg https://independentbookreview.com/2020/07/30/10-free-literar...
My mobile app BarSign: https://www.barsign.app/ I help managers get up to speed on testing: https://testfromthetop.com/
Location: Austin, TX, US Remote: Yes Relocate: No Tech: Web, LAMP, Java, Flutter Mobile, AWS, QA Automation, DevOps CV: https://www.linkedin.com/in/ross-radford/ email: ross@rossradford.com
I think the bias is merely confusion. In recruiter land anything uncertain is a pass.
The primary problem I suspect is I seem overqualified. Having a diverse skill set in all things software such as product development and engineering AND management AND devops (etc.) is just too much to process for a recruiter. Also for hiring managers in general. It's great if you're applying to say a director level position but if you NEED A JOB and try for an IC role it's a tough sell. Proficiency in multiple tech stacks is the same negative signal.
Secondary is perceived or real attitude misalignment. The problems most corporate tech companies are solving are boring and they know it. They must never admit it, and candidates especially need to demonstrate complete obliviousness. Candidates need to walk the line, simultaneously signaling technical ultra-competence and naive enough to consider yet another CRUD legacy app maintenance task challenging and interesting.
I personally don't have a problem working on boring problems, and I'm less inclined to create unnecessary challenges by using bleeding edge tech to pad my resume. Both qualities I can never admit to a recruiter. To actually get interviews, I severely cut down my resume to fit each open role. Recruiters can intuit my experience somehow anyway, and just about every senior IC role I've interviewed for lately came with a big disclaimer that this role will NEVER include management responsibilities. I guess to hedge against senior ICs expecting compensation for the management tasks they absolutely will be doing.
I'm a self-taught coder without a degree. I guess it may be extra frustrating for graduated candidates where your hard-earned degree buys you no credibility for skill.
Kinda similar, after ten years of lead development coding every day in the enterprise on huge projects I still don't get a pass on the code interviews.
I will say, if you're trying to career pivot and apply for a management or product or sales engineering role etc., lots of technical experience does carry weight in interviews.
I guarantee any book-length post on substack will get substantially LESS views than that.
This person discovered what any aspiring writer who cares already knows: Publishing like music runs on proven revenue generating content and gambles on the next big hit. Same as it ever was, and Amazon changes nothing about that fact.
Maybe publishing consolidates and changes, companies boom or bust but the business itself has always been like this.
One other thing is to limit input frequency, only allow a certain amount of posts over some period of time. Enforce this on both the front and back-end.
A little more complex, you can set a lifetime limit per user by IP address, which won't stop a truly dedicated attacker but will definitely block most of the random web crawler scripts that find your site.
The majority of bugs reported are explained as poorly designed code, which could then be tested without fuzzing.
For example: A primary class of bugs is unbound inputs, which could easily be found with static analysis. There's no reason to toss random strings at it until it breaks, you can know it will break simply because that input is unbound.
The lack of adequate traditional testing for each utility is specifically mentioned as a limitation of the studies. All fuzzing proves here, is the value of traditional testing. Of course fuzzing is going to find bugs where there are inadequate tests, but there really should be tests.
To beat all odds and discover something you can't predict, you don't even know what it could be. Some effort should be done to reduce the problem space.
In the given example, I don't see why you need to test input at the cli level when access control and input sanitation should be verified already using known parameters that reject all unpredictable input. Obviously, certain combinations of input are more dangerous than others, and at the very least, those individual systems should have focused parameterized tests, and that set reduced from the random fuzz possibilities.
Exploratory testing on highly secure, safety prioritized systems is one thing. Sure, chaotic testing like this has a place, in a very specific, hopefully highly structured system. Even then I would use it only after every other type of testing.
When someone wants to test every input possibility with random noise I roll my eyes. Test what you know is a threat first, achieve solid coverage, run tests at every stage of development and then maybe we can talk about fuzzing. Is the system actually functioning as it's intended? Are all the happy path use cases tested? Are you sure about that? Boring, I know.
I'd like my technical non-fiction to lead to a novel deal later. What do you think?
There is a culture of crisis management in the US when it comes to all health issues. This is the direct result, along with all the inefficiency you mention, of private for-profit health insurance.