When remote work doesn't cut it
samkhawase.com
samkhawase.com
I.e. I do know of embedded projects where the hardware designer works out of his living room and the software developers are spread across Europe. Does that count? Or doesn't it because the PCB fab and assembly service obviously works out of a factory? It certainly is remote as far as the developers are concerned - and it wouldn't work as well if the device in question didn't easily fit on a desk (although you can do a lot with only remote access to hardware too in later stages).
Somehow embedded developers often tend to (understandably) bemoan that the overall "software community" doesn't understand their work, while at the same time falling into the same trap regarding the breadth of what embedded development is today vs their individual experience.
We had to run the hardware lab with strict quotas in the middle of the raging pandemic, because the critical equipment can't be moved. I had to personally go to office several times to use the jigs to use special test devices, I can't even imagine our remote developers in Poland/Ukraine traveling to Berlin just to work on the experimental devices.
Also a lot of people are overlooking the compliance issue. Several of the projects under TISAX need a sealed working environment where access is restricted even for the same company people. Good luck porting that compliance to a home office.
Or you might not even have access to that room.
We just haven't had much motivation to do this for a more general class of hardware, and there probably haven't been enough non-pandemic motivators to build such things, and it would be pretty macabre to build a system just in case there's another pandemic, or to buy the thing if it existed.
Time sharing hardware with someone on the other side of the planet, for instance, might introduce too much delay for a Big Red Button. Apparently it's about .25 seconds if you're in the room. You can do a lot more damage in another 200 ms, and packet loss could make that delay bigger.
It is more feasible to ensure no such failures the simpler the device is, e.g. with a good hardware watchdog setup. We did it with a rather complex stack.
Seeing that now with Covid at customer sites: only 1-2 people from a larger group in the office, who if needed can go poke devices, while the majority works remotely (which often includes contractors that otherwise would be in hotels etc). Generally not optimal, since many don't have the amount of automation one would prefer, but workable and with room for improvement.
The thing though is you still need physical space for integration but a lot of the developed can be fully remote.
First, write the programs that set flags, work with IO, branch and jump, fault and recover, and so on. Stick in comments as appropriate that read eg. "Now move from PR1:Home to PR17:Infeed Magazine 2, approaching with the offsets from PR101".
We typically implement some sort of 'dry cycle' mode, where we don't actually check for part presence/energize vacuum generators/spool out wire/spray paint, so you can check for intermittent mechanical problems, loose wires or fasteners, etc. When starting development in this way, it's a sort of anhydrous or dessicated cycle, without any motion whatsoever!
When the robots finally arrive or when you actually go into the shop, only then should you need to move stuff. A benefit is also that you should have a much better idea of precisely where and in what sequence you need to move it, not just the RFQ's description of "the robot does some stuff and assembles the part".
From the article:
>Not every company is a FAANG, and companies will struggle to transition given their limited resources.
There are a couple of options:
1) There are a lot of accounting/law/etc firms willing to setup a local subsidiary for you and do all the necessary paperwork and book-keeping. All you have to do is pay them $$$ and sign the stuff they send you. They'll tell you when to have board meetings and spoon-feed you the resolutions the directors need to pass, etc (e.g. in some jurisdictions the directors need to review the accounts once a year and pass a resolution saying the business is still solvent – so long as the parent company is guaranteeing the subsidiary, this turns into a pro forma exercise, since the subsidiary will rely on the parent company's guarantee to ensure its own solvency)
2) There are firms (e.g. Gitlab uses Safeguard and Remote) which will employ people for you in another country. You just pay them $$$ and they legally employ the employees and look after tax/benefits/etc. Technically they are contractors who are employees of this agency but you can treat them like employees.
Now, both options can be expensive. (Option 2 may be cheaper for a small number of employees, soon option 1 will become cheaper.) But, it is really a question – if it costs $X extra to employ person Y in country Z, is person Y worth paying $X extra for?
Then the worker takes responsibility for their own work visa, employer's payroll taxes, social security and medical insurance. It is still possible for the hiring company to provide IT equipment and even offer stock options, or other bonuses.
In practice, the worker might actually be living in Country Z.
The discussion is about non-FAANGs here. In my experience this isn't always the case and companies aren't always willing to do so just to hire a remote talent. I personally know someone who was hired for a US based company in Berlin, and when he was laid off, he had to spend few thousand €s from his own pocket to take care of the legal stuff for closing the company.
I understand remote work is the future, but we can't brush stuff under the carpet and say everything is hunky-dory.
Some other countries do not have this problem, because, for example, dividends are not (double) taxed at source, and people pay the same income tax rate on their total income, earned and non-earned (interest, dividends).
Ahh, that I didn't know. Even if they are employed by their own consultancy firm?
> The smaller non-FAANG companies/startup might lose quality remote talent due to this.
That sounds like a business opportunity where some SaaS could take a percentage and handle local tax and reporting obligations.
When I worked on embedded, we had to take boards down to the lab to get rewired/modified not too infrequently. All of the preproduction boards that ever came in straight from the factory needed reworking, and being able to change things 'as needed' was super useful. Having someone sitting in the next office over with an oscilloscope to help debug strange issues on a bus was useful.
Embedded is one of those fields where it really is an entire team with distinct, but overlapping, skills all working together. One of the MEs can do some EE, some of the EEs can code, some of the software engineers can do EE work and assembly, a few of the UI people know how to do assembly and C++, some of the C++ people know how to work with design and marketing, and if everyone works together a product ships out the door.
Could it be done remotely? Sure, but productivity would take a huge drop.
Internet protocol is huge and unweildy, but since you can buy standard components and install free software to handle it, it gains another huge advantage over the "100 serial protocols" world of yesteryear.
Where this might become difficult is when embedded projects try to re-invent the wheel instead of just using existing code for these things.
I was on an embedded project a few years ago that had this problem -- the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful (proprietary modified version of C compiler), and thus were going to have to implement an entire network stack just to be able to talk to an API server. We ditched their approach and went with a board that could run Rust and the rest was easy.
>the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful
You said it was unlikely, but then described how it happens. The reflex of many embedded devs is not to use big processors running standard software speaking standard protocols. IoT represents people realizing that there are many applications where it's a good idea to use a $20 board and standard software to do something that could technically be accomplished by a $0.02 chip and 100 different serial protocols.
https://jaycarlson.net/embedded-linux/
In summary, if you can't have your IoT device plugged into the wall, or connected by a "crazy" 802.15.4 low-power serial wireless network to a hub device that is, and especially if you have BOM cost constraints, battery life requirements, or processing needs that mean you can't use Linux or lwIP, you're going to have a bad time.
Lots of chips have proprietary compilers. Something as simple as an MSP430 fits that description, which would probably be a choice driven by battery life requirements.
I'm sure you checked with the embedded devs before you "ditched" their "crazy" approach, but did they have any reasons behind it?
Aerospace, automotive, automation and self driving, oil and gas, power... all of those employ thousands of embedded engineers. Saying the nav systems for a plane, a satellite, an electric car of a self driving system are "IoT" only because they have a network connection and you can pull and push stuff to them from the Internet is a a stretch.
There's also a lot of consumer electronics that are not IoT, like peripheral software for laptops and consoles, appliances, audio, musical instruments, toys, displays and signage, etc...
1. “Cross-Nation employment laws and Regulations are hard. “ Yep. You end up not employing people from incompatible places.
2. “It’s hard to do projects that require access to unique equipment.” Yep, these people don’t have remote jobs. Just like a gas attendant or a barber doesn’t.
3. “Communication and Focus is harder.” Yep. I posit that this is you reflecting a desire to mimic the same patterns you enjoyed from the office. That stuff is hard when remote, and for some people it’s just impossible. Those people probably also don’t have remote friendly careers, and that’s ok.
I used to have a wireless router in the shop so I could do development from my office with its desk, monitors, keyboard, and chair. Now that router also runs OpenVPN so I can do the same from home.
It's only the non-technical staff that think workers have to be warming seats and shifting steel to be getting work done. A huge amount of building those machines is spreadsheet wrangling and rote business logic connecting inputs to outputs, which is more effective when working remotely than on-location.
I find this highly unlikely in the age of 3D printers, autocad, and readily available tinkering tools.
Before I moved out of Cambridge, I used to frequent the local Makerspace, which at the time had two laser cutters and a selection of 3D printers. One of the rules for using the laser cutters was to keep an eye on them at all times, and to never leave them unattended — I believe the fear was something might catch fire, or someone might use a material without realising it contained chlorine, or something like that.
The printers needed frequent attention, and while they could be left running overnight, there was a 50% chance they’d have failed by the time you returned.
At the same time though, I highly doubt many companies in the future will go 100% WFH, so all these discussions seem rather academic to me. I feel like the people that want to work from home will get more opportunity to do so, and the people that don't, won't have to. Easy.
Yes, most of the multi-country issues could be resolved (obviously, there are plenty of multinationals that do), but there is a not insignificant amount of money, effort, politics, and coordination involved with most of them.
I’m looking forward to using this with coworkers who keep insisting that in-person is better because they work with people who are shit at communication.
Anecdote from current job: UK citizen living and working in US for a Swedish company on a h/w project that I need physical access too. H/W is made by a Chinese company. Project leads are situated all across the world in multiple time zones. Other parts of the software development is spread across Eastern Europe.
Anecdote from last job: Building software in a team of thousands spread all around the world across every time zone imaginable needing access to remote systems, physical hardware and thousands of sensors on a floating ship thousands of miles away with a crappy satellite connection.
Conclusion: "I don't understand how the other half lives, therefore it is impossible."
There are certain subsets of software development that need to be hands on. Many don't.
And to address the "lack of discipline" in the article: That's your problem.
To address the hiring of foreign nationals and local labour laws: There are literally companies that exist solely for that purpose. I've used two of those companies in the past for our own teams to hire a foreign national as an employee that works remotely. A cursory web search will throw up dozens of companies that specialize in just that. Those companies have registered offices all across the world. You're hired to that company locally and fulfill all local employment laws for only a marginal amount of overhead.
Bad article is bad.
Remote work doesn't have to mean multi-country workforce. It can be same country, same state or even same state within 1-2 hrs driving distance. There is a lot of talk about in the office once or twice a week.
As far as social cues that you can only pick up in person. I haven't struggled with this at all. I'm not sure if that means I miss those cues in person so I'm not noticing or I'm capable of picking them up on a video call. Could it be possible that those cues are not actually that important?
I do feel bad for my single friends who live alone. During the pandemic they have been very isolated and very lonely. I understand that an office environment might have been more enjoyable for them. However, from a business perspective, perhaps there are better alternatives to solve this problem than require everyone to come into the office and sit on site 5 days a week. I actually think this will say more about how people chose to dwell then how the office space should work.
I just hope I don't get too confident and end up in trouble...
2. Just ship it. Most likely the boards came from a third party manufacturer anyways.
The first few points mention that not every company is a FAANG, and companies have limited resources, but then goes to address global presence which is most likely the case for multinationals. Again, for context: we're a tiny team that just happens to have people in a few cities because we told people to go wherever they want to.
Second, it addresses laws against unlawful termination. Unlawful termination, whether remotely or not, still is unlawful.
Payroll taxes would still have to be paid. If it's not remote work, then you'd have to attract talent to wherever you are. If you're a global company, you most likely have subsidiaires. Not saying it doesn't add complexity, just saying that for different modes there are different problems.
The 'law' states that the software economy, not the economy, is bigger than you think.
We also happens to have developed an 'IoT', read a device that talks to a device, which is how the plain internet worked before a guy who has been sleeping for years woke up with an idea he thought original of "what if like, things could like send information to like other things.. Whoaaa".
>The biggest hurdle employees face in remote/home offices is lack of focus and direction.
Not new or proper to remote work. It used to be called bad management. Goes on about it and all these can be not only overcome, but leveraged if one runs a tighter ship.
The question then becomes: how does management get their shit together after all those 'leadership' seminars and workshops they attended. Ready, steady, lead.
How we've done it: about two years ago, I got a bit paranoid about the fact we relied too much on people being present for work to be done, and was bothered seeing the team suffer commute at least 4 hours daily. We started experimenting with different schemes, sometimes working a full week remotely, seeing what 'broke', and addressing that. We wanted to get over the mistakes while we could afford it, and we wanted to be able to hire elsewhere after we had learned these lessons. The idea was to expose the crutches we relied on to get work done. For example, peculiarities in the code you tell your team over coffee about is a hidden crutch, because you unknowingly assume that the team is there and that you can address everyone. Working remotely for a few days exposes that because your colleagues hit that problem and you didn't tell them. Which means you have to document things, and institutionalize knowledge. I know it's a big word, but when you join a company and a year later the co-founder and CTO resigns without notice, you learn your lesson and establish processes so that if you disappear or are not in the capacity to help the team, there is enough knowledge to go by[0]. So the first few days, everything I did was documented in a git versioned handbook. I went so far as to document with pictures how to fill a cheque for taxes, what to write, where to sign, where to pay with a picture of the building, its GPS location, what floor. It was called an "Operator's Manual" so that anyone could take it and operate this. We have hired for that role later, and we just handed that person the manual so we could focus on other things.
Everything went there. Our corporate clients, addresses, points of contact. I didn't want anyone to go over a crappy handover if I wasn't there.
Things aren't always the way we want them to be.