Today’s tip is a hack for getting awesome tech support from a company for a product that you may or may not have purchased. It may not be polite, but it may be a method of last resort.

We all knows what happens if you buy a product and then call for support. If you’re lucky, you get put on hold. If you’re unlucky, you’ve called outside of their business hours of 1am to 3am. When you do talk to someone, you’re treated like an idiot (in their defense, it’s a learned behavior).

If you want great service, call their sales department. Tell them you’re evaluating their product, but ran into an issue. You’ll be talking to someone that actually wants your business. They’re typically very helpful, and remind us of the benefit of good customer service.

Just today a coworker sent me a link (unrelated site) that had a link to a page called "Pre-Sales Questions". They’re openly distinguishing between potential customers, and paying customers. The problem is that they make the pre-sales question form easy to use, but the paying customer form is not. Customer service is in a bad state.

My official recommendation is to to fully try out their product during a trial, so that when do you do talk to their sales team, they can at least earn a sale from it. Like I said, this is a method of last resort.

One of your goals as a developer should be to make your code as readable as possible, both for yourself, and for the other developers you work with.

One great way to determine if your code is well written, is to ask yourself if the code you’re writing is readable by itself. Another developer should be able to jump into a module, and have a fairly easy time seeing what’s going on. They shouldn’t have to sift through thousands of lines of interweaved code to figure out what’s going on.

Of course, what I’m talking about is simply a test for the single responsibility principle. If you’ve written a huge "do it all" class with thousands of lines of code, you’re ensuring that you’re the only one that will be able to maintain it. That that type of code usually suffers from high coupling to the other modules in the program.

I used to organize code into classes based on the type of functionality being provided. I used them more as containers for related functionality. At the time, I didn’t see a reason to split it apart. I was very wrong.

In a recent article by Jimmy Bogard, he walks through creating classes with a separation of concerns. In the conclusion is my favorite part:

Now we have many more classes (4 vs. 1) and interfaces (3 vs. 0).  For those who don’t like more classes, GET OVER IT.

That is an excellent point. Why should you be afraid of creating more classes and interfaces? It’s really not more code to write, in fact, it’s often less. Refactoring tools remove many of the obstacles of maintaining the interface, class, and method structure

When someone looks at your code and you have 4 classes instead of 1, and those classes are very specific and short enough to process by our tiny brains, it will be much easier to maintain and modify (or even better, extend).

As I mentioned before, I’m trying to consolidate the number of websites that I have to maintain. My young-technologies.com domain was badly out of date, and didn’t really have any useful information. I decided to redirect all of it’s pages to this site.

The only page that was getting real traffic on that site was the Subversion virtual machine appliance, which I created a long time ago. I decided to move that page to this domain. That means that I have only one page to manage instead of an entire domain.

If you haven’t seen that virtual appliance, it’s worth checking out. It’s basically a fully functional Subversion install on Ubuntu linux, with WebSVN installed to view it in a web browser. It’s been downloaded over a thousand times, and it’s now being hosted using Amazon’s S3 service.

While the appliance has found a new home, I’m not sure if an when it’s going to be updated. If there are any future announcements about it, they’ll be made on this blog.

In what little free time I have, I’ve been slowly working my way through the book "Agile Principles, Patterns, and Practices in C#" by Robert C. Martin. This is a GREAT book, and a real eye opener.

This book has shaped some of the fundamental ways that I look at software. Whenever I look at a problem now, I think about how I’m going to create the building blocks to solve that problem. As an example, MSDN magazine just had a great article about the opened-closed principle which actually discusses this book.

Sure, I used to have excellent test coverage and modularity, but this book has given me insight to take it to the next level. For example, following the single responsibility pattern is a concrete way of making your code more adaptable to change, and makes your code easier to maintain and understand.

The book even offers information about studies that have shown a correlation between how often working software is delivered, and the quality of the final product. When points are made, evidence is often provided to back it up. It’s difficult to argue with real numbers.

The book covers these areas:

• Agile principles, and the fourteen practices of Extreme Programming
• Spiking, splitting, velocity, and planning iterations and releases
• Test-driven development, test-first design, and acceptance testing
• Refactoring with unit testing
• Pair programming
• Agile design and design smells
• The five types of UML diagrams and how to use them effectively
• Object-oriented package design and design patterns
• How to put all of it together for a real-world project

If you haven’t read this book, I highly recommend it. I think just about everyone could get something out of it. Even if you’re not practicing or learning agile, the techniques themselves are still valuable.

On a personal note, I feel like I’m entering a completely new level of software development. I don’t know if I’ve just been unlucky, but I’ve never worked with a team that really understood and/or practiced these patterns and practices. They certainly didn’t teach this stuff in school.

I became curious as to the adoption rates of agile, and the rate of success that people are seeing. There is plenty of information that shows that the agile process is being used, and has been working well for lots of teams.

I’ve a read a lot of articles talking about what it takes to be a good development manager. There are also articles about what makes a good developer. I thought it would be a good idea to describe what a developer needs from their manager.

A developer abstraction layer - There is so much stuff that goes on in a company, and I really don’t need to know it all. For my own curiosity, give me general interesting tidbits, but more isn’t necessary.

Leave me alone - If you interrupt me for no reason while I’m getting a lot of work done, I’ll obviously get less done. It’s not worth interrupting me just to find out what I’m doing. If I’m walking around, that’s probably the best time to talk to me.

Buy any training materials that I request - Books are cheap compared to my salary. If I can learn something new that will save time, the investment will have been worth it. The same goes for magazines, software conferences, etc.

Be flexible - When it’s time to get some coding done, there are times that I’ll be more productive than others. My computer doesn’t care if I’m using it at 3AM or 10AM. You shouldn’t either.

Trust - If you don’t trust me, you’re setting me up for failure. Trust your employees first, and take appropriate action if they give you reason not to trust them. If I know you trust me, I can focus on getting my job done.

Keep me happy - A happy developer is a productive developer. Sometimes there are small things you can do that will keep me happy. Buy lunch every once and a while. Tell me to go home early on a Friday. As a bonus, I won’t be looking for another place to work if I’m happy.

Guide, but don’t over-manage - You have the big picture, so I need your guidance. That doesn’t mean that you have to know every detail about what I’m doing. You’re not a babysitter, you’re a teammate.

Be accessible - If I get need something, please be available. I may need you to pull in the right resources to solve a problem.

Have answers - You’re the hub of the wheel. If you don’t know what’s going on, you’re useless to me. You need to be organized and connected.

Be able to prioritize - You have a better idea of what is important for the overall product. That means I need you to prioritize features accordingly. That means I’ll always be working on something important.

Tell me what is expected of me - I need to know exactly what is expected of me, and I need to know how you’ll determine if I’m completing what is expected. I also need to know how you’re going to gauge my performance. When it’s time for my review, there should be no surprises.

If you’re interested in more information on this topic, I highly recommend you read "First, Break all the Rules - What the world’s greatest managers do differently". It’s not specific to development managers, but it certainly applies. In that book, they empirically determined the factors that are the most important traits that promote success and happiness:

1. Do I know what is expected of me at work?
2. Do I have the materials and equipment I need to do my work right?
3. At work, do I have the opportunity to do what I do best every day?
4. In the last seven days, have I received recognition or praise for good work?
5. Does my supervisor, or someone at work, seem to care about me as a person?
6. Is there someone at work who encourages my development?
7. At work, do my opinions seem to count?
8. Does the mission/purpose of my company make me feel like my work is important?
9. Are my co-workers committed to doing quality work?
10. Do I have a best friend at work?
11. In the last six months, have I talked with someone about my progress?
12. At work, have I had the opportunities to learn and grow?

That book is one of my favorites, and I highly recommend all managers read it.

Are there any other factors you feel are important? Leave a comment and let me know!