edmundhuber

Paradromics | Embedded Software Engineer | Austin, TX or Oakland, CA | Onsite | Full-time

Paradromics is building a high bandwidth brain-machine interface for clinical use. The implant we built is restoring function to patients by streaming out neural data from specific brain regions in real time, which we convert to e.g. speech using machine learning. Check out our recent article in the NYT: https://archive.ph/C6CRb .

We're looking for help in further developing and hardening our embedded Linux components, which work in tandem with FPGAs and our custom ASICs to read out neural data. Some of the ongoing efforts are: HIL testing on real devices, integrating new sensor ASICs, maintaining our Yocto build system, exploratory work on prototypes, improving our clinical UX, and improving the core code that receives and massages data. The code is largely written in Rust with a little Typescript, (and bash, and bitbake recipes, etc).

You'll be expected to have experience constructing reliable and understandable software in Linux, and some level of experience in building and interacting with embedded hardware. Rust experience is ideal but not necessary. We're not looking for a specific number of YoE, but for motivated and hungry engineers who want to push the frontier of brain-machine interfaces.

To apply visit https://paradromicsinc.applytojob.com/apply/u5hXN4N9ID/Embed... or email your resume and a little about yourself to me, ehuber@paradromics.com . I'll be glad to hear from you!

Often tastes better too, tbh. Lots of restaurants overuse salt to make up for lack of flavor.

I quit everything but Reddit (which I pretty much only lurk in, and only do hobby talk) and LinkedIn (until I strike it rich, I still gotta have a job). It's been excellent since I no longer waste my time being angry about things I can't change, or seeking attention or approval. Obviously some people can cope with the demands of social media more than others, but it didn't work for me, and I think, like me, a lot of people are putting themselves through unnecessary pain to stick to a platform which actually brings little or no value to themselves. In short, fuck social media.

In the US, our bureaucracies seem to attract some of the least intelligent people who have no interest in improving their institutions, just in riding the gravy train forever. I think that this is an outcome of how we treat all bureaucrats as equal. There are no entrance exams, or university -level courses for being a bureaucrat. There's no national standard. There's no pride or recognition in being a good bureaucrat, and few if any consequences of being a mediocre one. IMO it seems like a problem with what the US views is the acceptable structure of government, with many overlapping state and federal agencies and endless finger-pointing. There's rarely a "the buck stops here" moment, and so no need to ever improve. If you're familiar with the bozo theory, basically the entire bureaucracy is already full of bozos and thus irredeemable.

Circa a few years ago (maybe their obscurity scheme has improved since then), they just used a binary blob that decrypted the (Ruby) source then passed it to a Ruby interpreter process. If you replaced your Ruby interpreter with one that would also print the source, you had all the code. :P

It basically sounds like "n*gga" when said fast.

Depends on what you mean by self-flying, which is why I pointed out that BI probably has different ideas than Airbus.

To most people (and BI?) it will mean "taxi, takeoff, navigating/obstacle avoidance, landing". To the extent that driving a car isn't "what you see is what you get", flight is much worse.

In the simplest case of flight, you are in cruise (neither takeoff nor landing), and depending on what kind of airspace you're in you may need to: * listen to ATC for commands, and advise them of what you're doing, * avoid weather, * look out for traffic, * watch your gauges, * stay on a heading, altitude, and generally fly the plane. (This part is routinely done with autopilot.)

In short, if it seems easier, it's because pilots make it look so casual.

A thing they teach pilots is: "Aviate, Navigate, Communicate". This is the basic priorities for your attention. If you're pointed at terrain your priority is to fix that first. The point of autopilot today is to free you (to some extent) of that first responsibility, especially during routine parts of flight, so that you can do the other things. Airbus is looking for more things to automate to let pilots do more strategic thinking in general.

Contrast this with a car, which is probably more in line with what BI is thinking. The kinetic energies are much lower, there's no need to communicate, the rules for driving are pretty straightforward (get to where you want to be, without hitting other people, while respecting traffic lights and speed limits), and to top it all off, if the AI feels that it's in over its head than the car can just stop whenever and everyone can climb out of the vehicle.

Link to Airbus's press release: https://www.airbus.com/newsroom/press-releases/en/2020/06/ai... More info here: https://www.airbus.com/newsroom/stories/autonomy-aerial-mobi...

Airbus has an "innovation" (R&D) department and they're looking into more ways to have computers do the routine parts of flight.

Airbus's materials (linked) do mention "self-piloting", but I can't imagine that they are thinking of the scale as BusinessInsider is when they write "self-flying". No one's proposing getting rid of pilots, having a computer fly a plane completely would be insanity.

> The 737 MAX fiasco shows that Boeing still hasn't caught up with what Airbus was doing in the 1980s.

The Air France 447 accident demonstrated to me that Airbus hadn't really thought things through either. Pilots entered conflicting inputs and the plane averaged them out instead of giving (good, actionable) feedback.

Side question: is fly-by-wire an obviously good idea for passenger airplanes? It's ubiquitous in e.g. fighter jets because of the inherent aerodynamic instability of those platforms, making them hard or impossible ("Hopeless diamond") to fly without computer assistance. Passenger jets have different goals and are built to have stable flight -- the plane wants to fly level. My takeaway from Air France 447 was that I want more Boeing-style (linked, mechanical) controls in passenger airplanes than I want fly-by-wire. Am I off base?

Counterpoint: I've spent a total of an hour (ish) futzing around with my Debian install, for my home/hobby laptop. I feel like my work (OSX) laptop gives me much more to do, but that could be because I'm expecting more of it. My Linux workstation(s) require basically 0 maintenance.

For me, writing a thing down gives me the option to forget it. People are different I suppose.

Have you tried journaling? It lets you get ideas out (adding or remixing ideas from the previous days), without investing in getting a project up, writing code, etc. A lot of times, for me, I just want to explore an idea and I'm not actually interested in working through it. But if I spend enough days journaling an idea and I'm still interested in it, then I go for it.

The other thing that's helped me is realizing that anything worthwhile is hard. If you want to stick with a project until it's done, you're going to get bored, you're going to run into roadblocks, and you want to cultivate a sense of "this is what I want to do, and that is just a temporary issue that I will work through".

Last thing that's helped me is finding a support group. I use irc, specifically I hang out on irc.darwin.network (shameless plug, I kinda co-run it), there I can chat with people about what I'm working on, they can ask cool questions, etc, keeps the juices flowing and reminds me why a project is worth sticking to.

Cisco-Meraki | Bringup/platform engineeer(s) | SF or SJ, CA | Full-time

Meraki makes easy-to-manage cloud-connected APs, cameras, security devices, cellular gateways, (more to come!).

I'm looking for engineers who are comfortable in the kernel and device drivers, and who have a passion for making complete and stable products. Drop me a line at edmund.huber@meraki.net if you're interested!

If a system is not documented in terms of what it does, how it does it, and common remediations for when things go wrong, then it's a fragile system depending on one person to keep it going.

You need to get (particularly, senior) engineers to buy into the mindset of documenting everything and making the documentation the first place to look (not after all else fails). Leads should hold be held accountable for their docs meeting some standard of "this is a useful doc".

If I were in your shoes I'd get senior engineers in a room and be honest with them about the situation. You're going to need them to do work that they might not be naturally inclined to do, or work that might not seem like a "productive" use of time. You might want to get them to agree on what a good doc looks like (the standard), and what things need to be documented. Maybe take a whole day to do this, with snacks and coffee. Good luck!

You shouldn't feel bad about this, you might have saved someone from a lifetime of fixing wacky science bugs in exchange for not a lot of money.

The flying car designs I've seen have no true redundancies. They look like they would be dangerously unstable if they tried to run on fewer than all motors.

What are those things that you need to duplicate?

Are there examples of flat organizations that have to meet make-or-break deadlines? I'm a little skeptical of a flat org's ability to hold itself accountable to externally-imposed deadlines/requirements/etc.

Yes. I co-run a small, quirky IRC network/channel. We welcome all peoples who enjoy fun and discussing programming/hardware/technical stuff. Details here https://irc.darwin.network/

I'd love to know more.

They won't let you have the procedure if you attempt to alter the agreement. I've tried!

For those wondering, the biggest differentiator of this from PICO-8 is that this is open-source and PICO-8 is not.

I play a ton of SC2 and he is mostly right.

Great article, and it sounds like it took a pretty big leap of faith to go from heuristics to cost-based optimization. If this was addressed in the article I apologize: do you only ever select transformations that yield equivalent results, with immediately lower cost, or do you also explore transformations that incur in immediate cost increase, but then later pay off? i.e. are you doing simple hill climbing, or something more interesting?

I agree that most code review change requests are style-related.

One reason I can think of this happening is that in order for one's brain to focus on just the parts of the CR that matter, stylistic oddities need to be sorted out. Ideally after some time, a reviewee would stop opening PRs that contradict the basic stylistic standards that the group adheres to (and thus stop wasting everyone's time). Ideally there would also be a linter to get everyone to that point as quickly as possible.

Imagine if you were running an assembly line, and every person in every shift did their welds significantly differently. It would be a waste of time for the inspection workers to have to continuously remind everyone that it's hard to check quality on a variety of different welding methods, rather than just one or two. It would be a better use of everyone's time to just agree on what kinds of welds are acceptable.

To throw in dissenting opinion: I feel like that gets the point across to C programmers like me.

No one has mentioned groups chats from the article. It's kind of scary to think there's a manager out there that is mindfully siloing conversations instead of letting smart people figure it out.

I think it depends on what the CEO is really hiring you to do. Is it to turn this team around, so that it can take on projects in the future without stalling out? Is it to finish the project in as quickly as possible? I would recommend talking to the CEO first to figure out exactly what he's expecting from you, especially given that it's a hierarchy-oriented team/culture.

In my (and others', from reading other comments) experience, it is pretty unrealistic to swoop in and fix everything at once. You need to establish what you are being asked to do, and then make a reasonable step by step plan. Changing attitudes about software development is very difficult and you need to have a plan.

"If it ain't broke don't fix it" is absolutely a strawman, I agree. The point is to seed a discussion.

A lot of these things that you're pointing out are pretty vague. To pick apart one: "devops", it can mean "using docker", and/or "continuous deployment of configs", and/or "greater developer empowerment", and/or "no dedicated infrastructure team", etc.

IMO, attacking all of "devops" (or "agile", or "cloud computing") at once is not productive, because it means so many things. So if you don't get specific, as others have said, it makes you seem like you just oppose new things.

For example with devops, a very rational concern is that if the infrastructure team shrinks or disappears, then there's no one on the hook for making things all work at the same time. If you leave it to the developers of each team to make their thing work, you are likely to have a continually broken development environment.

A good argument to oppose any change without a clear rationale for the change occurring is "if it ain't broke don't fix it." This, at least, leads to someone explaining why change is necessary, and then from there perhaps you can have a conversation.