Dumbheart

Dumbheart: A Get Fuzzy Collection by Darby Conley
My rating: 5 of 5 stars

Despite be 10 years old, I find all the republican/democrat jokes to be spot on. I'm not sure they were balanced by it was nice to see both sides lampooned.

View all my reviews

Google AutoML And Thinking Machines

After attending a machine learning presentation I got the chance to talk to the presenter about AutoML. He said that it is out-performing a lot of data scientists at Google. Which really peaked my interest. I asked him if the software was similar to the software Daniel Hillis wrote back in the '90s to generate code that was out-performing human coders (see The Pattern on the Stone). Sadly, he had no idea who Daniel Hillis is. I think the idea of software generated code never caught on because no one could understand why it was faster but everyone could agree that it wasn't safe because it was so difficult to decide if it would always work correctly. Which brings to mind the question - is AutoML safe? Will it create bias because the data is formatted a certain way?

I look forward to learning more about how AutoML works. I'm also interested in learning how to use AutoML but am vastly more interested in its internals.

Monitoring Matters

My mornings start with me reading my Google news feed. This morning included a story about Wow Air closing. Approximately four hours later I ran the following Google query:

Imagine my surprise to see a large travel company still running ads for Wow Air. At this point operations had been ceased for around ten hours. Ads for such a competitive market would probably cost one to six dollars per click. And with Wow Air being in the news curious people probably clicked that ad to see what was being sold in addition to people who wanted to travel to Iceland. I clicked it. It was a branded page but when I dug into the options Wow Air was already removed from the list of carriers. This highlights the different speeds with with different departments react to changes. And moreso, it highlights the lack of communication in businesses. Someone, probably many someones, knew that Wow Air was no more so they removed it as a flight carrier option. They did not, it would seem, reach out to Marketing and say, "Hey, you'll want to disable your ads." This is the downside of work silos. It would never have crossed their minds that such a thing could be helpful. Besides it is not their job...

For small businesses and account managers, it often isn't a problem to respond to an issue within 24 hours. Something I use and have shared with some account managers is Google Alerts. This works well but can take a day to get an alert. Basically, you get notified if some keywords you specify are referenced when a new webpage gets indexed. This might not help you if an existing webpage is updated. It depends on whether your keywords didn't use to match but do after the webpage is re-indexed.

For things that need immediate handling when there is a change then that usually requires being proactive. For example, there are lots of services that will notify you within a few minutes that a webpage has changed. In this case, if you are the person handling Ads for Wow Air then you would probably want to know anytime the main landing page changes. Most of the time the changes won't matter to you but they could reflect a need to update your ads or in an extreme case - this case - the need to disable your ads. Several years ago, I had a job where it was very helpful for me to know when and if a set of services were down or had changed. I used https://www.runscope.com/ to notify me if a set of tests didn't pass.

As a software engineer, it is really valuable to listen to the problems that your coworkers are facing, even the ones in different departments. You might hear an account manager complain about how much of a hassle it is to constantly check for press releases that relate to any of their accounts. Then you can helpfully share that you use Feedly to monitor the release of new webcomics and they could use it to get notified of press releases or anything online.

Your Brain At Work

Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long by David Rock
My rating: 3 of 5 stars

Great advice but the presentation via examples made the material hard to endure. Also the examples were so extreme I found them to be a bit off-putting. They followed a pattern of saying that without the miracle techniques being presented in the book you would end up poor and unloved and it would be your own fault. But by applying the strategies from the book you would be successful in business, friendship, parenthood, and you would have more sex.

Don't get me wrong. There is undoubtable good advice in this book but results will vary. Some of the strategies will likely offend other people because they might feel that they are being manipulated. Read this book with a large pinch of salt.

View all my reviews

Inspect Code

Inspection of software design and code was first proposed by Michael Fagan in "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal, July 1976. Inspection can account for as much as 82 percent of all errors found in software. Inspection is much better than testing for finding errors. Define criteria for completing an inspection. Keep track of the types of errors found through inspection. Fagan's inspections consume approximately 15 percent of development resources with a net reduction in total development cost of 25 to 30 percent.

A project schedule should account for the time to inspect, and correct, every component. It might seem that a project cannot tolerate such "luxuries." However, inspection should not be considered a luxury. Data has shown that you can even reduce the time to test by 50 to 90 percent. If that's not incentive, I don't know what could be. By the way, there is a wealth of support data and tips on how to do inspections well in "Key Lessons in Achieving Widespread Inspection Use," IEEE Software, July 1994 by R. Grady and T. VanSlack.

Smoke Gets In Your Eyes

Smoke Gets in Your Eyes: And Other Lessons from the Crematory by Caitlin Doughty
My rating: 5 of 5 stars

A fascinating book with a lot to teach. I wouldn't recommend it for someone who is young. There are a lot of the lessons are hard ones. However, I wonder if it should be required reading for an adult or a kid in high school.

View all my reviews

Hand-Test Every Component

It might take 30 minutes to test a software component by hand with a few simple test cases. Do it! I am suggesting this in addition to, not in lieu of, the more thorough computer-based unit testing that is already being performed. What is the cost? Just 30 minutes. What is the alternative? Save 30 minutes now, proceed with unit, integration, and system testing. The system fails. Three to four person days are spent trying to isolate the cause of the failure. A half-dozen components are isolated as possible candidates. Each is given to its developers for further examination. Each candidate spends 30 minutes testing the component by hand with a few simple test cases. In short, 30 minutes are less than three to four person days plus 6 x 30 minutes.

Another reason to perform routine manual testing is that it identifies components that need to be updated. All your builds and automated tests will pass and not complain with outdated tech. But when developers have to manually test a component with an outdated build or libraries, they will complain and get it updated. Which will keep the software relevant.


Reference:
Ledgard, H., Programming Proverbs, Rochelle Park, NJ: Hayden Book Company, 1975.

Document Before You Start Coding

This advice will seem strange to some readers, but it becomes natural after being practiced for a while. Comment Before You Finalize Your Code explained why a programmer should document his or her code before finishing it. Document Before You Start Coding goes one step further: Programmers should document their code before starting to code!

After performing detailed design on a component [that is, documenting its external interface and its algorithm(s)], write your inline comments. Most of these inline comments will be nothing other than the previously documented interface and algorithm. Put these comments through the compiler to make sure you haven't done anything silly (like omitting a comment delimiter). Then convert each line of comment into a corresponding program segment. (Note: If you end up with one line of code per comment, you probably specified your algorithm with too much detail.) You'll find debugging goes a lot smoother.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Kiss My Asterisk

Kiss My Asterisk: A Feisty Guide to Punctuation and Grammar by Jenny Baranick
My rating: 4 of 5 stars

A fun way to brush up on grammar rules. Kiss My Asterisk is written such that each chapter is standalone. You can read it out of order or spread reading it over several months and you won't miss anything. This makes it great for focusing on specific areas, as a doctor's office book, coffee table book, etc.

View all my reviews

Barking Up The Wrong Tree

Barking Up the Wrong Tree: The Surprising Science Behind Why Everything You Know About Success Is (Mostly) Wrong by Eric Barker
My rating: 5 of 5 stars

An interesting collection of facts, research, and stories about success. For example,

"Distractions literally make you Stupid.

Students whose classroom was situated near a noisy railway line ended up academically a full year behind students with a quiet classroom. When the noise was dampened, the performance difference vanished. Offices aren't much different. Research shows that the most productive computer programmers have one thing in common. It's not experience, salary, or hours spent on a project. They had employers who gave them an environment free from distraction."

View all my reviews