Twelve years ago I was complaining about this term, Heuristics. The term itself is incredibly simple in meaning – the kind of thing you can learn in thirty seconds. People seemed, to me, to be using it to “sound smart”, to create insiders (who knew the term) and outsiders (who did not).
Today I see the value in it – the term is precise. I want to bring you on the inside.
Let’s start with that thirty second definition.
“Attend to what you eat, how you sleep, and exercise” won’t solve every weight problem. You could have an insulin problem or other medical condition. Yet it is good enough, often enough, that it is a go-to idea for us. The engineering term for an imperfect way to solve a problem is a heuristic.
Many of us have our heuristics internalized. They are implied in the way we work, and can be as simple as “if you want to get anything done for the day, don’t start with email. Start by doing the work”, followed by “at the end the the day, park your work to start it immediately tomorrow.” Those are productivity Heuristics. (By the way, it is prounounced “Hew-Ris-tic”) Today I want to talk about my heuristics in software testing.
I spent most of my youth – and a good part of my 20’s – obsessed with things. As a mathematics major, then computer programmer, they were abstract things. You couldn’t even touch them. I worked with ideas. Christmas was something to put off until December 20th, then either guess, or, if I was lucky, work a list someone else gave me. The people in my life that mattered were close family. That is, if I remember them.
Eventually I realized the truth. Ten years from now, no one is going to remember if that project was on-time or a day late. What they will remember is how you made them feel. In IT, you can do better than 20% of people just by bothering to get a card for a few people that matter. Get to 10% by putting a lottery ticket into it.
If you prefer to think of life as a video game, consider this post about how to break above the top 5%.
This year, I’m going to do something unusual. Christmas gifts that won’t break the bank but can blow the doors off. At the end, I’ll review my more historic stocking stuffers, the kind you can get from Amazon for ten bucks that can lead to a great ice breaker.
This year, I want to do better. Continued »
A few days ago, I put out a post on twitter about Documentation.
That post was my most-replied-to, most-liked, most popular in weeks.
It’s time we talked about it.
For my brother’s birthday party, around age 5, my father rented some horses, kept by a farmer at the end of Route 40, which becomes West Patrick Street. The sides of Route40 were farm fields. During my early childhood I saw creative destruction as the fields were sold to create retail stores and restaurants — “The Golden Mile.” Behind the stores, more farms failed, and the suburbs came. More creative destruction. The central symbol of farm replacement was the Frederick Towne mall.
Today the mall sits locked and abandoned. It has become the Frederick Towne Ghost Mall. The retail shops and the suburbs behind them are failing. This is not demographics; it is not that the rich people moved away. Amazon, Ebay, and Wal*Mart.com make shopping in person dated, if not obsolete. Netflix and Amazon prime made it easier to watch movies than shlubbling down to a store to interact with (ewww) humans.
Commerce killed the farmers, then big box stores killed retail, then online shopping killed the commerce.
Karl Marx and Charles Darwin both observed the pattern, visible since the loom put a few hundred handloom workers out of work in 1788. The trade union that fought the hardest against automation-in-sewing were, no kidding, the actual luddites.
As you’ve probably figured out, they lost.
It was the Austrian, Joseph Schumpeter that gave a name to the pattern. He called it Creative Destruction.
Now think about the low-end worker, who could have been a farm hand in 1970 and worked retail in 1995. Where does that person work today?
Let’s talk about how Creative Destruction works. Continued »
Like it or not, resume inflation is a real problem in Information Technology. Those that are willing to lie a bit are rewarded with better jobs and more money. If you are honest, leaving terms off your resume because you do not know the tech, you might not even pass the keyword-match algorithm. More than one person told me that resume inflation is just expected. “People say what they need to say to get in the door”, goes the chorus “You use the interview to figure out who they really are.”
Which brings the next problem.
How exactly do you figure out who cuts the mustard?
Earlier I suggested we have a crisis of confidence in software development that is leading to a lemon market. My suggestion was an audition. The simplest audition for a programmer-type may be to ask them to solve the simplest of programming problems in a language they claim competence in. Personally, I am a fan of SQL. When you think about it, SQL is basically venn diagram converted into a grammar something between English and set theory from Mathematics.
They claim SQL on the resume. You ask a simple SQL question. Start with an employee and job table, which share a job_id in common. Write a query to find all the employees with a last name of “Smith” and their salary, which is in the job table.
I post it on twitter … and then things go sideways.
If you’re like me, you got into computers because, unlike humans, they made sense. Humans? The rules for social success didn’t make any sense. By middle school, I had realized I would be judged by the kind of shoes I wore. Like many, I became a computer programmer largely because computers are consistent, applying the same set of rules every time.
Then something happened around ten years of experience. Long ago I had realized the success or failure of the project was more dependent on the quality of the people than the process or methods. About ten years in, I realized the quality of the relationships impacted the outcome as well.
Nobody wants to work for an ass. Nobody wants to work with an ass. If they are multi-tasking, the computer types (us) are likely to work-to-rule, doing exactly what was asked while disregarding the intent or customer need.
Today I’ll write about one way to build a team. Continued »
Last time I discussed the secret stories about computer science from the end of my childhood, and one that had gone missing. The piece, the Parable of two programmers, appears in Wicked Problems, Righteous Solutions, published in 1991. It is the single best short story on programming productivity I have ever read. The book had long vanished to the winds of time, but a few years ago I bought a copy.
Then, two days after that last post, the copy jumped out at me. I opened up the book, did not find it in the index, and instead looked a page at a time. There, on page 167, was the parable of two programmers. A little help from a search engine and I found the piece, by Neil Rickett, still exists on the internet in a few places. Tim Mensch repeats the story entirely, then adds a section at the end where he basically claims to be charles, one of the ultra-productive programmers that I suggest you either become or else become close friends with and deeply appreciate.
However, that is not the productivity secret I took from the story.
Leaving me free to tell it to you. Continued »
In my senior year of high school, after class, I would walk about a mile to Hood College. At night was taking math and computer science courses like assembler and pascal. Until the evening I hung out in the computer lab, telnet-ing into Multi-User Dungeons and otherwise avoiding actual schoolwork. The professors generally had print-outs or cartoons on their office doors, and I read them. All of them. Those print-outs, later combined with email forwards, became the basis of what I call an alternative computer science education.
For example, learned that in C you could shoot yourself in the foot, but no one could figure out how you did it. Or that in C++ first you had to define a pistol object with a shoot method. That in Perl you’d stab yourself in the foot with a large Swiss Army Knife.
Mind you, I had no idea what C, C++, or Perl were, other than programming languages. I had simply read a printout on some professor’s door. I would go on to learn and work professionally in those languages, and that background gave me some insight. For that matter, learning Assembler at Hood made C++ and most other languages incredibly easy to learn.
Those snippets generally came from shared emails on the ARPANet, which became newsgroups. In 1990, two programmers, DeGrace and Stahl, collected a few of them in their book Wicked Problems, Righteous Solutions. I was fortunate enough to find a copy of that book, wedged behind a file cabinet, in the early days of the 21st century. Today, the book is $45 on Amazon — if you can find it. In that book you will find the first references to Scrum. You will also find the first references to mature iterative methods which we call Agile today.
Sadly, none of these texts appear in any guide to curriculum. But they should, as they summarize key points the curriculum guides miss. They are, in a way, an alternative route to truth.
Your CS Alternative Education
A few of the best parts of that “Computer Science alternative” education still survive in corners of the internet. I woud like to share them with you.
For me to select them, the articles needed to be free, funny, insightful, and reasonably short. I could make another list of books, like Peopleware or the Mythical Man Month. This list is free things to read during a coffee break.
If you want insights into the human condition as it intersects with software, well, this is my pearl of great price, given to you.
I submit to you that today, right now, in software development, we have a crisis of competence. This crisis shows up in at least two ways.
- Hiring managers do not know how to assess competence
- In order to qualify for jobs, candidates feel they have to inflate, or directly lie on their resume.
The result is something called a lemon market. Arising from automobiles, the basic idea was that if the buyers (employers) could not understand the value of what they are paying for, they are likely to simply buy whatever is cheapest. “After all”, as I heard one executive say “we can have projects fail for a third the hourly rate without the risk of permanent employees.”
Over the past few years, I’ve managed to do a little hiring myself, and a great deal of interviewing. That time has taught me that the audition is likely the best way to interview. I have also learned a few broad, sweeping generalizations about the audition that, are firm enough to need feedback.
Allow me to share a few words about assessing competency. Continued »
Consulting, or indirect influence, is getting people to choose what you suggest. That makes developing long-term consulting skills incredibly important. Those skills go beyond “thrill and bill”, needed to get and keep the job. It extends to helping improve the client condition. Again, this has to be indirect. Without authority or power.
Today I’m going to suggest one way to do that: By talking to strangers.
If you grew up in North America, this might not sound like the best idea. I’ll explain how not to do it, how it can be done well, and the impact of doing it well.