HN user

r0s

1,020 karma

Founder: BarSign https://barsign.app Mobile point of sale with unique user experience.

Founder: Test from the Top https://testfromthetop.com/ Better software testing through leadership.

Posts4
Comments628
View on HN

Almost zero readers buy a book based on the title or content alone. They buy Dr.Phil because they saw him on TV and know a bit about who he is. On the other end of the spectrum, there's people buying books because they respect and admire the author's other work.

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?

Weird to claim the llm does all the boring learning and boilerplate for you as a selling point, but then also insist we still need to responsibly read all the output, and if you can't understand it's a "skill issue".

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.

It's not baffling in the least.

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?

Hot take about fermentation in these recipes.

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.

Totally agree about NFTs, but any artist gets a full pass from me.

Artists have it rough and I don't blame them for being charmed by con artists.

Ross Radford - Lead Software Engineer, DevOps, QA automation specialist, seasoned enterprise veteran and former founder looking to lead a team to create world-class software.

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

Confirmed. I took a year off for my startup attempt, currently looking for another 9-5 and they really don't know what to do with me.

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.

Everyone seems to agree live code interviews are both terrible and necessary.

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.

No one buys books 2 years ago

Is anyone else alarmed that the top tier is book sales of 75,000 units and up? One post on Substack could get more views than that…..

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.

This is on point.

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.

According to these reports, the effectiveness of fuzzing decreased over that time period.

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.

Fuzzing is guesswork. I see this attitude: because an unknown bug could possibly exist, therefore it could be a high severity bug and is then worthy of expending a lot of time and effort to discover.

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.

My first book deal went through recently and I'm about to finally get published. Any advice for a first timer?

I'd like my technical non-fiction to lead to a novel deal later. What do you think?

All that is true of regular type as well to some degree, I guess my point is a standard of readable url type could have all those qualities.

Also the longer a url is out in physical space the more danger of it being replaced online, longevity may not be desirable.