As the author of the blog post, it’s disappointing to hear that you didn’t enjoy it. My article was never about claiming to be a hardware expert, but rather about sharing my personal experience as a newcomer for those interested.
What I find concerning is the unwelcoming attitude towards newcomers like myself, prevalent in some hardware and electronics communities. My critique in the article is directed at this exclusionary mindset. It’s important to remember that every expert started as a beginner, and a dismissive approach does not benefit the community. We all have unique contributions to make, and diminishing the experiences of newcomers isn’t constructive. Let’s focus on fostering a community where learning and growth are encouraged for everyone.
I think several of the slightly negative responses are because the article is about "creating a side project for a specific user segment...in a tiny market," plus discussion of business considerations, and the headline suggests something much broader.
The HN audience has folks from all aspects of hardware design, from architecture, to RTL coding, to physical design, or hobbyists programming FPGAs, etc., Saying "hardware was an entirely new world for me. I found it to be an unforgiving, harsh, complex terrain," just sounds wrong to them, like you're drawing conclusions about a huge field based on a narrow hobby project.
You seem to have set out to write an opinionated piece with a particular point of view, and said in your intro that you were going to be controversial, so you must have expected not everyone would agree with everything you said.
That’s literally one of your headings. You can’t hide behind the arrogance of the EE community when you say stuff like that, especially if you’re just ordering a four layer board from JLPCB. No offense but you didn’t manufacture anything - you did the equivalent of spinning up an EC2 instance via the web interface, installed nginx on it, and blogged about it as if you were a cloud architect. That tone permeates the post, despite the titular admission.
I would approach any professional community with much more humility. Especially when you’re still learning stuff like ”When assembling parts, you may face delays if some are unavailable.”
As an EE/firmware engineer working in the field, don't listen to the naysayers. Just because it's not some 10 layer RF board doesn't mean it's not a rewarding project and a worthwhile product. For the record, the products we design and assemble in-house are only 4 layer boards, and our business is doing just fine.There's too much elitism in engineering. I think the article is awesome; you found out a lot of pain points that I deal with regularly. The only nitpick I have is that I wish more people were on the side of open source hardware than patents.
> I think the article is awesome; you found out a lot of pain points that I deal with regularly.
Imho the most valueable part of the article is between the lines: showing how many aspects are in play, how long the route from first experiments to shippable product can be.
The devil is in the details. And those details can differ a lot depending on project, expertise or suppliers. For example one pcb manufacturer may have very different capabilities, pricing structure or quality control than another. Picking suitable components is almost an art in itself. Etc etc.
Classic distraction maneuver. This postmortem is a prime example of tech porn that diverts attention from the main issue: many at Cloudflare didn't do their job properly.
Try to learn on your own about the topic and then obtain an entry level industry certification about it. They are easy and cheap, you should consider them as an investment.
The hiring company will not check that kind of details with your previous ones.
I have the entry level ones for Azure/AWS. Working associate ones for AWS currently. It's mostly me trying to fill in my knowledge gaps but do these mean anything without production experience?
I think we are talking about different things: first you need to remove the blockers from HR when screening your CV. Certifications will help.
Once you get the interviews you have to train yourself to pass the technical tests, and that’s a different story.
If you want to get real technical expertise about a hot topic and have a good technical interview, I would start collaborating with an open source project that matters in the subject you want to shine.
Regarding “production experience”, I can guarantee you that most developers in large organizations even with a DevOps philosophy they don’t really have production experience (because they are not allowed to interact directly with the environments).
Also be honest with the seniority of the role you are going to apply. Production responsibilities are strongly linked to senior roles.
There are so many people that would happily take the risk for significant reward though. Like, make millions of dollars a year, 1% chance you go to prison? Lots of takers.
Your assumption is wrong, a large corp is not an organized crime corporation.
To be a CxO of a large corp you just can’t be “people”. You have to be a person qualified way above the rest of us. If you can make millions in a different place not taking the risk of going to jail you won’t take a role in a risky corp.
May be they are psychos, but not idiots.
I disagree. Plenty of folks incurred very high fines and even jail time over backdated options. People still backdate options. The risk is low enough, and the return is high enough, for people to creatively interpret the law. As long as there is an interpretation that could be valid, laws will be bent.
That’s what our “Teleinformatics” professors taught to us early in the 90’s at the university. OSI protocols were promising but adoption was not clear.
I worked for Microsoft back in 2018-2019 and I was in charge of choosing and sponsoring T3chFest. It was BY FAR the event with the highest engage metrics per euro invested.
It was crystal clear that they were a NGO because they did not enforce contracts and deadlines like a professional event organization. But we understood it and tried to help them to cross the corporate hurdles to close the sponsorship deal.
I don’t know what is happening, and I’m pretty sure this is peanuts for Couchbase. They should fix this mess just to avoid the impact in their reputation.
I would say the opposite. The manager who receives the PR (merge request in gitlab) needs to know what has changed (if it is not obvious from the diff) to assess the change before accepting it. He has to know what has changed, for example to decide which non regression tests to performe.
The final user of the software will receive a changelog (a list of commit messages) that shall identify the bugs that have been fixed and the new user requirements that have been added. He needs to know why the code has changed to know what he has to do.
Whatever decision you make, be 100% sure first he is taking all the credit and using you as a “ghost coder”. Sometimes remote working environments make us think they are not taking in consideration our work.
Try to skip a management level in an informal environment like a coffee machine and start a short pitch about “your project” with the boss of your boss.
What I find concerning is the unwelcoming attitude towards newcomers like myself, prevalent in some hardware and electronics communities. My critique in the article is directed at this exclusionary mindset. It’s important to remember that every expert started as a beginner, and a dismissive approach does not benefit the community. We all have unique contributions to make, and diminishing the experiences of newcomers isn’t constructive. Let’s focus on fostering a community where learning and growth are encouraged for everyone.