4 ms·

In my opinion, no. If anything we likely only benefited the company. Our department has very low costs and those costs would have occurred whether we were on s

In my opinion, no. If anything we likely only benefited the company. Our department has very low costs and those costs would have occurred whether we were on site or not. When we were remote we used the communication tools that were already provided to the entire company. What we didn't use (benefiting the company) was electricity, water, space to occupy, network bandwidth, etc. The productivity increase of being remote resulted in apps/updates to occur much quicker. We were able to take advantage of many things we now had access to such as faster internet, IPv6, better network experiences (no more IP conflicts, blocked web sites/filtering, other IT nonsense), self managing our desktops, and so on.

nilkn 7y ago
Right, you and other developers were more productive and were able to make quicker updates. But was the company as strategically aligned at a high level? Was the engineering team as a whole able to react quickly and efficiently to strategic shifts that are more a matter of communication than coding? Were different teams able to juggle competing priorities as effectively as before? These are all elements of running the company that could be negatively impacted by remote work, and they are also areas into which many developers will not have much visibility, if any at all. To be clear, I'm not actually trying to argue against remote work in general. I think it can be done very well if the company is built around it from the bottom to the top. My point is just that one has to examine the effect on the entire organization. It might be the case that some groups benefited but at a cost that wasn't worth it at a high level. For instance, it could be that the organization needs a much more rigorous planning process rolled out to every single team before remote work becomes a net positive.
- Phillips126 7y ago
  Ah I see what you are asking. The company I work for designs, builds and sells medical devices. The software team's role is more focused on improving the workflow of other departments or building tools that help with more general company wide needs (interactive campus maps, kiosks, corporate directory applications). Example would be a tool I built for a team member that works with flex licenses (Autodesk, etc). He has a command line tool that lists how our licenses are used but it's a pretty verbose dump which isn't fun to read manually. I wrote a parser for this command and wrapped it up in a web app which provides a table of all users, charts on usage, data storing for historical metrics and so on. He is now able to better understand our usage and can more accurately guess as to when we need to purchase more licenses. He can also see what we are not using to reduce our company costs. The things we've built don't go through any "system" and are developed simply between the requester and the software team (nothing really public so far, all internal tools). As a result, our increased speed is only a positive. However, I can understand in other companies when increased code/updates would cause tons of stress on the teams so your point is valid.
  - dennisgorelik 7y ago
    > I wrote a parser for this command Were you able to effectively collect requirements for that tool while working remotely or collecting requirements required on-site interaction?
    - Phillips126 7y ago
      Yep, honestly it was almost like I never left. I used a VPN so I was almost constantly connected to our company network. At the company we don't do a lot of face-to-face meetings (typically only the older management folks here prefer that). Most of us use chat or email but I also get the occasional phone call. This project was pretty straight forward where the employee made a request and actually was able to send us the online documentation of the commands and we were able to take it from there. We built a prototype of what he was looking for and we made some minor tweaks after his initial review. We did come on-site at least once a week (sometimes more if it was needed) but they were mostly reserved for those occasional face-to-face meetings or when we were setting up a BLE Mesh Network for workorder tracking.

nilkn 7y ago

Right, you and other developers were more productive and were able to make quicker updates. But was the company as strategically aligned at a high level? Was the engineering team as a whole able to react quickly and efficiently to strategic shifts that are more a matter of communication than coding? Were different teams able to juggle competing priorities as effectively as before? These are all elements of running the company that could be negatively impacted by remote work, and they are also areas into which many developers will not have much visibility, if any at all. To be clear, I'm not actually trying to argue against remote work in general. I think it can be done very well if the company is built around it from the bottom to the top. My point is just that one has to examine the effect on the entire organization. It might be the case that some groups benefited but at a cost that wasn't worth it at a high level. For instance, it could be that the organization needs a much more rigorous planning process rolled out to every single team before remote work becomes a net positive.

Phillips126 7y ago
Ah I see what you are asking. The company I work for designs, builds and sells medical devices. The software team's role is more focused on improving the workflow of other departments or building tools that help with more general company wide needs (interactive campus maps, kiosks, corporate directory applications). Example would be a tool I built for a team member that works with flex licenses (Autodesk, etc). He has a command line tool that lists how our licenses are used but it's a pretty verbose dump which isn't fun to read manually. I wrote a parser for this command and wrapped it up in a web app which provides a table of all users, charts on usage, data storing for historical metrics and so on. He is now able to better understand our usage and can more accurately guess as to when we need to purchase more licenses. He can also see what we are not using to reduce our company costs. The things we've built don't go through any "system" and are developed simply between the requester and the software team (nothing really public so far, all internal tools). As a result, our increased speed is only a positive. However, I can understand in other companies when increased code/updates would cause tons of stress on the teams so your point is valid.
- dennisgorelik 7y ago
  > I wrote a parser for this command Were you able to effectively collect requirements for that tool while working remotely or collecting requirements required on-site interaction?
  - Phillips126 7y ago
    Yep, honestly it was almost like I never left. I used a VPN so I was almost constantly connected to our company network. At the company we don't do a lot of face-to-face meetings (typically only the older management folks here prefer that). Most of us use chat or email but I also get the occasional phone call. This project was pretty straight forward where the employee made a request and actually was able to send us the online documentation of the commands and we were able to take it from there. We built a prototype of what he was looking for and we made some minor tweaks after his initial review. We did come on-site at least once a week (sometimes more if it was needed) but they were mostly reserved for those occasional face-to-face meetings or when we were setting up a BLE Mesh Network for workorder tracking.