I went to dig into some of the sources cited in Peopleware (see my previous two blog posts), and I fell in love with this 1984 article on Japan's software industry and Hitachi Software Engineering. It's a look into a company that feels like peak-era IBM: much bureaucracy and even more success.
Timothy Lister and Tom DeMarco didn't include a bibliography in Peopleware, so I swept through the book and produced one for curious readers.
I just finished reading that old software classic, Peopleware. The first chapter is "Somewhere Today, a Project Is Failing," and hooked me immediately.
Mark Richards runs the Developer to Architect website, and puts out a video every Monday. He has helpfully categorized them. I watched all the videos in the "Soft Skills" category and took notes.
I've been reading about failures in distributed computing. A lot of it is thanks to Vaidehi Joshii's Year of Distributed Computing at https://medium.com/@vaidehijoshi . Here's small summary of what I've learned.
Here are my notes for week 2 of my product management education. This week is all about metrics, goals, and strategy, with a dive into Pirate and Heart metrics,
I've started an online Product Management class because, I dunno, I like learning new, non-coding things related to my job. I'll be posting all my notes here.
In the aftermath of GE's price fixing scandal, we learned that GE executives had a culture of winking while they told subordinates not to break the law. Sometimes. Each salesperson had to interpret the word and the wink, and the occasional lack thereof, according to their own internal rules. Effective communication was, effectively, absent.
NEDD is a one day conference in Cambridge. It's an inexpensive way to learn about the cutting edge of database research. These are my notes on each speaker.
I'm not in management, but damned if I don't love a good management paper. Today it's Frederick Herzberg's "One More Time: How Do You Motivate Employees," where I learn to not kick an employee.
There is one scene that gets referenced several times in Rapid Development by Steve McConnell as an example of a hugely productive team.
Joel Spolsky's writing and opinions are evergreen, and his 2004 book The Best of Software Writing shows it.
An 1984 paper that models the time it takes to complete a project, and show what happens when you pull are up against bad deadlines. The answer will not surprise you!
excerpt from How Complex Systems Fail
For my own reference, here are notes I took while reading Google's book on SRE.
If you're responsible for a large, legacy code base, here's my hint to you: delete your failing tests.
A small trick to make "before" a bit more powerful, a bit more useful, and a bit more dangerous.
Eric Brewer and Daniel Abadi expand our notions of what the real trade-offs are in the CAP theorem.
An scientist's idea of literary criticism is different from most people's. It involves math.
Chuck Jones inspires UI designers in this classic paper from Ungar and Change.
In 1991 Ungar and Smith wrote about the experimental programming language SELF, and in it described duck typing, callng it behaviorism
The great benefit of knowing the command-line is being able to write scripts to analyze scripts, all in ~1 minute.
How I write CSS.
I hand crafted the CSS for site. It's still a work in progress. I learned that while semantic tags are good for HTML, they're not that great for CSS.
After a lifetime of programming and compsci education, I've had some issues learning with Python. It screws me up in small ways. It's a wonderful language, but dear god I wish these things were different.
The greatest problem in learning object oriented design is in the toy problems. The object oriented solution never looks better than the regular solution.
Learn the right way to write a program the wrong way
This paper is considered seminal in Object Oriented Design, but Parnas never mentions objects, and his example program is described in procedural programming terms. The lessons in this paper are applicable to *all* programming methodologies. It's just about smart design decisions.
You can't trust Ken Thompson. He'll prove it.