Tagged with "blog"
Cheat Sheets
No cheat sheets were found matching this tag.
Articles
Mutual Blog Promotion
Commenting on blogs is an essential part of most low budget marketing strategies, especially when promoting blogs. Plenty of people automate blog commenting, spamming thousands of blogs with worthless generic comments. There is a better way, of course.
Online Marketing for Beginners
Wondering why you should hire someone to market your website and how they should go about doing it? Hopefully this article can help.
Jargon Explained
Many of my clients have worked previously consultants and SEOs that inundated them with jargon, especially where proposals and sales calls are concerned. I find myself sometimes using too much jargon - easily done when you spend so much time working in any field. This jargon guide explains the industry terms in simple language.
Blog Posts
What Makes a Great Developer?
What makes a truly great developer? Some might say a positive attitude. Some might say a high-sugar, high-caffeine, high-bacon diet. Some might say an absence of sunlight and as many monitors as a desk can support.
Certainly, everyone has anecdotes about developers they've worked with who they thought were brilliant. Unfortunately, most of the time that judgement is made not based on code quality, or hitting of deadlines, but on less relevant criteria, like whether or not the developer knew the names of their colleagues, how many lines of code they output or how confident they sounded when talking about their work.
Unfortunately, the best developers don't always come across positively. While this list may not be applicable to every development environment, here are a few of the traits to look out for to spot a great developer.
Pessimistic
Great developers are almost always pessimistic with regard to their work. That doesn't mean they're not upbeat, lively or even cheerful - just that they will always be thinking about what can go wrong and how it can be dealt with.
They'll assume that at some point they'll need to undo work already completed, that hardware will fail, that all security will be compromised, and that your office will burn to the ground. The really brilliant ones will assume that will all happen on the same day. And they won't be happy until there is a specific, actionable, testable - and fully tested - plan for dealing with these sorts of issues. Even then they won't be completely happy.
Pessimistic developers will be the ones that find constant flaws in ideas, and the important thing to remember when working with them is that they're not doing that to tear down other people's ideas - they're doing it to ensure that the ideas that turn into projects are properly thought through and that as many problems as possible have been anticipated in advance. That neurotic, paranoid, pessimistic attitude is exactly what you should be looking for if what you want from your developers is robust, secure, reliable code.
By contrast, an optimistic developer will be more likely to simply assume code will work, or that it is secure, or give a deadline for a project without considering all the potential pitfalls.
Likely to be heard saying: "And what happens when that goes wrong?"
Lazy
Laziness is not usually viewed as a desirable trait, and in this case I don't mean turns-up-late-and-pretends-to-work laziness or just-move-that-logic-to-the-view laziness - both entirely unwanted. I mean a desire to not do tasks that are repetitive, or to waste time doing things a machine can do for you, or even to avoid future work by writing better code now. A lazy developer is one that builds a reusable code library, or wants a fully automated build process rather than a manual copy-and-paste one, or wants comprehensive automated unit testing, or writes code to be scalable even though that wasn't a requirement (rather than revisit it later).
As a bonus, a lazy developer is also usually one who will try and keep a project focussed on its core goals, rather than try and cram more work into the same time, providing a buffer against feature creep.
For example, when writing a category structure, a lazy developer might be likely to assume a many-to-many relationship between parent and child categories, even though the project specification says it will be a one-to-many relationship. Why? Because it might be needed one day and it would be better to write it that way from the start than to revisit it later.
Likely to be heard saying: "We could automate that."
Curious
Good developers are often rather like Gregory House. They're very easily bored by repetitive work (see laziness) and spend most of their time ploughing through it looking for an interesting and challenging (and hopefully new) problem to solve. The less time they can spend on the repetitive, the higher the frequency of the challenges.
Curious developers will be constantly looking for new problems to solve, and better ways to solve previous problems. They'll be the ones encouraging new ways to work and constantly tweaking and trying to improve existing systems. They'll also be the ones most conscious of existing problems in the current working environment, and trying to correct those problems. Curious developers will usually have a wide breadth of knowledge, not just of their primary language(s), but of supportive, associated and alternative technologies.
Curious (or easily-bored) developers are often the least stuck in their ways - the most open to change. They may well need convincing of why a new way of working is better (and that's no bad thing) but as long as it's an improvement, and likely to release more time to spend on the interesting problems, they'll embrace it with a minimum of resistance.
Curiosity also breeds creativity, another highly desirable trait in any developer. A strong desire to work out what has caused a problem and how to solve it is highly likely to motivate someone to continue once obvious avenues are exhausted. It is that sort of mentality that fosters "outside the box" thinking and creative coding.
Possibly the most useful attribute of a curious developer is that desire to find and cure a problem rather than just paper over the crack.
Likely to be heard saying: "Maybe there's another way to do this."
Meticulous
Many great developers are sticklers for detail. They will demand consistency in their work and the work of their team (they're likely to care about common code standards and naming conventions, for example). They'll want unit testing and peer review of code. They'll want everyone in their team to comment on and document code. They are likely to be fussy about version control log messages.
They'll also be fussy about details in communication, and happy to ask what might seem like obvious questions, simply to be sure they have properly understood. This is especially true of things like bug reports. While they may not be terribly motivational communicators, they will usually be able to explain concepts clearly and effectively. That clarity is a tremendous advantage in any development environment, especially if teaching and learning are encouraged.
Likely to be heard saying: "I just have a couple of questions ..."
Translations
Dvorak vs Qwerty
If I might start by begging your indulgence - please look down at your keyboard. It's not very interesting, I know, but this won't take long. You see at the top left of the section containing letters a Q? Of course you do. To the right of that, you will more than likely spot W, E, R, T and Y. You might be surprised to learn that the reason you see those letters, and the others on your keyboard, in the position that they are in is because this makes your typing slower. That, and economics.
"Why", you may well ask, "would keyboards be designed to make typing slower?". A good question. Back when Christopher Sholes created the Qwerty layout for his new typewriter in the 1800s, it solved a problem. Economics has kept it in place ever since.
The main problem Sholes faced was that of bars colliding during typing. If two keys near each other were pressed quickly in succession, the bars they controlled sometimes collided or jammed. In order to avoid this problem, Sholes re-arranged his keyboard so that common combinations of letters were hard to type, thus making the keyboard slower and reducing the chance of jamming.
The other reason for the placement of some of the Qwerty keys in certain places was to boost typewriter sales. In order for salesmen to be able to sell typewriters, it was important that they not be seen 'hunting and pecking' during demonstrations. R was moved for this reason, and replaced the period on the left of the T.
That is why, if you look once again at your keyboard, you will see that commonly typed pairs of letters are well spaced out, and that the word "typewriter" can be typed using just the letters on the top row.

Once the Qwerty layout was in place, it was simple economics that kept it there. Typists were trained to use it, which meant that makers of newer typewriters had to use the same layout, otherwise potential customers would need to re-train staff. The same has applied ever since - people make Qwerty keyboards because that is what people are trained to use, not because it is the best layout.
The Qwerty layout

The Dvorak layout

Dvorak is an alternative to Qwerty. It is a keyboard layout designed to minimise movement, and make typing as easy and painless as possible. The idea behind it is to have the most commonly typed keys under the fingers, and make it as easy as possible to type common words and combinations of letters. To give an impressions of just how big a difference this makes, consider that the average Dvorak typist's fingers will travel about one mile in a day of typing. A Qwerty typist's will travel anything from 16 to 20 miles. Try to consider, for a moment, the effect that must have on your fingers.
Dvorak is easy to pick up, taking about half as long as Qwerty. That is little comfort to those who are already familiar with Qwerty, as it means starting over. However, the benefits certainly make it worth spending a couple of weeks learning to type all over again. For many of us, that is actually a benefit, since many computer users never learned to type properly in the first place.
Changing your PC over to Dvorak is actually quite easy. In your Control Panel, in the Keyboard settings, you will see a tab for "Input Locales". If you want to use Dvorak, simply select a Dvorak layout from the drop down on this screen (please note - you may have to re-start running applications for the change to take effect within them).
Changing the keys themselves is actually the trickiest bit of the process. You have a few options though. Before you try and change your keys though, I recommend you learn to use the keyboard. If you wait before changing your keys over, you will avoid hunting and pecking, and your typing will be all the better for it. If you do want to change them, you can use stickers (probably the quickest technique), and some keyboards make it very easy to move keys around. There are also suppliers who offer specific Dvorak keyboards, though these are rare.
Take another look at your keyboard. Are you really happy using something that intentionally slows you down? Something that makes you move your hands and wrists far more than is necessary? Would you not rather use something that was designed to make your life easier?
Update, 4th April 2007: Josue Salazar changed his Macbook to Dvorak - in part, he says, because of this article. Check out the photoset: Dvorak Black Macbook Photo Set.
