Anticipating the need to find video content online, the major search engines (Google, Yahoo and Bing) have created their own video search engines. These spider the web for unique video content and publish it in their video sections.

An interesting and cool result of this is that, instead of posting normal text listings, the search engines publish thumbnail screenshots of the videos on the search engine results pages (SERP). The thumbnail enables users to see what kind of video they can expect to see, before actually viewing it.

Universal search — a system that blends image, video, news, blog, local and traditional search to form a more complete experience and result set — is now integral to all three major search engines. Listings that have video thumbnails have been proven to receive a much higher click-through rate than traditional text listings.

So, how can you get your pages listed with video thumbnails?

1. Embed your video onto your web page using any number of methods. For example, you could use Flash video, Windows media video, Quicktime, Ogg Theora amongst others. As a point to note, you shouldn’t use a third-party video site — such as YouTube, Vimeo and DailyMotion — for this; the video must be unique to your website.
2. Create a thumbnail of the video for indexing.
3. Create four meta tags on the web page that displays the video:

   <meta name="medium" content="video" />
   <meta name="video_type" content="application/x-shockwave-flash" />

   Replace application/x-shockwave-flash with whichever video format you’re using.

   <meta name="video_height" content="280" />
   <meta name="video_width" content="460" />

   Replace the height and width dimensions with those specific to your video.

4. Create a video sitemap and submit it to the search engines. Google and Yahoo have a clear video submission process, whereas Bing does not, so you should submit to Bing in the normal way.

If your page is already in position one for a keyword, that listing will gain a thumbnail once you have optimised it for video. You’ll also get increased time on site and possibly page views, afterwhich you can develop a better conversion-rate strategy.

The decision to utilise a sub-domain, sub-directory or even a microsite is simply an architectural decision, but one that is often compounded with a marketing decision. In general, sub-directories are used to describe what individual pages are about while sub-domains and microsites are used to describe what an entire site is about.

When to use sub-directories

• Sub-directories are useful for organising content into meaningful groupings with descriptive URLs. If you have a meaningful taxonomy, then sub-directories are a good way to make your URLs more search friendly.
• For relatively small websites, i.e. not the BBCs and CNNs of this world, keeping your content in one place will help your website build trust and authority. The more trust and authority a website is able to garner with the search engines, the easier it becomes to rank new and related content.
• For the less technically savvy, sub-directories are easier to manage than sub-domains since they are generally created as part of the website’s page hierarchy. Furthermore, many CMSs don’t support the ability to publish across different domains out-of-the-box.
• Google Webmasters tools allow you to set basic geo-location preferences to sub-directories. The idea is to create new pseudo-website listings that also include sub-directories. For example, the www.domain.com listing could have www.domain.com/uk for the UK, www.domain.com/es for Spain and so on for each geographic location.

When to use sub-domains

• Sub-domains are useful for organising content that is otherwise unrelated. Take Google for example, they have a news product at news.google.com, a maps product at maps.google.com and a email product at mail.google.com. Since they are fundamentally different from each other and Google’s main search product, they aren’t held under the same domain.
• Sub-domains allow you to target regional markets more effectively. Sub domains are easier to market to specific geographical regions. For instance you can assign an IP address to a sub-domain and set a geographical preference in Google’s Webmaster tools for each sub-domain (sub-directories can have their geo-preference set but can’t be assigned an IP in another country, which might also be a signal of geo-location). For example, the www.domain.com listing could have uk.domain.com for the UK, es.domain.com for Spain and so on for each geographic location.
• If you already have a well established domain and want to expand out into other areas not completely related to your main website’s activities then a sub-domain may well be a good option. At the same time, people associate the sub-domain with your main domain’s brand, which means it can be easy to build up momentum on a vertical related to your main site. This is what the web giants Google and Yahoo, Sky and the BBC do successfully, but smaller websites can do the same. You often see this when the third-party functionality is “plugged into” an existing site, such as a payment gateway, events and job boards.

When to use microsites

Like sub-domains, microsites have an important position in the overall debate.

• If you have a new product or service that you potentially want to sell off or brand completely differently from your main business offering, a microsite makes a lot of sense. Microsites are really just a stripped down website, but as the product or service develops, so will the website and associated brand and it will take on trust and authority of its own.
• Microsites offer the ability to completely separate your main brand from the new product, service or promotion. This is useful if you’re pushing a content piece that has little to no association with your site and you don’t want the potential branding confusion or commercial association to hinder link and user growth.
• Microsites can be powerful if you have an exact match domain name for a particular keyword you’re targeting. Google’s preference for and ranking exact-match domains is a very powerful tool to use for SEO.

For a beginner, Google AdWords can be a little daunting to start with, so below I list some tips and tricks that have served and continue to serve me well whenever I setup and manage a campaign.

1. Don’t use broad keyword matching — At least not to start off with. What’s broad matching? “If you include general keyword or keyword phrases-such as tennis shoes-in your keyword list, your adverts will appear when users search for tennis and shoes, in any order, and possibly along with other terms.” With expanded matching it becomes even harder to know when your keywords will show, because Google will pick them algorithmically. Broad match is usually used by experienced advertisers looking to save time (usually with a long list of negative keywords) or by lazy advertisers, who may not have the time or the inclination to target their campaigns. Broad matching can also be the right way to go for parts of certain kinds of campaign, but wading straight into it can be dangerous.
2. Use dynamic titles in your adverts — Dynamic titles are easy, they don’t cost anything and they usually have a good effect on CTR and conversion rates. The phrase that the searcher uses in their search will come up as the the title of your advert. This saves you having to create an individual advert for each keyword and means that your ad will be more targeted. In the title field of your ad simply put {keyword:your default title here}. The default title is in case the search phrase is too long for the title field or if AdWords can’t display the search for some other reason.
3. Use global negatives to prevent advert duplication — If you’re selling something, you don’t want people finding your advert if they’re searching for free stuff. This sounds obvious, but do some searches and you’ll see it happening. Use the word ‘free’ in your campaign global negatives. You can also use this for other words you don’t want to turn up for. Using negative keywords is especially important if you’re using broad matching.
4. Turn off content targeting and search network — Do you know where to look at these adverts? If the answer is a resounding “no”, leave them alone until you feel confident that you know where they’ll be showing and that you can make them work — get comfortable with Google SERPs first. Conversion rates and CTR‘s change dramatically for each search property, not to mention content targeted adverts. Get acquainted with Google before you move on to the others.
5. Test different advert-copy and positions — How much of a difference will being in the first position, as opposed to the second, third or sixth position make, for your net profit? The answer is that it depends on your creative, industry and who else is bidding on your keywords. The bottom line is that you should know. Test your creative in each position and work out where it will be most effective, from an ROI point of view. Remember also that the AdWords ranking algo works on a CPC x CTR basis (it’s actually more complicated than that, but that gives an idea as to why out of two adverts with similar CPC‘s, one will be higher because of a higher CTR.) You can also test your creatives. Write several different adverts and set them to run evenly (Google will run the one which preforms best by default, but you can set them to run evenly in your campaign settings). The creative which gives you the highest ROI is the one you should go with. You should probably run this kind of test for more than just a day.
6. Optimise your destination URLs and landing pages — The landing page is the page which the person who clicked on your advert will see when they come through to your site. Don’t use your homepage as your landing page unless it deals only with selling the product you’re advertising. For example, if you’re selling widgets, optimise a page on your website with information regarding that widget, this could be a product page on your website, or a specific page for the advertising campaign.
7. Track conversion and ROI — Track everything. Google will track impressions, clicks and click through rate. Just because an advert has a high CTR doesn’t mean that it is making you money. Use Google’s own conversion tracking codes and link AdWords with Analytics. If you don’t know how each keyword is preforming, then you won’t be able to optimise your campaigns. Turn off the keywords that aren’t working well and invest more in the keywords which are.
8. Work out your CPA — How much is each sale costing you? Are your Google AdWords listings preforming as well as your Yahoo! listings? Your Bing listings? Your offline marketing? You should know how much you’re paying for each order, sale, download or enquiry on each channel — only then will you be able to set CPA targets to work towards and know which channel is best for you.
9. Don’t enter into bidding wars with your competitors, find a niche — It is easy to get into bidding wars with your competitors. You want to be number one and so does your competitor. The best thing to do is to take a step back, ten deep breaths and consider how important it really is to be in the number one spot. If you can justify it, fine but otherwise: let your competitor be number one, slot into the number two slot and wait. If you have a better product, your click-through rate will get you to the top – and you’ll still be paying the same as you were in the second position. More and more people are using automated bidding software. This software will update at a set interval to keep the ad in the desired position. Doing battle with this kind of software is even more frustrating and less rewarding than trying to outbid a competitor.
10. Set a weekly budget and stick to it — When you’re first starting out this is really important. AdWords is addictive, and like anything else addictive, it can quickly get out of hand. A keyword may convert like nobody’s business one day and die the next. Make sure you know a keyword is working — more importantly, know why it is working — before you invest more.
11. Geo-target your adverts — Geo-target your adverts to the relevant audience. It can be done when you set up a new campaign and in your campaign settings. If you want to show on google.com that’s fine, but remember that you can geo-target to individual countries and even cities (you can target regions in the US, UK, Canada, France, Germany, Italy, Japan, Spain and the Netherlands). The more targeted users feels that your ad is, the more likely they are to click on it.
12. Organise your adverts into logical groups — This will make it easier for you to know what is doing well and what isn’t — especially a year later. If you’re selling widgets have a campaign not just for widgets, but for each brand of widget, and then an ad-group for each widget model.
13. Keep a close eye on what your competitors are doing — Is your competitor doing something better than you? What keywords do you share with your competitors? Can you discern their strategy? Do they use automated bidding software? Do their landing pages have some magic which you should be emulating? This is the sort of information you can find out and the kind of information that you need to know.

If there are inaccuracies in the above list, just give me a shout, otherwise, I’m happy to hear your own tips and experiences.

Google’s addition of a page speed signal to its search rankings algorithm officially links performance with search engine marketing. The loading speed of a web page affects user psychology in a number of ways, and now it can effect its rankings as well.

From the Google Webmasters’ Blog:

Speeding up websites is important — not just to site owners, but to all Internet users. Faster sites create happy users and we’ve seen in our internal studies that when a site responds slowly, visitors spend less time there. But faster sites don’t just improve user experience; recent data shows that improving site speed also reduces operating costs. Like us, our users place a lot of value in speed – that’s why we’ve decided to take site speed into account in our search rankings. We use a variety of sources to determine the speed of a site relative to other sites

If you are a site owner, webmaster or a web author, there are some free tools that you can use to evaluate the speed of your site and therefore improve site performance:

• Page Speed, an open source Firefox/Firebug add-on that evaluates the performance of web pages and gives suggestions for improvement.
• Yahoo! YSlow a Firefox/Firebug Add-on that analyzes web pages and suggests ways to improve their performance, based on a set of rules for high performance web pages.
• WebPageTest shows a waterfall view of your pages’ load performance plus an optimization checklist.
• BrowserMob a tool for website performance monitoring and alerting.
• Chrome Developer Tools that let you edit, debug, and monitor CSS, HTML, and JavaScript live in any web page. You can also use them to optimise web page performance by profiling CPU and memory usage.
• Google’s Webmaster Tools, in the Labs menu, Site Performance shows the speed of your website as experienced by users around the world.

Other tools, including those for web debugging (Charles and Fiddler) and resource optimisation (Smush It and YUI Compressor), can be found on Google Code.

Google’s announcement of adding a page speed signal into its search rankings algorithm will in the long term will force the hand of website owners to increase the performance of their websites. This can only be a good think for user experience. With time and investment, the frustration of slow-loading websites will be banished to the past.

Apache 2.x uses mod_deflate. Much like setting expires headers, this will save you bandwidth and server load, because it allows output from your server to be compressed before being sent to the client over the network.

The deflate module is not compiled by default and must be enabled in the Apache httpd.conf file. Make sure the following is present and uncommented (remove preceding the #):

LoadModule deflate_module modules/mod_deflate.so

To set GZip compression, simply add the following to the section of your Apache vhost configuration:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Alternatively you can add it to your htaccess file in an <ifModule mod_deflate.c></ifModule> block.

All you really need is the first line. The BrowserMatch lines are there to handle issues with older browsers such as Internet Explorer 5.

You can read all about GZip by reading Yahoo!’s Best Practices for Speeding Up Your Web Site guide.

Alternatively, read the Apache mod_deflate documentation.

The timing of this is quite intriguing following the recent hacking attack, supposedly orchestrated by the Chinese authorities, on Google, Yahoo, Adobe and some 20 other major international corporations; whilst there is also the ongoing concern from many quarters about Google is too dominant in many aspects of our online lives.

But less of the cynicism, the five principles are:

• Use information to provide our users with valuable products and services.
  Focus on providing the best user experience is the first tenet of Google’s philosophy. When users share information with us, it allows us to build services and products that are valuable to them. We believe that focusing on the user fosters both the products and privacy-enhancing features that have fueled innovation and built a loyal audience of users online.
• Develop products that reflect strong privacy standards and practices.
  Our ambition is to be at the leading edge of technology, including the development of tools that help users manage their personal information in a simple, accessible manner without detracting from a valuable user experience. We comply with privacy laws, and additionally work internally and with regulators and industry partners to develop and implement strong privacy standards.
• Make the collection of personal information transparent.
  We strive to show users the information used to customize our services. Where appropriate, we aim to be transparent about the information we have about individual users and how we use that information to deliver our services.
• Give users meaningful choices to protect their privacy.
  People have different privacy concerns and needs. To best serve the full range of our users, Google strives to offer them meaningful and fine-grained choices over the use of their personal information. We believe personal information should not be held hostage and we are committed to building products that let users export their personal information to other services. We don’t sell users’ personal information.
• Be a responsible steward of the information we hold.
  We recognize our responsibility to protect the data that users entrust to us. We take security issues seriously and work together with a large community of users, developers and external security experts to make the Internet safer and more secure.

Whether these principles can be fully adhered to by Google is an important question, but they do serve to calm the fears of many about what they’ll do with our data. If nothing else, they do serve to highlight the need for data privacy to be taken seriously by anyone considering building web applications.

If you’re interested in more of Google’s privacy stances, they’ve got an entire portal dedicated to them.

The Internet is not simply a big place it is a huge place; new content is being created all the time. Google, Yahoo and Microsoft each have a finite number of resources, so when faced with the nearly-infinite quantity of content that’s available online, their various crawlers are only able to find and crawl a percentage of that content. Then, of all the content they’ve crawled, they’re only able to index a portion. Of course with the cheapness of storage, the search engines are able to index more and more content each day, but not at the pace the Web is growing.

URLs are like the bridges between your website and a search engine’s crawler: crawlers need to be able to find and cross those bridges (i.e., find and crawl your URLs) in order to get to your site’s content. If your URLs are complicated or redundant, crawlers are going to spend time tracing and retracing their steps; if your URLs are organised and lead directly to distinct content, crawlers can spend their time accessing your content rather than crawling through empty pages, or crawling the same content over and over via different URLs.

So, what can you do as a website developer or owner to reduce that labyrinth of URLs and helping crawlers find more of your content faster? Below are a few ideas:

• Remove unnecessary query string details from the URL.
  Parameters in the URL that don’t change the content of the page–like session IDs or list sort orders–can be removed from the URL and put into a cookie. By putting this information in a cookie and 301 redirecting to a clean URL, you retain the information and reduce the number of URLs pointing to that same content.
• Stop infinite pagination in, for example, lists and calendars.
  If you have a calendar with infinite past and future dates or a list with infinite pagination you have what is described as an infinite crawl space, which is a huge burden on crawlers. To resolve the calendar issue, you can add no-follow attributes to links to dynamically created future calendar pages. When creating pagination links, disable previous and next links when the first and last pages are reached and redirect users to an appropriate page if the query string in the URL is hacked (this may be a page not found static page).
• Utilise the robots.txt file to prevent actions the web crawlers can’t or shouldn’t perform.
  Using a robots.txt file, you can disallow crawling of login pages, contact forms, shopping carts, and other pages whose sole functionality is something that a crawler can’t and shouldn’t perform. This lets crawlers spend more of their time crawling content that they can actually do something with.
• Prevent duplicate content.
  An ideal scenario for crawlers is a one-to-one link between content an a URL. Each URL leads to a unique bit of content and each piece of content can be accessed by a unique URL. The closer your site can get to this scenario, the more streamlined your site will be for crawling and indexing. If your CMS makes this difficult to achieve, you can use the canonical tag to indicate a preferred URL for duplicate content.

More information on this topic can be found on the Google Webmaster Central Blog.

Carpe diem on any duplicate content worries: we now support a format that allows you to publicly specify your preferred version of a URL. If your site has identical or vastly similar content that’s accessible through multiple URLs, this format provides you with more control over the URL returned in search results. It also helps to make sure that properties such as link popularity are consolidated to your preferred version.

But what do they mean by canonical? One of the definitions of canonical is reduced to the simplest and most significant form possible without loss of generality.

What this means is that if you have a page–let’s take an e-commerce product page–and the simplest URL that you want it accessible by is:

http://www.site.com/category/product.html

you can add the canonical tag to that specific product. Google, Yahoo and Microsoft use this tag to tell their search engines which URL it should have for the current page.

Now, let’s say that the particular software you use also allows you to access the same product using:

http://www.site.com/company/product.html

and

http://www.site.com/different_category/product.html

Perhaps this one product is in multiple categories. With this tag in place when any of the alternate pages are loaded this tag notifies any search engine that this is really the same product as the page you defined in the canonical tag. So, you are still allowed to have the content available as generally needed (by categories, tags, or some other organisation system) and still avoid having the content duplicated and penalised.

To implement the canonical URL tag in your web application, you simply need to do the following inside the <head> section of the duplicate content URLs:

<link rel="canonical" href="http://www.site.com/category/product.html" />

As Google mention, this tag is a hint that they honour strongly. Google will take your preference into account, in conjunction with other signals, when calculating the most relevant page to display in search results.

Apache Ant is a software tool for automating software build processes. It is similar to Make but is implemented using the Java language, requires the Java platform, and is best suited to building Java projects. However, that doesn’t mean it is restricted to Java projects. I use Ant increasingly for all my web development projects as it is an integral part of Eclipse, my IDE of choice. It makes building applications and releasing them across different servers far more efficient and less problematic.

When I start a new project, after creating the folder structure, I create the Ant build file. Ant defines the build process and must be used by every developer working on the project. All of the tips in this article assume that the Ant build file is extremely important, must be written with care, and maintained in version control and re-factored periodically, when the project dependencies change.

Ant uses XML to describe the build process and its dependencies. By default the XML file is named build.xml. This makes it really simple for you setup and edit different build processes. However, since Ant is relatively simple to set up, you need to follow a common set of best practices. Some of these best practices were inspired by mistakes made on previous projects, or ideas passed on to me by other developers.

Automate absolutely everything

Ant is a powerful tool. If you choose to use it, get it to do absolutely everything. Ant can integrate with your source control databases such as Subversion (SVN), run SQL scripts, change file permissions, send files across FTP, zip and un-zip files, and many more tasks besides these.

If you use Ant, only use Ant

Use Ant as a common baseline. Regardless of what IDE you use to develop your applications, set up an Ant build file that all team members use. The build.xml file is the one true build script. Make a rule that everyone should perform a successful Ant build before code is checked into version control. This will ensure that code will always build from the same build file.

Follow consistent conventions

Ant expects your build file to be called build.xml and the build’s properties file build.properties. These files should also be in the root directory of your project. Other than an insane desire to change convention and confuse other team members, don’t change this convention. Another less-well-known convention is to prefix all internal commands with a hyphen (-). It has the advantage that it is not possible to invoke targets that follow this naming convention, from the command line.

Spend time formatting the build file. Since XML is quite verbose, use tabs and line breaks to make the file readable to the human eye. Ant itself doesn’t care if the file looks pretty, but you can bet that you and your team will.

Pick meaningful, human-readable names for targets and properties. For example dir.reports is better than simple rpt. The specific naming convention is not important, beyond being meaningful to your organisation. For example, I use the following:

deploy.local
deploy.dev
deploy.test
deploy.live
-build
-clean
-concatenate
-minify
-prepare

The -concatenate and -minify commands are specific to web projects, the later using the Yahoo compressor library to minify CSS and JavaScript files.

Provide a clean target

Every build file should include a target that removes all generated files and directories, bringing everything back to its original pristine state. All files remaining after the clean should be those found in version control.

An example clean command could be as follows:

<target name="clean" description="Deletes all generated files and directories">
	<delete dir="${dir.build}" />
	<delete dir="${dir.dist}" />
</target>

Use build files for all stages of the development process (development, staging and production)

Ant standardises your build and release cycle. Therefore use it for all stages of the development process. Use it for releasing code to your local development server, your staging or user acceptance testing server and your production server. The different deployments can obviously differ slightly based upon the needs, i.e. your production build need not include the creation of dummy data, but may include a call to source control.

Make build files self-contained

A build file that relies on external dependencies is one that will be difficult to configure or has the potential to cause problems. If your build depends on additional tools, put them in your source control repository. I generally include a lib for all dependencies in my project root. This folder includes such files as the Yahoo Compressor or JSLint.

Prefer a single build file

It is possible to split the build up into several small build files, each of which is responsible for a small proportion of the overall build. This isn’t always the best idea! Breaking the build often makes it harder to comprehend the whole process. It is better not to over-engineer the project and keep to a single, well formatted build file.

If your project is split into different build files, there should always be a master build file, found in the root directory of the project, even if it only delegates actual work to subordinate builds.

Put the build.xml file in the project’s root directory

The Ant build file can reside anywhere in the project tree, but conceptually it makes sense to put the file in the project root. This keeps things clean, simple and somewhat obvious to new members to the project. Having a build file in the top-level directory also makes it conceptually easy to see how relative paths point to different directories in the project tree.

When the build.xml file is in the top-level directory, you can compile code from the command line without the need to change the working directory.

Modularise your project

Arrange your project into coherent self-contain modules.

The following shows how I typically arrange my project files.

[root directory]
	/docs
	/lib
	/src
build.properties
build.xml
task.properties

The docs folder contains project documentation, the lib folder contains libraries specific to the project and required by Ant (generally this is a link to repository containing a number of utility JAR files, such as those for SVN and FTP). Finally, the src folder contains the actual project files.

Use version control

It is important to use version control for your entire project. The build file is an important artefact that needs to be versioned along with the source code of the project. When you tag a build for release, the build file should also be included. If you then need to roll back to a previous release, you will be able to build the code based upon the build file used for that particular release (after all, build files develop along with changes to the source code).

Third-party JAR and executable files should also be maintained in your local version control. This makes it possible to recreate previous releases, after all third-party libraries are likely to develop and change as frequently as your own code. If you want or need to take advantage of these changes, it is necessary to version control the older versions.

Avoid including build output in version control. Provided that you use version control correctly, you will be able to recreate these files at a later date.

Include comments in the build file (self-documenting)

Make the build file self-documenting. Adding target descriptions is one way to achieve this. For example:

<target name="clean" description="Deletes all generated files and directories">

Internal targets should not include description attributes. Internal targets may include targets that perform immediate processing, such as file concatenation or minifying.

Another way to include help in the build file is the echo tag. You can put any amount of comment between these tags and the information is printed to screen. For example:

<target name="clean" description="Deletes all generated files and directories">
	<echo>Cleaning project...</echo>
	<echo>Deleting build directory...</echo>
	<delete dir="${dir.build}" />
	<echo>Deleting dist directory...</echo>
	<delete dir="${dir.dist}" />
</target>

Summary

By using Ant and creating and maintaining build scripts for a project, the reliance on ad-hoc manual procedures for compiling and creating websites is removed. Using a defined process with Ant, or similar build tool, removes errors across the entire project, whilst allowing teams to develop code more efficiently.

References

Holzner, Steve (2005). Ant: The Definitive Guide, 2nd Edition, O’Reilly, ISBN 978-0-596-00609-9.

Apache Ant – http://ant.apache.org

• Don’t reinvent the wheel unless you really have to. Borrow code and ideas from elsewhere whenever it makes sense. The web community it great at sharing, just look at the various JavaScript libraries, the huge quantities of APIs or indeed the major players’ developer areas: Google Code, Yahoo! Developer Network, Mozilla Developer Center, Adobe Developer Connection and Dev Opera to name five I regularly refer to.
• Things should be as simple as possible, but no simpler (Einstein). This idea is really born out of and emphasised by 37Signals’ Getting Real book. Commonly, 90% of people using an application only use 10% of it’s functionality. The key therefore is to find what people use most often and only build that functionality. If there is a requirement to add more, then sobeit. This can also apply to the code-level, the essence here being a balance between over- and under-engineering something.
• Do one thing well (The UNIX philosophy). It is better to do one thing well, than several second-rate. This could be at the code level — think encapsulation, coupling and cohesion — or indeed at the application level — you’re never going to beat Microsoft Word, but Google and Zoho have developed compelling alternatives, but with far less features.
• Don’t fret too much about performance — understand how to write efficient code and plan to optimise later if or when needed.
• Don’t try for perfection because good enough is often just that. This of course is a matter for conjecture. If I were working on a personal project, I may be more stringent on perfection than say, for a client’s application. This doesn’t mean to say the client’s application would be any worse, but rather it is a question of dotting-the-is and crossing-the-ts. It also depends on your perspective and what gains can be made by aiming for perfection.
• (Hence) it’s okay to cut corners sometimes, only if you can do it right later. I rarely adhere to this! It makes sense to do it right the first time, since bodge-jobs often come back to haunt you and result in double the effort!
• Don’t fight it; go with the flow. This is somewhat clichéd, but the essence behind this is try to avoid getting stressed out. This isn’t always easy to achieve, but taking a step back from a situation and avoiding politics is important.

I often strive for perfection, which isn’t an entirely clever pursuit since it is almost impossible to achieve. However, in a realm of imperfection, the principles above have helped me to achieve a modicum of decent code throughout the years. They may also resonate and provide inspiration for you.