I too could, theoretically be thrilled to be drugged to the gills when I'm killed. I however, can consent. Animals cannot. But we know that animals can think. Regardless of debating the ethics of consuming them, this adds an additional ethical quagmire of is it ethically sound to drug non-consenting, thinking species.
This is a bit oversimplified, and relies heavily on understanding your threat vectors and agents. You haven't spoke about audio even.
There's a reason that many military and intelligence organizations worldwide physically cut / remove wifi and bluetooth chips from boards. The same is done when audio is identifiable, and specific hardware (only) greenlit.
I've lost hours of my life to calls explaining exactly this, only to have people ignore it, only to further have folks come back, tail between their legs. The worst part is learning this in industry, as I did. There's a reason for in-industry advisors. I wish that I had learned this the easy way.
I tend to apply this to myself, within an organization (as opposed to those who like to generically try it all - fair enough). I've always been an enormous fan of touring the organization. Whether I join as a dev, or an exec, I always make it a point to spend some time with product, with support, and with marketing. It ends up providing me a unique vantage point. I encourage others to do the same, and when I 'control' onboarding, make it part of the process.
It's literally the fastest way to have someone get up to speed with the customer profile and product. They can play with it whilst listening in to support calls (if a thing). They can learn about pain points and "hard edges" that as developers we don't always come across.
any tips on how to go about such things? its occasionally hard to find excuses to go hang out at the other end of the building and talk to another team I dont know much about as a regular developer
Always have a folder in your hand when visiting other teams in other parts of the office. Print out some code, a few pages of spec, whatever. Just don't go walkabout empty-handed.
I'm not going to pretend to understand your stuggle, but I will echo it through my lens. I am not trying to hijack your point, inasmuch support it with my view.
I uses to think that it was about fear of the unknown, or as you've said "Being angry at people who make you feel a bit weird inside".
I now firmly believe that it's a modern form of tribalism. Having an "other", whether as a scapegoat, a fear inducing device, or a target is simply too convenient to ignore. Whether or not one is a globalist is orthogonal to the fact that people ultimately decide, or evolve to see through a different lens.
One look no further than Vietnam for how the government learned to use intranational xenophobia to manipulate different slices of the public into identifying as separate groups that could then be played off of each other. Since then, there has never been as successful a political movement, because we have been turned against each other by state-driven manipulation. AFAIK, this is well-documented policy intended to “maintain civil order” (i.e. prevent the revolution that is so richly deserved).
I would say it slightly differently: humans themselves are tribalistic, and politicians are looking for ways to tap into that to gain and hold onto power.
There's an issue where people assumed the syntactic activity of writing code was what mattered. The reality is that this was always a smaller part of the role, as opposed to thinking about observability, serviceability, and test automation. The ability to write software that is properly separated from concerns and when to enact those separations matters.
At the same time, I think we're far too far down the systems path now. We've hit a point where interviewing has become purely systems design "because the AI writes the code".
Not that I'm ever asked, but I inherently believe the act of critical thinking, communication, and expression are the key skills for those who already have the appropriate coding/engineering/cs/etc background. I now only interview for those skills - but through the lens of impossible to solve systems design conversations as opposed to problems. It tells me a lot about how people think.
So is architecting, testing, validating, and even occasionally using.
This isn't the first time I've seen this phrase recently, but I'm not sure what the thought is a cliche or what it is intended to convey (don't read my note as negative, I sincerely am unsure what connotation folks are trying to say).
The idea behind "writing is thinking" is that people often overestimate their understanding until pressed to express it in words (or code).
How many times in your career did you sit down to tackle a task thinking you knew exactly how to approach it only to realize during implementation that there were edge cases you hadn't considered, API contracts that were now broken, or that the feature was trying to solve the wrong problem.
Having to be the one at the helm during implementation made you intimately aware of not only the problem at hand, but the current state of the codebase. That's something you can't replace with automation. You can't compress all of that context into your brain in a handful of prompts with Claude.
Remember the words of your math teacher--
"Watching someone else solve the problem doesn't mean you can now solve it too."
Not sure what you mean as system design conversations because while in theory those can be good in practice the ones I have been at had been techbro wankery where the interviewer had a particular answer in mind. Like designing your own memcached clone for example is a terrible task for systems design.
What you're mentioning is 100% what's wrong with the industry. Agreed! To me a systems design conversation is a conversation - not a design goal. The idea is to determine ability and psychology:
1. When you press on someone's design respectfully, do they get defensive. Do they become argumentative.
2. When thoughtfully pointing out a concern, how does the candidate take it?
3. When you suggest a technology that makes no sense to intentionally challenge knowledge, does the candidate recognize why it makes no sense? Are they able to share what the negative of the approach is. If you indicate that you know the question is "senseless" but want their feedback, how do they communicate?
4. When you hard request a change that requires a literal rethink and rewrite do they become argumentative? Do they embrace the change?
5. When discussing testing, how do they think about it? I come down to the nitty gritty and ask about postive vs negative cases, table driven testing, what types of tests matter (for our situation) and why.
6. We discuss timeline tradeoffs, and then have the conversation about the candidate's approach given updates to see how they think.
You'll notice that I am never looking for a solution. I'm seeking communication, description, partnership while having a (relatively) thorough gasp of the subject matter.
Every single time I get a response from a candidate such as "I don't know, I'd have to learn more - or use AI to, or.. what do you think" turns out to be something I LOVE, because it creates a great fabric for the interview.
I'm a (Samsung) Fold user. They're great - a year in I never, or rarely if ever see the minute crease, and ditto here with Apple. The reality is that ~70% of the time I want a small screen. It's perfect (if thick due to the fold). It opens to "larger" (i.e 8 inches) which is great - compared to what I had before (6.9").
I'm actually hoping that this will force Samsung to solve their silly lockscreen choices, and the fact that it needs to be "configured" to be useful, because it's separate (Multilock - I'm talking to you). Honestly, I would happily take even bigger. The extra real estate when you want it is great. But it needs to hit tablet(ish) sizes. We're just in early days.
Thank you for sharing this. It's such a great example of how fun learning and the internet can be. It's downright refreshing when things don't have the same exact design as the rest of the universe, and take the time to teach something.
Why do we have the assumption that industrial robots need to have legs? The largest grocery store chain uses picker robots already - for building my orders, including fruit / vegetables (from boxes). They currently have humans filter the veggies and fruit prior to box setup, but a friend is working on the models to eliminate even that.
Their robots do movement using sliding scale in 3D spaces (think poles that are left right, up and down, and the "picker" being able to glide and move. They currently have a ceiling slider that goes down and suctions things into a pneumatic tube to then end up in my grocery bag. IMHO it works pretty well - especially considering that delivery is ~$8 for me.
Ultimately we're going to end up with several different types of robots, and not with a human centric vision. The question is if bipedal is a long term dead-end, and merely a short term method to fit into the world we currently have designed.
There's a bunch of options for this task, but combining the three wheel stair-climbing dolly with the self-balancing hoverboard/segway seems like the easiest.
you don't need legs to climb stairs, you can have a rotating mechanism with different rows of wheels that have good enough grip, maybe an extruding stick to lift the whole robot up and the wheels move forward... would take a lot fewer joints than pair of legs probably.
There's a clear difference between defense, mission critical software, and slip. Medical cannot tolerate bugs of this nature (it's literally illegal in many a jurisdiction), which accounts for part of the cost, the approach, and testing cycles.
Can we get there in the future - perhaps. But the accuracy needs to be much higher. I remember in the 90s when my father's clinic tried both Softvoice and Dragon. Comparing it to his receptionist typing out his notes, the accuracy was in the 80s - hence rejected. Just last week an AI startup here in Israel was kicked out of their HMO partner for having a transcription accuracy of only 92% in a mixed mode these where a doctor, patient, and caregiver are all in the room (think doctor + mom + kid)
For the curious - trained medical receptions have and maintain accuracy rates when measures of 97%. This is just transcription.
Hallucinating entire events is another, far worse thing.
I've had both self hosted GitHub (enterprise), and GitLab in the last year. It really deoends what you're trying to replace and how you structure the things you're hoping to replace. Also, the value of investing in your separation of concern or safety valve.
To me, still, at a scale of 250 contributors (which we hit), Gitea solved all the problems. The fact that there's a command line tool (tea) that mostly works, means that it is beyond good enough for my use case, out of the box. It misses all sorts of things and depending on how important they are, you then invest in looking to close we they'll gap. That in turn creates its own maintenance and frustration costs.
In other words, there's no one shot. There's a good enough depending on need.
reply