Author: Mr. Cheap

Increasingly, in today’s world, it is necessary to continually learn.  Whether reading books about real estate investing, pouring over a company’s annual report or retraining for a new job (or new position) life-long learning is moving from being an asset to a necessity.

As a long-term student (currently in my 9th years post high school and with at least a couple more years ahead of me), I’m always interested in techniques for learning faster or better.  One such technique, which I learned years ago in my first year of university, is easy to apply and has been valuable for occasions where I need to bear down and really learn some written material.

For this you’ll need a set of set of markers (of assorted colours) and a copy of the information that you’re learning that you can basically destroy (don’t do this to library books!).

Associate each color with some judgment about the text.  I use red to strike out redundant (or well understood) information, yellow to highlight information that I need to memorize (such as vocabulary when I’m getting up to speed in a new area), I write questions in blue about something I’ve read that I don’t understand, and I write in green actions I need to take to follow up on information (to ask somebody about it, look at another source, or think about later).

At this point, more than just text, it becomes a working document.  I can look at it again later, see the points in blue, and immediately know what I have to work on to understand the text (it keeps me from forgetting any of the questions I had while reading it).  When I’m planning out a day, I can scan over it and copy out the green actions and put them on my todo list.  If I’m studying, trying to memorize terms, I just focus on the yellow highlighted portions (and skip over the red parts).  As I deal with these, I strike them out in red (so if I’ve memorized a yellow-highlighted term  I strike it out, if I deal with a green action I strike it out in red) and when the text is totally red I’m done with it (and throw it away).

Beyond focusing your attention on important parts of the text for different purposes later on, I think it’s also helpful as it transforms reading from a passive activity to an active one.  I’ve often found when I’m trying to read something boring that my mind will drift as I “read” through a section (and suddenly realize I don’t remember what I just read).  When you’re reading and trying to decide “is this important to know?  do I understand it?  do I understand everything well enough to cross it out and never look at it again?” it’s pretty tough for your mind to wander and evaluating it keeps you very engaged with the material.

I’ve used this during my undergrad on course notes, and as a grad student when reading academic papers.  I’ve never actually used this on a book (it would kill me to mark up a book this way), but I should.  Books are purchased for the knowledge they contain, and absorbing that information is more important than keeping the book in pristine condition.

There is a small “silly” feeling as part of this (it feels more like colouring than working hard).  Usually with academic papers I’ll stick to two highlighter colours and a pen for making notes instead of the full range of multi-coloured markers (especially when I’m working at a coffee shop or in my shared office).

Although this may or may not work for everyone, it’s easy to try (and if it helps you learn material, why not?).

This approach certainly isn’t universally valued.  One book specifically mentions it as something that takes longer and interferes with learning.  Cal Newport mentions this in the introduction to one of his books as an ivory tower approach to learning that doesn’t really work (although it has worked for me, so his experience isn’t universal either).

What is your favourite technique for learning new material?  Do you often use study habits from your school days (assuming you’re out of school)?If you try this out, please return and comment whether it was useful to you or not!

For people who have grown up in a Western country, servants bring a number of images to mind.  There’s the Jeeves and Wooster ideas of butlers, valets and chambermaids, the fabulously wealthy lifestyle that would lend itself to mansions, luxury cars and servants or social justice issues where it’s unconscionable to even allow people to serve one another in this capacity.

I’ve never had a servant (my family is firmly lower / middle class and has been for as long as anyone remembers).  I’ve never really even interacted with one.  I do, however, have a number of friends who grew up in households with servants (or had relatives who had servants).  In many developing countries, it’s very widespread to have servants in your house (such that even the middle class has servants).  One of my friends from the Indian subcontinent said once “where I grew up EVERYONE had servants” (except the servants I suppose).

I was fascinated by this and kept asking questions until they got sick of them and refused to answer any more.  This post is a summary of some of the more interesting facts I gathered.

To clarify, what I’m talking about here is someone who lives with a family and does work around the house for extended hours on an ongoing basis as their principle occupation.  I’m *NOT* talking about people who come in once a week for 3 hours to clean your house, a landscaping company or a dry cleaner.

Not Slaves

First of all, there’s an important distinction to be made between servants and slaves.  I asked one friend if his family ever beat their servants, and he gave me a withering look and said “no, they’re not slaves, they’re employees.  If we beat them, they’d quit.”  Sometimes families hit the point where they can’t afford to keep the servants around, at which point the servants have to go off and find new jobs.  It’s a long-term career, with expectations of loyalty on both sides, but ultimately it is a job.

Limited Skills

It’s often more remarkable what servants are (supposedly) INCAPABLE of doing, rather than what they’re asked to do.  One Indian family I talked to, who had servants back home, told me that none of their servants would be capable of operating a washing machine.  I was incredulous and kept asking, couldn’t they be shown how to operate it, to which the family kept repeating “no, they couldn’t learn and would refuse.  If they wash clothes, they’ll do  it the old fashioned way by hand.”

Another friend did verify that I was right and servants could be taught more advanced skills, but he said you wouldn’t.  He and his brother had lived extensively in Western countries, and he said if they wanted pancakes, they’d make them themselves.  He said if he asked the servants for pancakes, he’d get something like naan (which I’d take over pancakes any day, but maybe it wouldn’t taste as good with maple syrup).

He acknowledged that you could teach your servants to cook western style food (or use a washing machine), but he said they’d promptly leave and find higher paying work at a richer persons house as soon as they’d learned (and he said if you wanted a servant with those skills, you’d be better off just hiring one who already knows them).  He also said they wouldn’t be the fastest learners:  it would take more than just sending them to a weekly cooking class or giving them the washing machine’s owner’s manual.  He said the same would be true if you got a servant to learn to give you Shiatsu massages.

One Boss

One thing that I found interesting (and seems to be fairly universal from the Indian subcontinent to Egypt) is that usually the household has one person who is the servants’ real boss (and it’s usually the matriarch).  When I asked one friend if he could send his servants out to run laps around the house, he gave me a pained expression and said their first response would be to give him a “Come on man!” look, then if he still insisted they do it, they’d go talk to his mother (who would then tell her son to be nicer to the servants and tell the servant he didn’t have to run laps).

In another situation, one of my friends had an aunt who was mean to the servants, and occasionally when the servants got upset, her grandmother would ask them what was wrong.  They’d reluctantly tell her the aunt was misbehaving, and the grandmother would straighten the aunt out.

Variations of Respect

There seems to be a spectrum of the respect shown to servants.  One woman I talked to had an older servant whom she said she and her mother would always talk to using the honourific phrases of speech appropriate for an older person.  She admitted that some families don’t follow this convention.  Another friend spoke the same language that his servants spoke.  His father understood it perfectly, but the son had never in his entire life heard the father *speak* in the servants’ language (he used a higher class dialect that the servants similarly understood but didn’t use).

One really interesting superstition I heard about is that if you don’t share your food with your servants you’ll get sick.  The expectation is that the servants eat what the family eats, and if they order something special (like Kentucky Fried Chicken), they order enough for the servants too.  One friend hypothesized that maybe the fear is the servants will poison you, but my feeling was that this was more a general superstition that a “poison-avoidance” strategy.  I laughed when I heard one friend say that his mother forces the servants to eat small portions of the same food she does, even if the servant doesn’t like that food (so she won’t get sick).  I suspect this superstition was started by a clever servant who wanted some of the food his boss was eating.

Do you have servants, or have you ever lived in a house with servants?  What was it like?  Have you heard experiences that differ from what I’ve described here?

This continues last week’s post on Working With Computer Nerds (if you haven’t already, read part 1 first – it has cartoons!).

Unknowables

With computer work there’s almost always big unknowns.

Whereas most people learn their jobs, get good at them and do the same thing over and over (I want a lawyer who has seen hundreds of contracts just like the one she’s preparing for me), computer work is different.  Software can be copied so inexpensively it’s basically free.  This makes it redundant to do something that has already been done.  For legal reasons, this happens (I can’t get Google to send me the software that runs their servers or Microsoft to send me the source code for Windows XP, so if I want to make software LIKE theirs, I have to write it again from scratch).  For many thing however, copies are available FAR less expensively than it would cost to build a new version.  Computer nerds are almost always working on new things, because if they already had software to solve a specific problem, they’d just copy it (or buy it then copy it) and be finished.  Often computer people also dive into projects that involve technologies that are new to them and part of the project is learning something totally new, then using it to do the work (which is also new to them) they were hired to do.  This causes most of work that we actually do to be new, and therefore will usually be far more challenging than most people’s work (which is why we like it). Yes, this can be as frightening as it sounds.  I came to realize that a moment of blind, absolute panic was required in most contracts I worked (“Oh my god!  I’m not going to figure this out, I’ll miss the deadline and the client is going to shoot me dead!”).

An example of this, I did a 6-week contract at a publishing company (I’d never worked for that company or in that industry), building a content management system (which I’d never done), using Django (a framework I’d never used before), based on python (a programming language I’d never used) using PostgreSQL (a database I’d never used before).  As near as I can tell from their website, the system I put in place is still chugging away fine for them (and they were happy enough with my work that they wanted to extend the contract after I was finished).

The big reason for avoiding the two problems in last week’s post is that there’s enough uncertainty in software development, so remove any extra uncertainty that you can.  When someone does computer work, part of what they’re offering is insurance that they’ll deal with the expected unexpecteds – they should be allowed to do what they can to contain the amount of risk they’re being asked to insure.

This all being said, it’s not outside the realm of possibility (it’s actually fairly likely) that once the nerd digs deep enough into the problem they’ll find that something that was originally planned for that won’t do what it was expected to (some part of the system is missing a feature or there’s some incompatibility).  Usually when a computer nerd comes to you with this, they’ll also have 2 or 3 alternatives to offer.  Hear them out and take one of the alternatives.  You may be within your rights to insist what was originally discussed be delivered (especially if a couple extensions you wanted were turned down as “feature creep”), but it’s going to poison the working relationship if you can’t at least give a good reason why you need the exact original (sometime substitutions are necessary).  It may also be possible at this point to strong-arm a discount, but this is the opportunity to be the cool client who will get top priority in the future or be the difficult client who gets dropped as soon as business is good enough.

Imprecise Deadlines

Because of the above mentioned uncertainty, computer projects ofter take longer than expected.  It’s probably reasonable to hold firm on the money element of a deal (although many a junior nerd has driven themselves below minimum wage levels by poor estimates), but it’s worthwhile to give a project a bit of wriggle room, and let the computer nerd deliver a bit late if they run into problems.  I’d recommend padding the schedule by 10 or 20% and if they come and start seriously talking about a schedule slip, you’ll be a hero when you give them a bit of extra time.

Vendor Lock In

One of the things some technology vendors (and some computer nerds) do that drive me NUTS is vendor lock in.  They do work for a client, doing a good job at a reasonable price.  They’re hired back and start a good business relationship.  One day the client realizes that the price has been steadily increasing, the delivered value has been steadily decreasing, but they’re now reliant on the vendor for core technical needs (systems have been set up such that the the vendor is the only one who can modify them) and are being held hostage.  I would often stress to customers that I won’t do this, and would leave their systems in a well-documented state such that someone else could take over for me when and if this was needed.  Customers never seemed to care about this, but I’ve heard enough horror stories of companies getting shaken down for thousands of dollars for trivial changes that I can’t believe this isn’t a bigger concern for people.

To avoid this, present your concern to the computer worker as “what will we do if you get run over by a bus?” or, if it’s a bigger development company, “what will we do if you go bankrupt?”  Don’t be deflected by them laughing this off.  Get them to document everything, and occasionally hire ANOTHER computer nerd to have a look at what’s in place and see if they could take over if needed.  Both of these will increase the cost of a project, but in my opinion, is some of the best money you can spend on risk management.

For software that is at the core of a business, I think it needs to be developed in-house (hire an employee).  Giving an outside developer this much control over your entire company is reckless.

For computer nerds and people who have worked with nerds, what advice would you have for the best ways to works productively together?

In a (surprisingly well-received) post a while back, Working With Computer Nerds, I provided a profile of the typical computer nerd, and some suggestions on general approaches to understanding my clan.  In this post I’m hoping to provide concrete examples of problems that typically arise when working with nerds, an explanation of the misunderstanding leading to the problem, and some idea of how to avoid them.  As with the previous “working with” posts, please consider this a rough sketch rather than a definitive guide.  The target audience is someone who might hire a technical person to do work for them, someone who regularly works with a nerd (or, heaven forbid, nerd*S*) or someone who is friends with a nerd and wants to understand their work better.

Pay by the Job, not by the Hour

As with many things, with computer work I feel you’re better to pay for what you need done rather than by the hour.  By-the-hour work has the inherent conflict of interest that if the person doing the work is less productive, they get paid more.  You won’t be able to get all work done this way (for example, no reputable computer shop is going to agree to fix your machine for a flat-rate, sight unseen), but for most things it’s possible.  If the person doing the work is efficient and gets things done quickly, good for them and let them earn a premium for their work.  Surprisingly, a number of computer nerds are highly-ethical and may give a partial refund (or discount the charge) if the job is easier than expected (I’ve done this).

For jobs, like computer repairs, where you must pay by the hour, I’d recommend trying a few different people then stick with the one you like the best.  Over time you’ll get a sense whether someone is being honest with you or not.

Feature Creep

Software is an unusual product in that it’s so versatile.  As soon as you see it doing something, it’s easy to think of extra things you’d like it to do.  Almost any software product that has a customer base will keep turning out new versions, each one inspiring customers with more things they’d like it to do.

This causes problems with custom jobs, as customers immediately think of new ways they’d like their website or software to work once they see it in operation (and usually convince themselves that their new idea should be included in the original project and delivered within the original budget and time line).  The customer wants better software for a lower price, and the nerd wants to be paid as much as possible for what they’ve produced.  This was one of the big things that got me out of contract programming – I got fed up arguing with customers whether something was in scope or not.  It’s possible that some people view this as a chance to re-open negotiations, but you’ll be driving the nerd you’re working with NUTS if you do this (you’ll be burning goodwill at an alarming rate).

A good computer nerd will write up a specification for a project and carefully go over it with a customer (even if that “customer” is another employee within the same company).  It’s important to take this seriously, as this is what you’ll go back to to resolve whether something was part of the original project or not.  If something important isn’t in the original specification, admit that it’s something new that you want and add it on as an extension to the project (or be willing to allocate more resources to the project to have it included).  Let the specification act as the contract, and if something isn’t in it, then it’s extra work.  Avoid vague language in the specification, as this will just lead to arguments about definitions and meanings.

I knew I’d laid the ground work properly when one client wanted me to do extra, unpaid, work  and they began the discussion with “I don’t want to talk about the contract, don’t even mention it.”  Clearly, they understood that our agreement clearly supported what I was expected (and not expected) to do.

Poorly Defined Problem

Without a specification (or with a bad one), it becomes very difficult to figure out WHAT should be made (and even when something is working, feature creep becomes inevitable without a well defined problem).  Some people approach design work (and sadly software development) with a “I’ll know what I want when I see it” attitude, which is totally unreasonable with computer work.  I’m amazed that people accept this in other lines of work (it seems to be the norm with graphic design).

It’s possible (although inefficient) to work this way with a salaried employee, but when working with a contractor this is guaranteed to end in misery.  When you’ve done the same job repeatedly and it keeps getting rejected without a concrete reason, you’d need to have INSANELY high profit margins to keep going with a customer like that.  I (and many other computer nerds I suspect) prefer to offer people a good price, with the understanding they won’t pull this kind of thing on me.

With people who know what they’re doing and are good at their job, it’s often worthwhile to express your needs and be open to their suggestions.  Just because you’ve heard buzz about Ruby, if someone doing work for you can make a good case for using Java instead, it’s worth hearing them out.  Talk about the problem, listen to their proposed solutions, and hammer down exactly what you’re hiring them to do and what will be delivered.

If the reasons they give for using another technology AREN’T relevant to you (they hit you with techno-babble that doesn’t make any sense), and if they won’t clarify after repeated attempts to get them to put things in terms that are relevant to you, I’d recommend not working with that person.  If they won’t build things with your needs in mind, how could they possibly do good work for you, no matter how brilliant they are?

This post got a little over-sized, so the second half will appear on Tuesday.