Like many companies every year Digital Cheetah holds a Holiday Party. We have two events that make our Holiday Party special to us: I perform a magic show and we have a spirited gift exchange. Along with music, food, and drink the evening is always very well received and it is talked about long after the event.
It takes a lot of planning and effort to pull this event off each year, but it is always worth it as the party brings us closer together as a company and gives our employees something to look forward to. When you think about your own Holiday Party think about going the extra mile, you’ll enjoy it more and your employees will too. And in the end that is really what counts.
Here is where I attempt to cut the head off of Digital Cheetah’s President: Aj Tidwell. Enjoy!
Fifteen years ago I built my first web development platform or framework called SAGE that was used by garden.com to go public. Nine years ago I built a new platform called The Universal Web Engine (UWE) that we have used at Digital Cheetah since its inception. About three years ago I mapped out a new system that was going to replace the UWE. I actually began to implement it in 2008, but was forced to shelve it’s development due to the economy. This month I began looking at starting this new platform in earnest.
My plan was to use Python as the primary development language and I was going to take all of the ideas from the last fifteen years and develop the “perfect” system for the creation of 1000’s of custom websites. Luckily before I had really started I rediscovered Django.
Django, named after the legendary guitarist Django Reinhardt, appears to be the perfect place to start to develop a new framework. It doesn’t do everything the way I had planned, but it does so much more and is flexible enough to allow me to augment it with at least a few of my own ideas.
To the many happy developers and designers already using Django this is probably no big surprise. But for someone who has been used to developing his own frameworks from scratch this is a huge departure. I for one am really excited that I can start building at a much higher level.
I believe using Cloud Computing and Django I will truly be able to deliver a platform that will allow Digital Cheetah to continue to provide world class custom solutions for the next ten years and beyond. And just maybe we’ll be able to build a new website for ourselves too, instead of the eight year old one we currently have!
The software vendors push the idea that better tools, languages, frameworks, and programming systems will make better programmers. This is simply not the case.
It is certainly true that most programmers can produce better code with the right tools. However, the second you want to do something new that is not covered by the tool or framework you are using you are now left to your own innate abilities. If you aren’t a good coder you will likely produce a bad solution, no matter how good your tools are. Stick within the framework and you’ll be laughing and people will think you are hot stuff.
In fact if you stay within the framework you might even produce better code than a more talented developer without the tools – kind of depends on the tool. However, don’t stray too far from your tools if you want to continue to impress your boss.
I read this article recently and agree 100% with these words by Matt Marshall:
One of the biggest challenges is getting an ace developer. The difference between a great developer and a mediocre one is huge. A great developer can push your business forward 10 or 20 times faster than a mediocre or average developer.
However, it only goes so far. In the first two years of a company great developers are what give you a shot, however to be really successful in the long term you have to have equally as good if not better marketing and entrepreneurial vision.
I think this is where a lot of great developers fall down – they think they can do it all by sheer technical virtuosity. This view typically leads to disillusionment. You need both sides of the coin to be successful in the long run, and sadly (for the developer) after the first two years much of the success of a company is driven by the entrepreneur and not the developer.
I have been collecting and performing magic since I was nine years old. However, when it comes to software my best advice is to avoid as much magic as you can. It is easy to think writing software that does all sorts of magicis a good thing. But after years of being burnt by such software I have come to the earth shattering conclusion that there is no place for magic in software.
The worst kind of software is code with multiple side-effects – it is a nightmare to maintain and never does quite enough magic to make it worthwhile. It doesn’t mean you can’t write useful scripts and routines that perform multiple tasks, but each task in the script needs to be spelled out rather than things happening “as if by magic.”
This revelation might seem obvious to many but for me it has really only been in the last five years that the truth has become crystal clear. These days I aim for simple and explicit code and although I like to think what I write is still cool, it is no longer magical.
It should be obvious based on my worship of Bill Joy, but with a number of postings on Windows I wanted to make it clear:
When it comes to web servers and production environments I always use *nix and would never consider using Windows to run my enterprise.
I’m very happy with Windows 7 as my desktop I just wouldn’t want to build my server rack using anything but some form of Unix. These days I favor the CentOS distribution. For years I was a BSD guy of course, then an AIX guy, then a Solaris guy, and these days I’m happy with CentOS Linux.
“Is the customer always right?”
I get some interesting responses. My take on this is clear: the customer is clearly not always right, but it doesn’t matter as long as they are satisfied and happy. In fact, I like my customers deliriously happy if possible. It doesn’t matter if a problem is their fault you need to go out of your way to make them happy.
When it comes to developing applications one of the bad traits developers get into is doing things because they are easy to code, rather than because they are easy to use. There is rarely a time where it is a better policy to make the developer’s life easier at the expense of the end user. Of course, if possible, you want to make every ones life easier.
One of the most useful things a developer can do is to actually watch customers use their applications. It is amazing how “features” that you are proud of get used and abused by them and you can quickly see things that are poorly designed. Another practice that pays off in spades is to spend a day answering calls from customers and use the tools provided to the customer service staff. Nothing shows the flaws of a system like actually using it under fire!
Caching is so important from every aspect of running a website that without it, the Internet and/or our servers would surely grind to a halt. Caching occurs at many levels and the more levels you have the better performance you will likely have. If a few caches remain sticky along the way this is normally ok. People say they want “Real Time” but rarely do they care. Sometimes a minute or twenty minutes old is fine and frequently hours and days is also fine. The more use you make of this knowledge the better chance you have of helping out with various well placed caching systems.
Some common forms of caching are:
The best forms of caching are ones that don’t require developers to think about it. But sometimes the application requirements are unique and only the person writing the code can get the most out of the system.
However you slice it caching provides a huge benefit to both producers and consumers and without it the internet would have crumbled long ago. Caching truly is our friend.
I started writing software in the outstanding music decade of our time: The Seventies. In those days good software performance was instilled in me early on. System calls and disk I/O were to be kept to the absolute minimum. When I started building websites in 1994 performance was still a big deal to me. In those days static HTML was prevalent and when I set out to build a 100% dynamic CGI site it was quite rare. For speed I used compiled “C” and the site (Garden.com) was feature rich and very fast. Over the last fifteen years there have been many hardware and software innovations to make processing dynamic pages faster. In fact, for many sites we don’t even have to think about it. However, I’m amazed how slow some large and influential sites often are.
You really need to render pages in less than a second to keep people from noticing. Certain pages (e.g. order checkout and account creation) can take longer without losing people’s interest, but for the most part clicking around from page to page should take a second or less. 0.1 to 0.5 seconds are better. You can certainly notice the difference between a second and half a second.
What happens is that developers get so enamored with adding all these “cool features” to a page that they fail to keep an eye on the clock. Or they keep an eye on the clock for the single instance and don’t take into account that 100’s or 1000’s of clicks are competing for the same resource.
I have heard on more than one occasion developers say “Performance doesn’t matter anymore.” Well, performance does matter. Without it you can’t add all the features you need to keep people coming to your site and if you do your site will be so slow that people will leave even quicker.
As we constantly change and fragment the ways we get to deliver content over the web our servers will continue to get pummeled with requests and I don’t see a time when performance will ever be irrelevant. What is more likely is that if we don’t start really thinking seriously about performance at the lowest levels we will build systems that just topple over with the load.
Performance is more relevant today than ever.
However, I remember feeling disappointed when we first started in 1995 because he was not always as encouraging as I expected about our business. This can often be the case because a VC’s primary goal is to make investments and to get a good return. As an entrepreneur you are typically starting a company out of passion and a burning desire to create something. Of course you’d like to make money, but frequently this is not your primary goal.
As a result, when I started Digital Cheetah in 2001 the last thing I wanted to do was get any external financing. If you can afford to go alone, that is often the best strategy because you can create the company precisely the way you want. However, if you need the cash then remember VC’s are for funding first and just be grateful that they are willing to invest in you at all.
Nothing frustrates me more than when I see sloppy code or practices. If you have a set of coding standards for testing, documentation, naming conventions, and even layout – use them. If you don’t, then maybe you should get some.
One of the reasons I am drawn to Python for my next major project is that the language has a very clean semantics and when you write using Python it just flows very naturally. The precise indentation requirements make even the layout of code always look consistent. Also, with facilities like doctest it becomes possible to combine the code, with the documentation and testing in a very clean and precise bundle. One can certainly not accuse Perl or even “C” of being rigourous.
No one would ever say John Tucker was a great coder, but he certainly helped me write better code and design stronger systems that have lasted for years. I think a big reason for this is the sense of rigour he instilled in my over twenty years ago. Thanks John!
and we spent many hours discussing programming, girls and beer. I got on very well with Chuck and was quite certain we would both be writing code for the rest of our lives.
When I was at IBM I worked with another great coder – Larry Raper. Larry and I worked closely together on one of IBM’s great lost technologies the System Object Model (SOM), and it was through the work on SOM that I received the majority of my patents. Larry and I had many coding discussions together and I have fond memories of those times. Larry was always going to be a coder, I felt sure of it.
Chuck started working for Microsoft in 1989 and today he is a General Manager. Larry is now retired but he spent the last five years of his career as a manager. Both of these great coders took the manager path that I see all too often in our industry. There is only one reason I know that great coders move into “management” – money.
One of the main reasons I started Digital Cheetah was because I didn’t want to end up as a manager. Nothing against managers – a good manager is almost as hard to find as a good coder. What is sad is that our industry almost always takes the best and most experienced coders and makes them managers. I don’t understand why this is because rarely do the best coders make the best managers.
I think companies like Google understand the importance of experience in their coders and only wish that more companies would compensate them fairly. An experienced coder is easily worth ten or more juniors, sometimes a lot more.
Since starting Digital Cheetah in 2001 I have developed some very creative solutions that are certainly worthy of patent submission. However, I have not applied for one patent. There are two reasons for this:
- The cost of processing a Patent.
- The restriction they can impose to freely use the ideas.
In the early days of Digital Cheetah the cost was the biggest reason for not pursuing a patent. However, these days I am less inclined to apply for a patent because although they offer some protection against their use, they also impede my own ability to use the same ideas in the future. For most small businesses I believe “patent protection” is an illusion and all that you really do is limit your own use of the ideas.
Most of the time the only possible reason for applying for a patent is if you plan on selling the company. Then having a patent portfolio can be attractive.