Tuesday, June 10, 2014
Do what you love and you’ll never work a day in your life - Confucious
Do you like your current job but dream of something better? Or perhaps you go to work and are constantly thinking about your side project, or hobby. This could be a sign you are in desperate need of a career change.
This happened to me. I was a successful retail manager, first at store level and then managing a group of stores for a large electronics chain. Life was good. I was earning great money, being challenged and building high performing teams. But I would get home in the evening and program my computer. The next day, I would be thinking about how to improve the program I was writing. In the car I would listen to podcasts about programming practices and freelancing. This went on for years.
I had worked for this company for 18 years. I was regarded highly and sent to ‘Future Leaders’ training programs to further my career. But towards the end, I had begun to imagine a life out of retail. About being happy doing what I actually loved doing. Programming computers. I wasn’t unhappy in retail. Or regretful of the opportunities it had given me. I was just beginning to be mindful that it perhaps wasn’t my destiny.
One day I just did it. I just typed out a resignation letter, gave a lengthy period of notice (I didn’t want to leave on bad terms) and finally, left. It was a sad day. I was leaving the known and entering the unknown. Out of my comfort zone completely. I had a family to support and did not really have a solid plan on replacing my current income. I had decided to become a freelance web developer. Out of a handful of contacts I began to get some minor jobs. These progressed to major projects and eventually to my current role. Today I manage a web team and code most of the time. Its pure bliss, combining my love of programming and system architecture with my experience in developing people. It would not have happened had I not realised that I could change my career whenever I wanted.
I realise that for a lot of people a switch like I describe may not be financially or otherwise feasible. But don’t give up. Pursue the job of your dreams. One that you bounce out of bed for in the mornings.
Saturday, May 03, 2014
Barry Levine, writing in VentureBeat
…one idea in the new Chrome 36 version of Canary is to bury the full URL into the top-level domain name. Even navigating within the site shows only the site name.
I’m not sure how I feel about this yet. I love seeing URLs. But could probably get over it.
Tuesday, April 29, 2014
More testing wisdom from DHH
Above all, you do not let your tests drive your design, you let your design drive your tests! The design is going to point you in the right direction of what layer in the MVC cake should get the most test frosting.
Worth a read.
David Heinemeier Hansson on why he feels Test Driven Development is not all it’s cracked up to be.
I don’t think that’s healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that’s “slow”. Like hitting the database. Or file IO. Or going through the browser to test the whole system. It’s given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.
Whatever his views, the one thing he is not saying is to stop testing. Just be more careful in what and how we do test. Keep testing. Always.
Sunday, September 01, 2013
Print design is about how it looks. Web (and product) design is about how it looks and about how it works. They are different.
Wednesday, July 20, 2011
Use of a particular operating system on any platform is largely a matter of personal choice. Sometimes, that choice is made by a business or corporation on behalf of their employees, and other times, individuals can make the choice themselves. I’m often seen tweeting or facebooking the virtues of Apples operating systems and products, often citing increased sales statistics or my own experiences in my message that Apples products give me a better experience than any of the alternatives. However, I often see mention that Android must be better because it has a higher market share. Or Windows is king because it has a higher market share. Higher market share does not always mean better product. A number of variables play part in determining market share. There are many cases where a product with lower market share, is simply the better product.
I will use the analogy of the car market. Australias #1 selling car, the Holden Commodore, sold 45,956 cars in 2010 (in Australia). Ferrari, on the other hand, sold 6,573 cars last year (worldwide). That’s an almost 7 times increase between one model of car from one manufacturer compared to every single car sold from another. A classic example of a better product (in terms of experience, luxury, and in most cases performance) having a lower market share than a competing product.
It is not business rocket science for a vendor to saturate a market with cheap product and grow market share. Selling cheap android handsets is a clear example of this. Numerous reviews have showcased the horrible experience a cheap android product provides. Yet, people continue to quote Androids stunning market share growth as a clear example of a superior product. Not so.
A similar case can be made for the ongoing debate of whether Microsoft Windows operating system is better than Apples OS X. A windows PC can be bought for a mere $199. The same is not true of Apple hardware. It stands to reason that Windows market share will be higher. This does not mean that it is a better product. If you’ve ever had a blue screen of death, had to re-install due to a slow down, or the computer crashing or catching a virus (even though you already had an anti-virus installed), then you will know what I mean.
So, next time you hear “High Market Share means better”, have a think about all the factors that have contributed to the market share number. Product quality and overall joy of use may not rank high in contributing factors, and it may in-fact be a terrible product to use.
Wednesday, June 29, 2011
I must admit, I probably didn’t test my code as thoroughly as I ought to have. Let me re-phrase that. I did test it. I just didn’t write complete test cases to ensure regressions weren’t introduced when new bits were added. As a result, maintenance always took longer than it should have, and bugs were introduced when changes were made. Even though I had read and studied the importance of testing very early in my software development career, it was only after continued frustration with things breaking that I got off my butt and actually started using testing practices like TDD, BDD and even writing tests for code that had already been written. I made it a goal to have the code as covered as possible.
Initially it took way longer to write code. Way, way, way longer. I did get frustrated. I questioned if this was really the way to go. But in the end, I got quicker at writing tests. I more often than not wrote the tests first. And things were good. If things broke, I wrote a test, fixed the bug, tested the entire app to ensure I didn’t break anything else. And things were good. I’m now very much an advocate for testing and consider it probably the most important skill in my software development bag.
I recommend reading the post by Ryan Bigg. It covers some other points in relation to testing, especially the economic and financial implications both personally and to an organisation when testing is not a priority.
I’ll follow this post up with some tips on how to add tests to a Rails project that has none. I think this is a very under documented process and one that will help many people that have existing projects that they understand very well, and adding tests will give them the confidence and knowledge to use tests when they start a new project.
Sunday, March 06, 2011
A few weeks ago, I finalised some new code for a new section of an existing website. I always code websites using web standards and always test on the latest versions of Chrome (v10), Safari(v5), Opera(v11), Firefox(v3.6) and Internet Explorer(v8). In the case of the latter two, I test both the current version and the upcoming version. So the site is also run through its paces on Firefox 4 and Internet Explorer 9. As for mobile, I test on iPhone and iPad too. As you can see, it’s a pretty comprehensive test. However we began getting customer feedback that they couldn’t log in to the new section of the site.
I looked through the logs and couldn’t even see that they’d made an attempt to login. Very weird. I went back to the tests and everything worked. Then some users were able to log in. But the majority couldn’t. We started to get some screenshots and feedback and discovered that it was a browser issue. Internet Explorer 7 to be exact. The jQuery login popup we had implemented didn’t render correctly on the old Microsoft browser. Hence it didn’t work, and no entry was made in the logs, as the customer wasn’t even able to submit the form.
I had a look at the analytics data for this group of users and found that 89% of them were using Internet Explorer 7. A browser not in my test suite but used by the vast majority of our users (of this part of the site). The fix was easy once we knew the problem. And all customers can now log in.
Suffice to say that Internet Explorer 7 is now part of our test suite. We don’t test that things “look” the same. We just test that the site “works”. Internet Explorer 7 has 5.7% of the worldwide market share, and Internet Explorer 6 has 3.8%.
But the main lesson learned, is that when developing for a closed group (like an intranet or a internet site that is locked to certain users), make sure you know the browser statistics data. Not only will it ensure that what you’re developing works, but it also provides the opportunity to give them a better experience through harnessing the power of that particular browser.
Friday, February 18, 2011
Facebook is like fashion. It never ends.
I was watching..or re-watching….The Social Network the other night and my ears pricked up as I listened to some dialogue between a young Mark Zuckerberg and his equally young financier, Eduardo. They were celebrating the fact that The Facebook was about to “go live” and Eduardo asked if the site is “finished”. Mark shot back, “It’s never going to be finished. Facebook is like fashion. It never ends.”
Not quite sure if Zuckerberg ever actually said that, but it’s an interesting and bold point, not just for Facebook, but all web sites or web applications. I’ve always been a big believer that a website is a continual improvement process. Sure you can launch and leave it. But the site then becomes stale. It’s design becomes stale, its content becomes stale. And visitors stop coming back.
How many sites have you been to lately where the “news” section was last filled in 3 years ago. Where the site looks odd when you look at it in on your smart-phone? These are the sites that suffer from “launch and leave”. Like a neglected yard, the weeds start accumulating and people just see your site as a wasteland.
Often times, we as designers/developers, need to share the blame for this with our clients. We build sites to a budget that doesn’t take into account ongoing maintenance, post-launch reviews, or even educating the client on how best to keep the content on the site fresh. And I think it is up to us in the design/development community to lead the way in, at a bare minimum, communicating this message to our clients. Keeping them educated on the pitfalls of stale content, on the importance of re-visiting the site for design updates on an agreed interval, or reviewing that the site is keeping up with the goals it was originally designed to meet. Surely these points are something we should be looking forward to doing, not shying away from.
A young Mark Zuckerberg was right, and had he left Facebook as it was when it originally launched, it wouldn’t have over 500million regular users that it enjoys today. Websites are like fashion. Never finished. Never done.