One that knocked me upside the head once was, upon remarking "That's going to take a long time, like a year" to accomplish something, as if that made it not worth doing, being told, "That time is going to pass anyway." In other words, you can either start working towards it now, and be in a better place in a year, or let that length of time discourage you and then, when next year rolls around, still be discouraged. So just start.
Back in the 1990s, when I was a software engineer at a database company in the Bay Area (rhymed with "PsyBass", if you pronounce "bass" as a musical instrument :), there was a joke among some of the architects along the lines of, "I DREW the boxes and arrows! If you can't implement it, that's you're fault!" Now, as a "software architect" in a really, really small shop, I basically just try and lead by example, and make sure my ideas work as code before inflicting them on anyone else. But that sorta sounds like keeping it all to myself until I am sure it works, per the article. I like to document (more than most), but have found over the years the only person who reads my documentation tends to be me. So writing docs or writing code, either way, tends to help me refine my ideas.
I tried the advanced summarizer and got the lines below. Seems to me it skips summarizing beyond a certain length of the article.
Most people have had mild to moderate illness and recovered, but the virus is more serious for those who are older or have other health problems.
The risk of virus transmission from food servers is the same risk as transmission from other infected people, but “one of the concerns in that food servers, like others facing stark choices about insurance and paychecks, may be pressured to work even if they are sick,” she said.
Tests have found high amounts of virus in the throats and noses of people a couple days before they show symptoms.
Flu kills about 0.1% of those it infects, so the new virus seems about 10 times more lethal, the National Institutes of Health’s Dr. Anthony Fauci told Congress last week.
The death rate has been higher among people with other health problems -- more than 10% for those with heart disease, for example.
If the Basic Summarizer is meant to convince me to sign up for the Advanced Summarizer, that's not gonna happen with the former providing unconvincing results.
I worked from home full-time from 1996-2000, part-time from 2000-2005. My main advice would be, "Learn how to go home at night." In other words, if you have an actual home office, close the office door and "commute" home, and leave work behind you. If you don't have a home office, close the laptop instead, again thinking, "I am now commuting home." After reveling in the fact you now have a two-second commute, go do what you do every evening after you get home (presuming you don't just drudge away some more after you get home).
Whatever you do, especially if you work for a global company like I did, don't check email right before bed! Otherwise you will get sucked into this - https://www.xkcd.com/386/ - and won't be able to go to sleep.
In fact, it was after one of those episodes, bored with TV so casually checking email and exclaiming, "How could those engineers in [some city six time zones away] be so dumb?!?! I must stop them before we lose all of tomorrow cleaning up what they're doing!!!", that I instituted the "commute home and leave it behind you" rule. Because it was fine - they weren't dumb, I was misunderstanding something, but the resulting email flurry back and forth got me worked up to the point of not being able to sleep. So I lost all the next day due to bad productivity anyway.
I am old (I have seen things). I still have my first program from college, in FORTRAN, on a card deck. I also worked as a "computer operator" (an extinct species) while going to college, putting card decks in the readers, running decks that were output from the punches through "interpreters" (which printed the characters across the top of cards), and remembering that you always (ALWAYS) drew a diagonal line across the top of a deck of cards with a pen, in case you dropped them (colloquially known as a "floor sort"). If you wanted to be really fancy, you'd use different colored cards for different sections of a program, but that was rarely worth the effort. Good times.
Besides card punches, readers and interpreters, other quaint machines I dealt with on a daily basis were chain printers (with carriage tapes - look it up), reel-to-reel tapes (which required cleaning the heads with isopropyl alcohol and cotton swabs once a shift), and the most evil of all, decollators (again, look it up). All controlled via consoles that didn't have cursor keys, so to this day I have the TERRIBLE habit of backspacing to nuke and fix typing mistakes rather than cursoring and surgically correcting them. I bet the Backspace key on my keyboard is probably in the top 10 keys in my usage profile. :)
I'm old, too. I learned to program on punched cards, and remember the move to high-speed paper tape. That was awesome!
One of my favorite stories is from those punched card days. I was a careless teen, and knocked one of the developer's card decks off of a desk, sending all the cards scattered widely across the floor.
The sysadmin made me gather them up and manually sort the several thousand cards into the proper order. It took a over a day. When I was done, he took them from me and dropped them into the hopper of a machine in the corner to "check my accuracy".
What he didn't say, and I didn't know until weeks later, was that the machine he used was a card sorter and could have put the entire deck into the correct order automatically. The dev made me sort the cards manually as punishment -- and it worked, as I was much more cautious from then on.
My ex-wife worked for a legal software firm. One thing to note is they were threatened with lawsuits ALL THE TIME, because, after all, their customers were lawyers. So any bug or whatever else would end up with some nasty email from some customer exclaiming, "We're going to sue!" In reality, not many (if any) actually carried through with it, but if that sort of threat makes you queasy, better be (or have) a really good lawyer yourself if you go this route, and not just as a domain expert for the software itself.
So true! I built a solution for a legal services outfit a few years ago. First bug they see, they want to sue you. Forget about working with the vendor to refine the solution. They just want to sue you. Never want to work with lawyers again.
