I always enjoy reading Sebastian Marshall’s blog. Primarily because I feel like I can relate to a lot of the things he talks about and his general attitude towards life and business. His book is a great culmination of those things. I thoroughly recommended checking out his book and blog.
-
A guy goes in to consult for a company and runs across a bug. He raises the issue and the boss says “Oh boy – another ‘Bob bug’ – Bob created a lot of bugs.” (Bob has moved on by now). After the guy was there for a while he comes to realise that Bob wrote most of the code while the rest of the staff wrote very little. The perception that Bob created a lot of bugs was technically correct, but an analysis of bugs per line of code written show that Bob actually made fewer mistakes than his co-workers, but since he generated the majority of the app, he had the majority of the bugs.
-
You don’t consciously set out to put on weight so it sort of creeps up on you. You don’t put effort into getting fat. You just wake up one morning, look in the mirror and go “Geeze, what the hell happened?”.
Getting fat is easy and comforting. You can relax and eat all the glorious tasting things. Losing fat is a constant battle. You’ve got to kill yourself in the gym and resist the temptation of eating too much. Doesn’t mean it’s not worth doing and not possible though!
-
My TalkTalk broadband hasn’t been working for the past three days and it looks like it’s never going to work as technical support refuse to believe that there is a fault.
Of all the years I’ve spent calling various company’s technical support numbers, I can honestly say that TalkTalk’s is the most appalling one of the lot. I’m completely livid with their so-called “support”. I’ve spent more than five hours on the phone with their “technical” team since yesterday, all while having to listen to nothing but lies and apologies for being unable to help me. Today I was on a single call that lasted three hours, which had me bounced to-and-from the same departments only to be hung up on. And I don’t mean disconnected, but actually put through to the end of call customer satisfaction survey with a cheerful “Thanks for your call”. One person even said I would have to upgrade my account to get technical support. I don’t think so.
“Oh, there’s no problem with your line”. Yes, I know there’s no problem with the line, I just can’t authenticate with the exchange.
“Oh, your router is not supported”. Yes, it’s worked fine for the past 6 years, so explain that.
If I even dare mention I’m on a Mac, that opens a whole other can of worms.
The only way I’ll be able to get any sense out of them is to have them send me a new router which I guess I have no choice but to do. Either way, I’ve had enough. I’ve already got a reconnection date from BT to move my line back to them and a Virgin Media engineer is coming round next week to get me on their internet service. I’ve heard some bad things about VM, but I really want to take advantage of the high speeds when it does work. I still have a backup broadband connection in the house I can use if it goes down at least.
Whoever thought offshoring technical support/call centres was a good idea should be shot. Has anyone ever had a good offshore call experience? Everyone I’ve mentioned this too has their own horror stories. Yeah, great, it cuts costs, but at what expense? Offshoring wouldn’t be so bad if it meant I could speak to someone who was actually technical. But what’s the point if I’m going to speak to someone who just reads a script to me.
Avoid TalkTalk at all costs.
Update 6/1/12: Inexplicably my broadband has now started working again, a full six days after it first broke. So much for “I can assure you sir there is no problem at our end”. A new router will be arriving soon, which I had to threaten I would cancel my account over to get for free (They wanted me to renew for 12 months). Honestly, I wish I could shove the thing up someone at TalkTalk’s arse.
-
I finally finished reading The Lean Startup. The main gist is that we need to be creating fast feedback loops for products/changes we make, so that we can quickly see what is and isn’t working. It’s a good extension of what to do once you have you minimum-viable product up and running, as it’s easy to fall into the trap of just adding features, without actually adding any value. I especially liked the parts on doing a cohort study of your users. Instead of measuring figures like engagement as a total for a specific time, you would track engagement for people who signed up in January only, then sign ups in February, then March, etc. This gives you a better picture of whether you’re actually improving your service or only appearing to improve because of growing figures.
Overall the book wasn’t too bad. I felt that perhaps the first half was a lot more “actionable” and my interest fell off once past the half way point, so I ended up just steaming through after that. Definitely worth reading if you’re in the startup arena though.
I’ll be getting another copy soon anyways as I’ll be seeing Eric talk when he comes to London in January.
-
This recent post from 37Signals reminds me a lot of the brilliant post by Derek Sivers on there being no speed limit.
It can be hard at times to know how hard you should be pushing or how fast you should be going. It’s easier to go with the flow rather than to push ourselves to see what we’re truly capable of.
-
My generic SEO strategy for a startup is a) be the best on the Internet for b) as many topics as you possibly can be that c) matter to your paying customers – Strategic SEO for Startups
Over the past couple of weeks I’ve been spending an increasing amount of time learning about SEO and how to go about applying it to our day to day business. There’s a lot of stigma attached to doing “SEO” and while a lot of it is very shady, once you learn how to do things properly, it’s not as dirty a subject as people would have you think. Personally I’ve found the whole learning experience absolutely fascinating.
It’s very easy to think that SEO is something you do to your site. Adding keywords, making sure things are tagged correctly etc, but the real meat of SEO comes before all that. Researching competitors, finding keywords to compete on and own, building trustworthy and relevant linkbacks, etc. The SEOMoz Beginners Guide is an excellent resource for learning the basics while the link at the top is a a great way of learning how to apply the concepts to your startup/site.
For anyone thinking of hiring an “SEO Expert”. Be extremely cautious. There are a lot of people out there dying to sell you their black hat techniques to drive your search engine performance up, there are also a lot of people out there who really don’t know what they’re talking about. If someone offering to give you advice doesn’t first ask to see your analytics and your content, but rather focuses on technical changes (especially things like LOC and embedded Javascript), I’d personally look elsewhere for help.
There’s no point having the best content in the world if people can’t discover it, and really SEO is all about making that content discoverable.
-
I’m generating PDFs with PDFkit/wkhtmltopdf on a current project. While the output is fine in the browser, £ (pound) signs in the generated PDF were showing up incorrectly as:
£The fix was relatively easy as PDFs have their own view layout, so all I had to do was add an extra meta tag to the head:
-
I recently had to serve a static file on a specific url in nginx. The requirement was that /sapm/jcb should show a specific page, but I of course forgot about the html extension so the end result was my file only appeared on /sapm/jcb.html.
An nginx conf change sorted it all out.
location /sapm/jcb { try_files $uri $uri/ /sapm/jcb.html; } -
Iceberg features are where on the surface they seem small and simple while backed by a huge un-seeable chunks of functionality and processes. Like their real counterpart they come in many different shapes and sizes. From the “Oh, just add an extra field to this form”, which in-fact impacts the business logic, to “Just copy this feature on site X”, without taking into consideration the processes that go on behind the scenes. I’m sure we’ve all experienced the first sort of “small change” problem before, but the second one is a lot more subtle and easy to miss.
A lot of sites successful implement a “invite your friends” feature, which grabs a user’s address book and messages each of them asking them to join. The simplistic way of copying the functionality is to think that the road to success is simply grabbing the needed details and messaging them, thinking that what makes the functionality successful starts with the form and stops with the initial message. That’s just the tip of the feature iceberg. Is it successful for another site as they have a planned out set of campaign emails they send out to an invited person, with timed followups and different possible campaign routes depending on a user’s reactions. It may well be that having a naive imitation of the feature is better than not having one at all, but it’s the compromise of deciding what to do. Is a poorly imitated, half implemented and thought out feature better than a smaller, but more complete and well thought out one.
-
Five monkeys are caged together and there are some bananas hanging from the top of the cage. Some scientists attach an automated device for sensing if the bananas are moved; once a monkey tries to get any, an electric shock travels through the cage so that all monkeys get shocked. In the beginning, a single monkey climbs up to the bananas, touches them and every monkey gets shocked. So he doesn’t try anymore, but the other four monkeys try the same thing and the result comes to be the same. Therefore, the monkeys learn something in common: that is, do not get the bananas! You’ll get a painful electric shock! The scientists then replace one of the original monkeys with a new one. This new monkey sees the bananas and wants to get them right away, but the other four monkeys beat it when they see its actions. Since these original four monkeys think the new monkey will make them get shocked, they stop the new monkey from getting the bananas. This monkey tries a few times and the others beat it every time without it ever getting the bananas. Of course, all five monkeys don’t get shocked. The scientists then replace another of the original monkeys with a new one. This second new monkey sees the bananas and you bet it wants to get them immediately. But, sadly, the others beat it and the first new monkey beats the newest one even harder then the others (for the newest one is the rookie and has the lowest social status). Just like before, the newest monkey tries several times to get the bananas and is stopped by the others when they attack him. The scientists continue to replace all the original monkeys until no monkeys who actually felt the electric shock remain. Now none of the five new monkeys dare to touch the bananas yet none of them know why. They only know whomever wants to get the bananas will be beaten.
Frequently I write about doing what matters most and not getting caught up in the stuff that makes the least amount of difference. The tale above is a great story that leads on from that; Making sure you know why you’re doing something.
This recently came up in a conversation about re-designing the homepage of viewshound.com. One person thought the front page should be laid out one way, while another thought it should be laid out another way. The problem was, neither answered the question of firstly, why the homepage needed to change and secondly, what did we want to achieve by changing it. The naive answer to the second point is that we want to “increase page views”, but really in essence the answer is a lot more in-depth than that. Are we looking to drive first time visitors to individual articles or are we looking to drive people to category pages? Are we optimising for new arrivals or optimising for frequent readers? Once you rule out these sort of low-level questions, the route you take becomes a lot clearer, and changes for the sake of making changes becomes a problem of the past.
-
“It blows me away every time I walk into a nice home and meet its proud, overweight, out-of-shape owner. They just don’t get it. Your real home is not your apartment or your house or your city or even your country, but your body. It is the only thing you, your soul and your mind, will always live inside of so long as you walk the earth. It is the single most important physical thing in this world you can take care of.” Mark Lauren
-
Imagine your business is a lovely big garden. You tend to the flowers, water the plants, and place your seeds carefully in the hope that a few months down the line they’ll blossom into a beautiful array of colours. But you don’t mow the lawn. As time goes by, your lawn gets overgrown and filled with weeds, eventually swallowing up all the hard work you put into your flower beds. Would you do this? Of course not, so why do we run our business like this then?
The lawn is the heart and soul of your garden. It’s plainest and simplest to maintain, but it is the easiest to neglect in favour of working on the things that are more attractive. Are you neglecting the core of what makes your business run, in favour of what’s more exciting? Blogs, SEO, Facebook, Twitter, Affiliates, Promotions are not your core concern. You need to be making sales. Don’t make the mistake of thinking this is how sales are made. They are fillers for an already churning sales engine. Pick up the phone, go and meet potential buyers. Start the engine of your lawn mower and mow your lawn.
-
I spent the day at Infusionsoft’s Customer Tour Conference. It was interesting to see some of the more advanced things that are possible using their product as well as listening to how some people are using it to market and sell their products. One of the things said during the day was in regards to sequences and moving user’s through a series of steps and goals, but which applies quite heavily to programming, which was:
“Build your process assuming the user won’t do what you want them to do.”
I found this quite a succinct quote and an excellent rule of thumb for when designing pages. Once you reach a certain size, your clout allows you the freedom to get away with less than stellar design choices. For instance, personally I think the Amazon site is a mess, and this was re-affirmed to me recently while trying to show someone how to go about ordering things from it.
When it comes to Amazon their reputation means a user is more likely to jump through hoops to complete their order, but for a never heard of site, any signs of hassle and they’ll be out the window and onto the next (Unless your offering is just so amazing they can’t resist). News and unheard of sites that are successful, “reduced friction” for their users. They seamless move users from one stage of a process to the next without having to make them think or accidentally moving them onto the wrong path. A good site needs to be more than a set of CRUD pages. It needs to be an experience that helps the user achieve what they want, in the clearest way possible.
-
I dreamt last night that a load of “business” people had been suddenly injected into our company. I got into an argument over the difference between two different hosts, stating that they are the same while someone else jumped in stating that they are totally different while citing various technical reasons, that really made no difference to the delivery of the project.
A while back I turned down working on an idea some acquaintances had because I didn’t have time. It ended up that someone else I knew took up the project. When first going over it myself I remember thinking a pretty much complete MVP could be done in a month or so, but last I heard, the other developer was still working on the project backend framework a few months in, with no basic site or anything in sight.
This is a common problem with starting a new site. It’s easy to get bogged down in the technical aspects while missing out on delivering actual usable software. I always remind myself of the General Patton quote “A good plan violently executed now is better than a perfect plan executed next week” and so the same stands for programming. Better to launch something sloppy today, than something perfect in the future. If the project is successful you can alway incrementally improve the code you rushed in. If the project’s a flop, you’ll know a lot sooner.