5 ms·

I worked remote for most of the 90s. Wooo 9600 baud! Competency was probably the most important trait. A boss without a clue was easy to dupe and avoid, but al

I worked remote for most of the 90s. Wooo 9600 baud! Competency was probably the most important trait. A boss without a clue was easy to dupe and avoid, but also a pain when you were actually doing plenty of work. A boss that knew what was what would be on your case if you slacked, but also super relaxed if you were producing to expectations. Clear communication was also critical but it was even more important to be measured in the volume.

sida 6y ago
Can you share your stories around how working remotely in the 90s was like? e.g. there probably wasn't video chat. So how did you communicate? Were you coding? What were tooling like for coding remotely back then? etc etc
- bobbane 6y ago
  I worked as part of a distributed team from 1989-1994. I was on the US east coast, one guy was in Ohio, two guys were in California, and two were in Japan. I worked at the end of a Telebit Trailblazer, so I had a 19200 baud link to the internet. I remember emailing myself GCC - staged the tarball on a remote host, uuencoded it and sent it home as multiple email messages. We mostly did stuff via email, with the occasional conference voice call. I had to learn to restrain myself and not try to solve user problems when I first saw them - because of the distribution of time zones, I would tend to be the first person awake. This was definitely coding - we were selling and supporting Interlisp-D and its many derivatives.
- brainbag 6y ago
  Remote work in the 90s and 00s was a lot of FTP, CVS, email and IM. Long distance phone calls still cost money for much of that time too, so there wasn't much synchronous phone calls, once a week or so. Also, generally the business needs were either high enough that the staff were all expert-ish and could get done what they needed, or low enough that random Bob's cousin's nephew could build it in HoTMetaL. There wasn't a lot of in between. When I worked for other people, management spent a lot of time with requirements and specs before implementing, which often resulted in mismatched software expectations. Agile gets poo-poo'd now, but it was a revolution at the time When I was doing my own consulting, I always did my best to find local clients for remote work (often building e-commerce web sites when the competition was still using FrontPage) because it was preferable to be able to call the client or meet in person to discuss the inevitable requirements snafus. Honestly, it doesn't seem that much different now. Humans are generally not all that great at communication. The tools we have today make a dent in that problem but there's still significant unresolved challenges. When I'm leading teams, I tend to spend a lot of time on teaching people to communicate more effectively and creating processes to enable it. It makes things go more smoothly than trying to be the central hub for all communication.
PragmaticPulp 6y ago
> A boss without a clue was easy to dupe and avoid ... A boss that knew what was what would be on your case if you slacked, but also super relaxed if you were producing to expectations. Very true. We struggled with this at a past company. Most engineers were inherently honest and hard working, but maybe 1 in 5 were constantly playing games to convince their manager that they were working harder than they really were. Managers who were formerly engineers had no problem spotting this. It was the managers with non-technical backgrounds who struggled to gauge if their employees were really working hard. My workaround was to coach non-technical managers to pick up clues from the person's peers. If you privately ask 3 random team members to estimate tasks and 1 person constantly gives estimates 10x longer than anyone else, that person should be watched closely for performance issues. It also helps to group people together to finish tasks, then ask each of them how it went in private direct conversations (your schedules 1:1s). The person's honest peers will give strong hints that another person isn't pulling their weight. Trust your employees until they prove themselves untrustworthy, but be careful. We had at least one confirmed situation where a remote employee took another full-time job but didn't quit our company. Instead, they worked on doing the bare minimum to keep their manager satisfied so they could collect paychecks until we were forced to fire them. I suspect this play will become more common now that WFH is on the rise.
- mywittyname 6y ago
  Also, not all engineers who mislead their progress are doing so out of malice or laziness. Sometimes they have too much work and don't want to be the person complaining about the work load, especially if they think everyone else is managing fine. If a manage doesn't pick up on it early enough, then shit will eventually hit the fan.
- 0xffff2 6y ago
  10x is excessive, but I'd also watch closely the relationship between estimates and actual time taken. My estimates are probably 2-3x longer than they where when I first started out because I realized that I was consistently underestimating tasks. Despite being warned about it consistently in college, I still find that virtually everyone, when asked to estimate a task, gives an estimate based on the best case scenario where they encounter absolutely no issues while executing the task.
sktguha 6y ago
How did you work remotely without screen sharing and all ? I mean what if the need to something similiar to screen share arose ?
- ghaff 6y ago
  Not the 90s but I worked remotely to a significant degree in the 2000s. By and large, we did not have screen sharing although companies would present to us using tools like WebEx. Mostly we just mailed documents around, used email (with some chat latterly), and phone calls.

sida 6y ago

Can you share your stories around how working remotely in the 90s was like? e.g. there probably wasn't video chat. So how did you communicate? Were you coding? What were tooling like for coding remotely back then? etc etc

bobbane 6y ago
I worked as part of a distributed team from 1989-1994. I was on the US east coast, one guy was in Ohio, two guys were in California, and two were in Japan. I worked at the end of a Telebit Trailblazer, so I had a 19200 baud link to the internet. I remember emailing myself GCC - staged the tarball on a remote host, uuencoded it and sent it home as multiple email messages. We mostly did stuff via email, with the occasional conference voice call. I had to learn to restrain myself and not try to solve user problems when I first saw them - because of the distribution of time zones, I would tend to be the first person awake. This was definitely coding - we were selling and supporting Interlisp-D and its many derivatives.
brainbag 6y ago
Remote work in the 90s and 00s was a lot of FTP, CVS, email and IM. Long distance phone calls still cost money for much of that time too, so there wasn't much synchronous phone calls, once a week or so. Also, generally the business needs were either high enough that the staff were all expert-ish and could get done what they needed, or low enough that random Bob's cousin's nephew could build it in HoTMetaL. There wasn't a lot of in between. When I worked for other people, management spent a lot of time with requirements and specs before implementing, which often resulted in mismatched software expectations. Agile gets poo-poo'd now, but it was a revolution at the time When I was doing my own consulting, I always did my best to find local clients for remote work (often building e-commerce web sites when the competition was still using FrontPage) because it was preferable to be able to call the client or meet in person to discuss the inevitable requirements snafus. Honestly, it doesn't seem that much different now. Humans are generally not all that great at communication. The tools we have today make a dent in that problem but there's still significant unresolved challenges. When I'm leading teams, I tend to spend a lot of time on teaching people to communicate more effectively and creating processes to enable it. It makes things go more smoothly than trying to be the central hub for all communication.

PragmaticPulp 6y ago

> A boss without a clue was easy to dupe and avoid ... A boss that knew what was what would be on your case if you slacked, but also super relaxed if you were producing to expectations. Very true. We struggled with this at a past company. Most engineers were inherently honest and hard working, but maybe 1 in 5 were constantly playing games to convince their manager that they were working harder than they really were. Managers who were formerly engineers had no problem spotting this. It was the managers with non-technical backgrounds who struggled to gauge if their employees were really working hard. My workaround was to coach non-technical managers to pick up clues from the person's peers. If you privately ask 3 random team members to estimate tasks and 1 person constantly gives estimates 10x longer than anyone else, that person should be watched closely for performance issues. It also helps to group people together to finish tasks, then ask each of them how it went in private direct conversations (your schedules 1:1s). The person's honest peers will give strong hints that another person isn't pulling their weight. Trust your employees until they prove themselves untrustworthy, but be careful. We had at least one confirmed situation where a remote employee took another full-time job but didn't quit our company. Instead, they worked on doing the bare minimum to keep their manager satisfied so they could collect paychecks until we were forced to fire them. I suspect this play will become more common now that WFH is on the rise.

mywittyname 6y ago
Also, not all engineers who mislead their progress are doing so out of malice or laziness. Sometimes they have too much work and don't want to be the person complaining about the work load, especially if they think everyone else is managing fine. If a manage doesn't pick up on it early enough, then shit will eventually hit the fan.
0xffff2 6y ago
10x is excessive, but I'd also watch closely the relationship between estimates and actual time taken. My estimates are probably 2-3x longer than they where when I first started out because I realized that I was consistently underestimating tasks. Despite being warned about it consistently in college, I still find that virtually everyone, when asked to estimate a task, gives an estimate based on the best case scenario where they encounter absolutely no issues while executing the task.

sktguha 6y ago

How did you work remotely without screen sharing and all ? I mean what if the need to something similiar to screen share arose ?

ghaff 6y ago
Not the 90s but I worked remotely to a significant degree in the 2000s. By and large, we did not have screen sharing although companies would present to us using tools like WebEx. Mostly we just mailed documents around, used email (with some chat latterly), and phone calls.