Hacker Newsnew | past | comments | ask | show | jobs | submit | HeyLaughingBoy's commentslogin

My experience with hardware engineers, at least IRL, is very different. They love to talk about their work. However, I used to be an EE so that probably helps.

As for Reddit, there's a lot of "bury head in sand and problem will go away" behavior when it comes to AI. People are understandably worried about their jobs, but they're certainly not doing themselves any favors by downplaying AI or looking for "tech niches where AI isn't yet."

Copperhead is very interesting. I do some embedded systems consulting on the side, but I've never enjoyed PCB layout very much. I briefly investigated using AI for it the last time I had to do a board, but it wasn't very helpful.


Thing is, what can they realistically do? Any work that does not involve a social component is on the way out. All work that remains will be more like "service" than like "work" the way we see it today ("service" as in "civil service", not as in "held in service or labor", i hope).

"I got five kids to feed"

It's funny. As a SW dev working on medical devices, I've done at least two catheter ablation machines that I can think of, but I never knew the specifics of exactly what problem it solves. I mean, I obviously know in detail what the device is doing, just not the why.

And it's specific to just that type of device: anything else I've worked on that I can remember ATM, I know what they are used for.


Huh. I was actually thinking about him a few days ago. Is he still among the living?

I remember posting on PM about 15 years ago asking how to fix a mistake I kept making and he gently smacked me on the head and basically said just learn to do it right in the first place. Which was really the only good answer!


No, he died 2 years ago. The immense knowledge and skill that he shared with everyone remains an incredibly valuable archive and hopefully remains searchable for the indefinite future.

I had a co-worker who was an experienced software developer but had never worked on a system that interfaced with the physical world before.

For quite a while, he hated having to test on real hardware because all sorts of failure modes that he couldn't predict: belts stretching, mechanisms hitting each other or not lining up properly and losing position, etc. kept happening and interfering with his nice "this will only take 15 minutes to test" estimates, making it an all-afternoon affair.

OTOH, it was that unpredictability and having to deal with weird stuff that I liked about programming embedded systems.


That's not a valid comparison.

A Jira log is not part of a Quality Management System (QMS). An aircraft maintenance log is. If you fake data in the QMS, software or not, for a regulated industry, I can assure you that it won't be taken lightly by the regulators.

Try forging the software validation test records for that airplane's flight control system and see what happens.


My point is exactly that there's no such thing as legally required quality management system for software. And that's what makes software development uniquely shitty in terms of not having documentation or following written instructions, to a degree unseen in any other STEM discipline. Trying to explain lack of knowledge transfer in aviation industry by putting it in terms of software industry was the worst possible analogy out of all analogies that could conceivably be made on this subject.

Forging software validation records isn't illegal because you're forging documents regarding software, but because you're forging documents regarding an airplane. Nobody gives a flying fuck about forged records for software that isn't installed on any airplane. It's not the act of forging that's illegal, but the act of installing forged software on a real airplane. Unlike the airplane repair records, where forgery is a crime in and of itself even if the airplane never flies.


Hopefully something happens a lot quicker than with volkswagon!

I don't think you guys are really disagreeing with each other. Just that one is using a colloquial definition of "missing" and the other, a technical one.

This really made me think about what got me interested in programming and I have no idea. In HS, I had a Physics teacher who had a TRS-80 (Model 3, I think) and he would let us use it during Lunch for whatever. But I was already interested at that point. We had a "programming" class where we programmed some kind of computer in some unknown language, but again, I was already interested in programming before then: that was just the outlet.

Really have me wondering now.


To your point I think I'll adjust what I was saying a bit. I was definitely interested. I always thought it would be cool to be able to program. There was good media to make it intriguing from afar. But I had nobody in my life to help me understand.

My mom did a great job making sure I always had a computer but she didn't know enough about them to help.

Elementary school put us in front of them and taught us how to type and let us play oregon trail and print shop, but that wasn't it. And my high school has us programming in Pascal. Meh.

When I was in my 20s, in a new city, working to pay my own way I found the determination needed to teach myself. It absolutely helped that the internet was becoming this wealth of information for the self-taught. That was my launch pad. I definitely think everything else helped get me there


To paraphrase what I recently said to someone I haven't seen in 25 years: one of the greatest gifts that ageing has given me is increased self awareness.

I think this is just a Jira/bitbucket thing. If you add a feature branch, that's how the naming convention defaults. I've been seeing it for years.

I assumed the convention came from somewhere before AI and maybe one of the new devs brought it in from there. We also have an analyst who used em-dashes before AI ruined them, and who justifiably complains about that every so often. I'm not sure that's a trend anyone wants to pick up on.

But for branches in addition to Feature/, we're seeing Hotfix/, Modernization/, you name it. If you're parking branches for a long time without completing them, I'm 100% appreciative they're categorized.


The original git flow suggestion [0] was posted more than 15 years ago (date on the post is 2010). It didn't entirely invent the branch names/conventions from whole cloth, it was based on plenty of prior history in SVN spaces especially, which it picked up from CVS.

(Personally, for long term parked branches I prefer `{username/dev name}/` branches because then you know who the owner is without having to look at the commit log and guess based on recent commit authors. But that's the fun thing about branching conventions, there are so many to choose from, many of which have been around forever.)

[0] https://nvie.com/posts/a-successful-git-branching-model/


Linear does this, too. It provides a button that copies a branch name to the clipboard based on the ticket id/name.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: