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.
The caveat on (2) though is that you _can_ do R&D entirely remotely these days except in industries that require very large equipment that you couldn't set up at someone's house or home office. And in those industries, a lot of the R&D is done in autocad or virtualized environments anyway. Prototyping similarly has been revolutionized by 3D printing.
I work in industrial automation, with CNCs, robots, HMIs, and PLCs that have huge price tags and footprints. Yes, you'll eventually have to be on site to integrate the equipment, and making anything actually move while not on-site is a big no-no, but between a little simulation, a VPN, and maybe a controller, good development practices make it easy to work remotely. Also, all our machines for several years now have included industrial VPN appliances so we can do remote support and updates - an Ewon Cosy is way cheaper than even an engineer's airline ticket - we just use them a little earlier now.
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.
IoT is just the sexy name for embedded, and folks have been doing embedded remotely for a long time. You need someone local to set things up (just like you need on-prem IT folks to deal with equipment), but for 95% of the use cases, you can set up simulators, cameras, and remote access equipment to develop embedded software.
IoT is embedded plus an internet connection. The internet connection is sometimes a big deal that changes a lot. There have been "run the wire from A to B" networks of controllers since forever, but with an internet connection the number of links grows as N instead of N^2, and you can connect to nodes around the world with no additional cost. For some applications, that's hugely significant.
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.
I read this as "embedded devs don't know how to consume REST APIs", and I also found it unlikely.
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.
>I read this as "embedded devs don't know how to consume REST APIs", and I also found it unlikely.
>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.
There was a great primer on embedded Linux boards by Jay Carlson a couple weeks ago that touched on the network limitations and various tradeoffs that devices in this class need to make:
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.
> the real-time/embedded devs wanted to use some crazy board that couldn't run anything useful (proprietary modified version of C compiler)
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?
For them it was a matter of preference. The board they selected was priced similarly to the pi zero, but they were afraid of making things too easy I guess ;)
> IoT is just the sexy name for embedded, and folks have been doing embedded remotely for a long time.
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.
IoT is only a part of embedded, and no it's not anything with a micro-controller and an internet connection.
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...
> My current project is an IoT device that talks to an iPad app. The hardware team needs specialized tools to work on the IoT device, and these tools can’t be moved to home office. Remote work is a strict no-no for such products.
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.
A professional hardware lab will have multi-thousand-dollar multimeters, oscilloscopes, wave generators, power supplies, etc. Sure, you can buy $30 alternatives, but they're obviously nowhere near as good.
1. You can circumvent most of that by hiring the international remote person as a contractor or by having him incorporate himself as a consultancy firm and then buy consultancy services from him. It also becomes trivial to fire (don't renew the contract!)
2. Just ship it. Most likely the boards came from a third party manufacturer anyways.
For the "rudderless" and "self discipline is hard" parts, that is one reason I am glad our team is doing Agile/Scrum. Just the daily stand ups give you enough accountability to have a goal to shoot for.
This article makes no sense. It's someone who has no idea at all asking extremely superficial questions. How do companies from country X operate in other country Y? They setup a local company in country Y wholly owned by the parent. Suddenly, all of the FUD around "how will this ever work across borders!" in this article goes away.
But that's an argument about having remote workers in other countries, not necessarily about remote work in general. Allowing remote workers would greatly expand the available resources a company could choose from within their own country.
> but "is it worth it" for smaller companies to have workers in other countries
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?
> They setup a local company in country Y wholly owned by the parent.
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.
You can circumvent most of that by hiring the international remote person as a contractor or by having him incorporate himself as a consultancy firm and then buy consultancy services from him. It also becomes trivial to fire (don't renew the contract!)
Most people here in EU would prefer to have a permanent work contract instead of having to jump through the hoops.
Also contracting is a different ball game in many countries. E.g. in Germany the Tax office mandates that the contractor should have more than one customer per tax year. This would make it a hassle for a German software engineer to work for a UK company, who would rather work locally. The smaller non-FAANG companies/startup might lose quality remote talent due to this.
IANAL, but AFAIU this will violate labor laws in many countries. For example in the UK, if you are a contractor that only works for one employer all year, you are considered an employee. And if the company does not pay tax to the UK it is in violation of labor law.
But only an employee for tax purposes (IR35), i.e. you cannot get a tax benefit by paying yourself a minimal salary (just enough for NI social security qualification) and taking the rest in dividends from your company at a lower tax rate. It is still a contract position in other respects, such as termination (contract law applies, not employment law).
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).
No, they usually expect the worker to set up a local company in Country Y, and hire the worker as a contractor through their own company.
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 article is full of contradictions. For context, we're not a FAANG, we have limited resources, but we have been way more productive remotely as a team.
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.
Just want to clarify a mistake in the article: USA does not have two weeks notice for termination. This is per contract basis and based on culture, but it is not a regulation.
Sure, but the way the sentence is written make it believe that the Europeans average of three months is equivalent to the US average of two weeks.
The former is an average of regulations, the later an average of folklore.
As a robotics engineer, I'm surprised how controversial "hardware can't remote" is turning out to be. Sure, some things can be done fully in simulation or by mailing everyone on the perception team a bunch of sensors. However, existing/popular simulators aren't that good at simulating things like odometry error, and if you're trying to do any object manipulation they're not great at anything beyond "before I run this on the robot, please make sure I'm not going to destroy things" (my understanding is that accurately simulating manipulation is hard because of the various frictional forces involved). And, of course, giving several employees a large, expensive KUKA arm to keep in their house or apartment is impractical on many levels. If people are running code remotely on a physical robot that's in the office, at least one person has to be in the office to keep an eye on it (for safety, and freeing the robot if it gets stuck). This is also not even getting into remote embedded, electrical, or mechanical work -- everything I've listed would affect a garden-variety software developer. So, yeah, I'll endorse "hardware can't remote", and will admit to some frustration with non-hardware-adjacent software engineers, who have a tendency to make over-broad generalizations about the feasibility of remote work.
Always the problem with absolutes. It highly depends on the project and what you look at. I wouldn't sign "hardware can never be remote", but I also think "hardware always can be done remotely" is very wrong. And that leaves out the massive space of hybrid models.
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.
My team deployed lots of stuff on Kuka robots from across the world using a VPN with remote pendant software and few PTZ cameras around the robotic cell. It can be done.
The thing though is you still need physical space for integration but a lot of the developed can be fully remote.
I've developed a lot of stuff for Fanucs with a similar setup, minus the cameras. A relatively small amount of the work is actually getting in the cell with the pendant and teaching the position registers. A large amount is structuring your programs, writing interprocess communication, setting up inter-machine communication, fault handling, zone exclusions, process monitoring, manual overrides, dry cycle controls, etc. etc. etc.
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".
We had enough problems with "hardware can't remote" with server equipment that they made systems to control them. Those systems are useful even if you're in the same building and just don't want to go hang out in the cold, loud server room while you figure out the problem, and everyone wonders if you're even working today (since they can't see you).
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.
Testing is one field where you already might see fairly automated unsupervised/remote setups that are not that difficult to use for remote development too, although surprisingly often testing is still done manually.
We had some experience with this, and the device under test or even testing harness can fail, so you need a local operator to fix things anyway.
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.
Of course, you also need someone and somewhere to set it up in the first place after all, but it makes a big difference between "you need the entire team in one place" vs "you need a place that has a test engineer or one member of the team available/on-call". (To continue the parallel from /u/hinkleys comment, lights-out management is useful even though the server still can't swap a broken disk itself)
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.
Touché. People on HN are sometimes really flippant about the lesser discussed segments of software industry.
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.
I know I for one will be going back to the office as soon as possible. However, that's more due to the fact that working from home does not fit with the way I want to live, rather than any actual logistical hurdle.
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.
Mathematics is very annoying to do remotely. If a bunch of people cannot physically gather around the same blackboard and point to the drawings, something fundamental is missing.
I thought I was going to hate this article, but I was pleasantly surprised. It’s very logical and practical.
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.
Sure… so remote work doesn't work for some jobs for some companies. Remote work doesn't work for sandwich artists or mechanics. However, there are so many jobs that do not require you to physically interact with anything other than your computer. Not just software engineering jobs. This doesn't mean that none of the hardware jobs can't be remote, just the ones that requires regular interaction with tools that cannot be shipped to engineers. Consider how much money companies save by not paying rent for large office space. If that money is redirected to making sure their remote employees can upgrade their workspace and send the necessary tools, then many of these can still work out.
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.
Social cues aren't lost on me, but I don't miss them. I've found that it's been way easier for me to speak my mind when I don't have an audience looking at me. Huge increase in confidence. I even asked for a promotion a few weeks ago, something I've never had the courage to do in person.
I just hope I don't get too confident and end up in trouble...
Disclaimer: The world is a lot more complex than you or I can imagine, and there are many variables that go in an environment that neither of us are aware of.
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.
49 comments
[ 2.4 ms ] story [ 75.9 ms ] thread1. “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.
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?
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.
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...
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.
2. Just ship it. Most likely the boards came from a third party manufacturer anyways.
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?
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.
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.
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).
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 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.
- [0]: https://news.ycombinator.com/item?id=25025253
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.
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".
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.
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.
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.
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...
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.