Skip to content


What’s wrong with Squarespace Support?

In moving my blog to Squarespace 6 I've had a lot of contact with their support service. They are 'just ok'. Yes, they have the usual boilerplate, "so glad you contacted us" and "i think I understand why this is important to you." Ok, ok. Enough cut and paste.

The problem is that they are probably pretty junior and used to answering easy questions. But when they get at all subtle or maybe even pointing to a bug, they are lost in the woods and give you useless help. But that's not the biggest problem.

The biggest problem is that there's no continuity. Each part of the support email 'conversation' is answered by some random other person. And while they probably make a good will effort to maintain continuity, it happens constantly that the new person doesn't understand what came before and gives you a non- sequitur answer.

Now I have nothing to compare them to, for example, what does give in support (probably nothing) and what does give in support? (probably nothing.)

Rules of Thumb for Software Engineers

Based on my own experience, some of my favorite books and blog posts, and advice from friends, I've come up with this. What do you think? What should I add? Please comment!

Personal Effectiveness Rules of Thumb
  1. When you have your best idea ever,always remember that the idea is just 1% of the journey Yes, ideas are cheap. At least in the world of software engineering and product development, everyone and their grandfather have ideas that may be great. The distance between the idea and the reality is great. Here's Steve Jobs about ideas

  2. When your project is late,never ADD people Most of the time this will slow you down. The reason is that with each additional person you add to a project you've created that many more paths of communication. If a project is late, adding people to it will make it later. See * The Mythical Man Month by Fred Brooks.

  3. When planning your time,always allocate at least 20% to learning more Software engineering, programming languages, libraries, platforms, hardware and software are constantly changing. It take a real sustained effort to keep yourself up to date. What was a good or best practice a year ago may no longer be right.

  4. When arguing about a design or a feature,always stop and go ask a user. Good products don't come from debate around a table, they come from discussion with the actual users. Don't guess, don't argue, go ask! This is known as "getting out of the building".

  5. When planning a project,always work in short increments. Follow Agile practices, whatever your favorite flavor is, scrum, XP, Kanban, it doesn't matter. Different teams and people like different approaches. And they change and evolve all the time. But there are eternal truths there. Work in small chunks. Even smaller. Even smaller. Don't change many things at once because when your code invariably breaks, you won't be able to tell why.

  6. When you are spinning your wheels,always stop, think, and only then act. Google It! The amount of knowledge and down and dirty solutions that you can find on google is infinite. See a strange error message? Google it! And learn how to edit the error message, removing the parts that are specific to you so that you get matches. Or ask on the right forum or mailing list. You need to learn how to ask a question in a way that it will be answered. Make it as easy as possible on the answerer.

  7. When you are posting on a technical forum,always formulate the question carefully. Here are the best practices:

    • Explain precisely what you are trying to accomplish
    • Give a step by step explanation of what you've tried and the result.
    • Give code samples, links to github accounts, and so on. If the code samples are not brief, create a gist and put the link in the post.
    • Include listings of the relevant data, file names, console logs, and versions of various software you use.
    • When you are writing a 'business' email, always follow best-practices

    • If you expect action, have a single person in the to:

    • Know the difference between reply and reply all. Usually don't reply all
    • The first sentence should state what action you are looking for
    • Keep it short and sweet. Make it "skimmable".
    • Know your audience and write appropriately.
    • Get to the point. Be polite.
    • When you have to write up a design or a spec,always keep it to a few pages. Prefer writing short 'stories' over writing long 'specifications. There is no requirements 'phase' to a project any more. Write many short stories and prioritize them relentlessly. If the story is more effort to write than the code, you should be writing the code!.
Programming Rules of Thumb
  1. When coding,never go beyond the immediate requirement. Write only the code you need to solve the problem RIGHT now. You might think that this class clearly will need all this methods even though no one is calling them yet. This almost never works out. Don't spend time to set things up for what you'll need in a month. You're usually wrong.

  2. When coding,always wait to optimize until later. Optimizing too early is one of the cardinal sins of programming. You never know where the bottleneck will be, The thing you think will be slow, will be fast, and vice-versa. Actually you might end up ripping it out anyway!

  3. When your own code mystifies or surprises you never accept that. Dig deeper.

    • Catch yourself engaging in magical thinking. If it worked yesterday, and not today, then something changed. Similar story as "It worked on my machine, why doestn't it work in production?" Both of these are a symptom of magical engineering thinking. It's just a computer. If the behavior changed, then something cause that change in the behavior. Methodically go through each thing that might be different and, like a scientist (or Sherlock) figure out what it was.
    • Don 't be satisfied with blind luck Copying some code without knowing what is going on is not a good idea. Eventually it will come back to haunt you. Be really curious!. If a certain change fixed the problem, investigate until you understand how it fixed the problem.
    • Learn to Debug Debugging is a craft in itself. Approach it like a scientist. Don't poke blindly at the code, or solve the problem just by thinking about it. Have hypotheses to test. Do experiments.
    • When your program blows up always stop and read the error messages. Catch yourself jumpint to conclusions or seeing what's not there. Fight the impulse that you know what must have failed. Often the right answer is right there in the error message. It might be buried in the middle of a lot of noisy trace output, but discipline yourself to actually read it.
  4. If you think you spot a code smell always come back and eradicate it Train yourself to recognize (and HATE) code smells. Like nails on a blackboard, badly designed code should make your stomach turn or your skin crawl.

    • <%= ir "Never, Ever" %> Cut and Paste code. DRY is a law. If you see any duplicated code it is almost always a bad thing. Look for it and kill it.
    • <%= ir "Learn how to Refactor" %> This is a fundamental coding skill. When you see non-dry code or other violations, refactor ruthlessly.
    • never leave dead code behind** Delete it.
    • always keep your files, methods and functions short** Depending on the language and the program, the right number may vary. But a method that has more than 20 lines is almost always a serious code smell. A guideline would be 10 lines.
    • When programming always use a source control system. It's your safety net. This is especially true when working with other programmers. Learn your SCS tool so you are never reluctant to use it.
  5. When designing software,always keep concerns as separate as possible. Design for loose coupling. Pay attention to the Single Responsibility principle. Whether it's a single class or function, a subsystem or module, or a whole system, minimize dependencies. Learn about dependency injection and other techniques for decoupling.

  6. When doing object oriented programming always avoid using class inheritence While tempting, it is almost always better to avoid using inheritence in your class design. It brings undesireable coupling with little benefit that could be had in a simpler way.

  7. When programming always use 'intention revealing names' Chosing the right names for classes, variables, methods is one of the best ways to 'document' your code. Follow your language's naming conventions closely and then create names that reveal your intention. Name things after what they do, not after how they work! Also make sure names are internally consistent. (Ref: Intention Revealing Names)

  8. When programming,always comment your code, but not too much. The exact line is a matter of (fervent) debate but it is almost universally accepted that having no comments is a bad idea and that its easy to have too many comments. Keep your comments at the start of each source file, and at the start of each method. Occasionally you might want to put a few lines of comments inline. But that desire often alerts you to a refactoring opportunity.

  9. When learning new things never fall in love with the shiny toys It's ok to be proud in your expertise and trying to perfect your craft. But platforms and languages come and go, and you must remain alert to newer and better ways to solve problems as they are invented. Don't fall in love with a language or platform. It will change and the specific details you memorized will eventually become useless.


Many of these are from books, blogs and my own experience. I will list all the credits that I can identify but I think in some cases these rules are so deeply embedded that I cannot recall where I got them from. If you see sonething that you think you came up with, I appologize! is not the site I have been looking for

I've been using for years now but every month I hate it a little bit more. It's too big, too slow, and too buggy. But it's solving a problem that I need solved which is a comprehensive cloud based personal finance tool that covers banking, investments, credit cards, reporting and analysis. I can't say that their decline corresponded exactly with when Inuit bought them but… it didn't help either.

I've wondered why no one is tackling this space. I try them all and they all are lacking in one key way or another. Here's a review from the New York Times From those, I've been test driving BillGuard and it seems to have potential but I am not ready to switch yet. So when I read about NerdWallet I thought, based on the name, that I had another candidate. I had to search their web site high and low before I could find a summary of what they do:

We create user-friendly tools, crunch numbers and give you all the results, unfiltered. Across banking, credit cards, education, health care, insurance, investments, mortgages, shopping and travel, we offer data-driven tools and impartial information to help you make solid decisions about the money you work hard to earn. In short, we do the homework so you don't have to.

Nope. Keep looking.

When Twitter becomes a blogging platform

I have been noticing more and more serialized tweets. In other words, someone tweets several times in a row because what they have to say will not fit into 140 characters. They number them and fire them off one after the other. That way you, the reader, can reassemble them in your head. Of course the arrive in reverese order (the newest ones are the last one.) Also you need some way to note that your series is over, which might beget a new twitter shorthand

Why, if I can attach a 5 minute video or a photograph or a 3 minute mp3 to a tweet, can 't I attach a 2 paragraph messge? Why not allow me to have as much text, and why not fonts and styles? It's just a matter of time.

The 140 Character Limit was the gimmick that differentiated Twitter from all other messaging platforms at the time. But we in a new era now. Twitter has established itself. Your twitter handle has become almost as self-identifying as your actual name (or maybe more so, because it is guaranteed unique, world-wide.)

It's a totally natural set up for the ultimate, universal, blogging platform. I see that happening.

Someone said, Twitter is trying to become more and more like Facebook, and Facebook more and more like twitter. And both are the worse for it. Maybe when Twitter starts accepting long messages people will say that Twitter jumped the shark. I doubt it. I think it's inevitable.

My Bitcoin stash is falling in value!

Yes, I have about $100 in Bitcoin and today was a bad day. It droppped from around $630 to around $580. Am I a speculator? I guess, but my excuse is that I'm very interested in the underlying technology and there's nothing like having some to getting a feel for the space. Here's a great article about Bitcoin Mining.

For Virtual Prospectors, Life in the Bitcoin Mines Gets Real -

Bitcoins are mined by a decentralized network of computers that guess solutions to a mathematical puzzle. As part of that process, miners keep track of and verify all transactions on the bitcoin network, so bitcoins are a kind of compensation for maintaining the ledger of transactions. The faster a person's computer system can find solutions relative to the rest of the network, the better chance he or she has of being awarded bitcoins.

Better to be a software developer than a college professor?

Other than the headline, which is amusing, I am not sure about the methodology or significance of this study in US News (do they still exist?). And it seems that many professions, e.g. College Professor, don't even get mentioned. Is it because they don't even make the top 100? I doubt it. Anyway, Here's more about the US News and World Report's assessments:

"All jobs aren’t created equal. In fact, some are simply better than the rest. U.S. News 100 Best Jobs of 2014 offer a mosaic of employment opportunity, good salary, manageable work-life balance and job security. Some careers offer just the right mix of these components – for instance, nearly 40 percent of our picks are health care jobs – but the list also includes strong showings from occupations in the social services and business sectors. And for the first time, our No. 1 pick is a technology job. Read more on how we rank the best jobs, and check out our complete list." Read the whole article and see the report in US News and World Report.

Jonathan Harris on being stuck

Jonathan Harris is the creator of several really interesting web sites that in very creative ways combine art with computing. From his home page one might conclude that he's a bit

"This is the website of Jonathan Harris. I make projects that explore the relationship between humans and technology, incorporating computer science, statistics, storytelling, visual art, and other techniques. I see our species evolving into a single meta-organism, brought to life by the Internet, even as we live our individual lives, searching for meaning and beauty. My projects straddle these scales of existence--from the planetary to the personal. I make work, give talks, write essays, run a storytelling community, and obsess about the number 27" (His web site is here)

Here's a very well written piece in which he talks quite personally about some things that have challenged him emotionally and professionally. It's a great piece even though it still is a little .

Transom » Jonathan Harris:

I thought about stuckness, and about where I lost the flow. I remembered other times in my life I'd been stuck, and how the stuckness always eventually passed. I thought how life is a lot like that fountain, with its columns of water moving up and down, and how the low points are actually thrilling because the high points are about to come back, and how the high points are actually terrifying, because the low points always come next.

The Cloud is Watching You

It's obvious if you think about it, but this article drives some points home. If you use some kind of web service to read, listen, watch, charge, use, borrow or share stuff, that company not only knows what you've (read, listened to, etc.) They also know much more specifically how you did so: Did you stick with it to the end, did you do it from a particular place, at a particular time? Did you do it in one sitting or over a day or a week or a month?

If you then combine such observation across a farily large group of peope you can learn amazing things. Like how many people finish your book, or how far through it they get before abandoning it. Do they listen to the whole song? At what episode of a series do people abandon it? A little scary as the 'art' we 'consume' gradually morphs into the 'art' we 'like'.

Not only will be be offered to buy new products that we are likely to buy, but the products themselves will be designed in a way that we will like them. Or the art will be created in such a way that we will want to experience it.

Good or bad?

As New Services Track Habits, the E-Books Are Reading You -

Scribd is just beginning to analyze the data from its subscribers. Some general insights: The longer a mystery novel is, the more likely readers are to jump to the end to see who done it. People are more likely to finish biographies than business titles, but a chapter of a yoga book is all they need. They speed through romances faster than religious titles, and erotica fastest of all.