Code Zest

'Make it Happen / Whatever it Takes Attitude’

Dave Schinkel — Thu, 09 Jul 2009 04:14:27 GMT

Technorati Tags: Rants,Opinion,Management

I often see this in job descriptions for Software Developer positions. I don’t know about you but to me this kind of description is just getting ridiculous these days and I’m seeing this language more and more. I mean is this kind of statement really necessary? We’re all adults and professionals here. Personally when it’s that strongly stated in such a passive aggressive tone, it turns me off. Yea yea, you’re telling me your environment is hard core and extremely high pressured. Wonderful, as I woke up this morning I was thinking wow, I really need a lot more stress than I really already have at work. That’s just what I was looking for. Is that what you’re offering/selling to me, a potential candidate as I read your job description? Lame. Why would I want to work in an environment where I’m going to be constantly whipped which is what you’re telling me here.

Because to me when stated so bluntly like this, it’s saying we don’t care if you get sick over the task you’re working on, just get it done. That “pulling the load” to you most likely will mean not to ask any questions or hit any walls whatsoever during normal development because “that’s what you’re paid to do, to be perfect essentially”. That we don’t care how many hours you work, or if you have to work till 2am and were dedicated (and also sacrificed personal time and family time) enough to come in and work that long for me; you better just have it done or you’re fired kind of lame attitude. I think a lot of the managers who post this shit probably have no idea what reality is or they’re basically lead developers who really have lost touch with reality.

Obviously you hear time and time again that “we have to do what it takes for the business”. Give me a break, we know this. But when the business is such a dictatorship that employees lives are ruined, I take that statement and shove it down the toilet.

Personally I am very motivated and hard working (very entrepreneur). My friends tell me I work way too hard for my employer but hey, I can’t help it. I sincerely truly care about delivering for anyone I’m employed with and you can ask any of my collegues now or in the past to confirm. However these kinds of statements from management is simply overboard, even unprofessional at times. This kind of rigid no room for error, learning, or family life has to be discouraging to our profession. While many of us get paid top dollars, we also have a LOT to deal with today in programming.

What would be appropriate and sane? Probably something like this: “Looking for a developer who is willing to learn new technologies quickly and apply them where needed while working with the team together to deliver results”. Why is this better? Because it emphases working as a team and it emphases a positive working environment in order to “make it happen”. It is saying hey, we expect you to pull your load, but also we’re a team here (we’re human) and sometimes we need to help each other out when we’re stuck. That’s what a development team should be. Not this dictating “You figure out everything on your own, I don’t care, leave you in the mud, get it done or you’re fired tomorrow” kind of luda overbearing attitude.

I also love the “fast paced environment” statement in job descriptions and statements like this in interviews. What environment is not “fast paced” these days including in far too many cases a run & code shop. I mean is this really necessary to put in a job description? This is common knowledge. Do you think with today’s pace with technology, that development is so easy that we’re going to have a lot of spare time? Definitely not the case even if you’re not running at blazing speeds. So why the hell state that in a job description. It’s obvious. I if you keep stating to me how face pace your environment is, it’s going to really make me think you truly are a code & run shop with no real management skills as the cause. There’s a reason you keep saying this to me. Therefore I can read between the lines if you keep repeating it.

Take all the new languages, techniques, and changes that are happening day in and day out and it’s enough to really challenge any programmer these days anyway. So we don’t need someone standing behind us with a whip every day with the fear of losing our job when we’re already busting our ass and have a fear of hitting any walls during the development process. This expectation to “make it happen” has to have some flexibility somewhere and some sort of saneness and breathing room!

There are many surprises that come up in software development, and often many walls daily. We try hard to get past them as quickly as possible. But when you have managers and leads just acting like assholes because you couldn’t figure something out in 2 seconds (and they say they can) it’s becoming unhealthy bullshit for employees. Look, I’ll say it. Sometimes we CAN’T figure out the work-arounds or fixes or whatever that quickly even after spending many hours working very hard on something. Even the best developers get stumped and I’ve seen even my own leads say NO. Sometimes they offer the business alternatives sometimes they say there is none. While we are definitely supposed to and I agree to expect to be thinking about alternatives, work-arounds, etc. sometimes some things are not possible. That could be because of resources, bad or lack of planning, or whatever the case might be. That’s when you come together as a team to discuss. And that old saying “The business doesn’t want to hear not possible” fine. But you know what? The business better damn well be able to compromise and listen to their developers to the alternatives and move forward with them.

Now I’m not saying we should not do our best, not have deadlines, or not work our asses off to deliver results. But there is a point where this kind of expectation to get things done or get fired attitude has got to stop in development environments especially as our jobs are requiring us to master much much more (too much) than we had to 10 years ago. I remember when I could easily get out a huge application using classic asp.net, SQL, and JavaScript. But now, we have to go way beyond just mastering 3 areas like this and supposedly the business is supposed to care about good design when most of them could care less (design patterns, useable code, testing, etc.). To come at your developers with a breathing down your neck attitude every day nowadays makes it even worse.

And I’m also not saying we as developers won’t have late nights at times. But if the environment is so ridiculous that you’re up every night till 12 am coding because of the statement and attitude that you must produce perfect code and expect no stumbling blocks exists, you gotta ask wtf. This extreme hang me over a cliff if not done in 2 days kind of attitude is ridiculous and really just plain stupidity.

Am I alone on this? Does anyone else see this trend becoming more and more “In your face” type of attitude from management so much so that we’re getting to a point were IT and American business will eventually come to a bubble and fail? And where developers are just going to get burned out and turnover is going to get even more ramped because of the lack of reality in expectations?

There will be a point where businesses will just have to realize that they are becoming way too ridiculous in their delivery expectations and tone of language to the people they employ. This unforgiving passive aggressive tone coming from management is becoming extremely abusive. How about suggesting alternatives to help your team succeed rather than threatening ? And they will also always eventually realize that hey, after all these years of “Get it done lightening fast” was implemented, they now have a pile of shit to either refactor or throw away losing many $$ because of this kind of slave driven environment. And that they’ve lost many good developers and GOOD CAPABLE PEOPLE and most likely ruined a lot of lives because of this carelessness.

I’d love to hear your thoughts and also what position you hold (meaning title) as you reply. Hopefully this will be an interesting discussion.

Making a jQuery JSON Request to an ASP.NET Handler And Back

Dave Schinkel — Wed, 08 Jul 2009 04:22:36 GMT

Technorati Tags: jQuery,ASP.NET,JSON

Recently I was working on a small project where we wanted to make requests to go get some data and pass it back via XML or JSON to a jQuery control. So I picked out a control that I thought would work (as it had hooks there for init, load, and other callback slots) and then thought ok, how the hell am I going do this. Having never really created my own or used any HttpHandler (.ashx) before, I found out that this would be the way to do this.

The Goal: Make XML or JSON AJAX requests to the server, pick up some data, send it back and parse with jQuery. Something pretty common but this was my first time attempting it with jQuery and first time using JSON. And the reason do to this was for deferred loading of the jQuery plug-in that I was going to use. To make a long story short, here’s a bit of information on how I did this.

In one of my load functions on the jQuery plug-in, I ended up deciding to make JSON requests instead of XML for primarily 2 reasons:

1) Obviously JSON is less data over the wire as compared to XML. Just compare or look below to see that JSON has no tags like XML does, making it less overall. It’s also much easier and less to read than XML. To me it’s like the analogy of reading tableless design in an HTML page vs. clunky horrible table based layout design with a crap load of uneccessary tags.. <table><tr><td>, blah blah..who wants that crap in mark-up. Well same for JSON vs. XML, who wants all those XML tags when you’ve got JSON! Anyway, to me it’s just cleaner and I like JSON now a lot.

2) jQuery JSON parses it much easier than parsing XML. While it’s still very easy to parse XML with jQuery, it’s even easier with JSON because you have less code to deal with and also better yet, you get a nice typed object once you receive the data back that you can work with to access the variables in your returned JSON

So here’s how it looks using the jQuery getJSON method:

        1: $.getJSON("http://someurl/SomeHandler.ashx?action=getproducts&ids=" + ids,

       2:     function(data) 

       3:     {

       4:         ..some other code

       5:  

       6:         someplugin.add(i, decode(data[d].Image));

       7:  

       8:         ...rest of code

       9:     }

      10: );

Decode is just decodes HTML characters if any:

       1: function decode(s) {

       2:     return s.replace(/&amp;/g, "&")

       3:             .replace(/&quot;/g, '"')

       4:             .replace(/&#039;/g, "'")

       5:             .replace(/&lt;/g, "<")

       6:             .replace(/&gt;/g, ">");

       7: };

Notice data[d].Image. Data is returned back to the function after successfully parsed by the getJSON method. This parsing happens automatically. And only if successful enters into the function via whatever parameter name you give it. It doesn’t matter what you name the parameter in function(). Now that we have the data, you can access it via index and then simply access the variables using a period. So Image was a name in my JSON name/value pair:

[
    {
        "Image": "\u003cp\u003e\u003cimg src=\http://www.xxx.com/image/25.jpg\ alt=\"SomeText\"\u003e\u003c/p\u003e\u003cp\u003e\u003ca href=\"somepage.aspx\"\some text\u003c/a\u003e\u003c/p\u003e\u003cp\u003e$20.95\u003c/p\u003e",
        "ProductID": "523"
    },

    {
        "Image": "\u003cp\u003e\u003cimg src=\http://www.xxx.com/image/44.jpg\ alt=\"SomeText\"\u003e\u003c/p\u003e\u003cp\u003e\u003ca href=\"somepage.aspx\"\some text\u003c/a\u003e\u003c/p\u003e\u003cp\u003e$20.95\u003c/p\u003e",
        "ProductID": "524"
    },
]

by the way, make sure you validate the retuned JSON using a JSON text validator.

Now on my .ashx side, I simply used the built-in JavaScriptSerializer in .NET 3.5.

In my .ashx, I simply created a function that cycles through products but populates another generic list based off a custom class that only has properties for what I really want to pass. I don’t want to serialize the entire Product object because that’s too much data so I created a small class called ImageList to hold the values I’m actually going to really want to send back as JSON:

       1: public class MyCustomHandler : IHttpHandler {

       2:     

       3:  

       4:     public bool IsReusable {

       5:         get {

       6:             return false;

       7:         }

       8:     }

       9:     

    public void ProcessRequest(HttpContext context)

    {

      ...some code and then eventually:

      

            GetProductsJSON(context, products);

    }

  

    public class ImageList

    {

        public string Image { get; set; }

        public string ProductID { get; set; }

    }

  

    private void GetProductsJSON(HttpContext context, string[] products)

    {

        context.Response.ContentType = "application/json";

        context.Response.Charset = "utf-8";

  

        List<ImageList> imageList = new List<ImageList>();

  

        foreach (Product p in products)

        {

            StringBuilder productInfo = new StringBuilder();

            

            productInfo.AppendFormat(string.Format(@"<p><img src=""{0}"" alt=""{1}""></p>", ImageUrl(p.Image, false), p.AltTag));

            productInfo.AppendFormat(@"<p><a href=""{0}"">{1}</a></p>", ProductURL(p), p.Name);

            productInfo.AppendFormat("<p>{0}</p>", ProductUtil.ProductPrice(p));

            

            imageList.Add(new ImageList { ImageTag = productInfo.ToString(), ProductID = p.Id.ToString()});

        }

  

        string jsonString = imageList.ToJSON();

        context.Response.Write(jsonString);

    }

  

}

A few pointers (common mistakes or just good info here):

1) Be sure that you set the content type and charset correctly. And some settings don’t work for IE but will in FireFox. You obviously want your returned JSON to be parsed successfully in both IE, FireFox and the rest so it’s very important that you use the following:

context.Response.ContentType = "application/json";
context.Response.Charset = "utf-8";

or just

context.Response.ContentType = "application/json;charset=utf-8";

either or will do the trick. Don’t make the mistake of only specifying the ContentType as "application/json" and then forgetting to set a Charset!

2) If you are not using .NET 3.5, you can still get at the JavaScriptSerializer class by including the AJAX 1.0 library from Microsoft

3) Make sure the returned JSON does not have an extra comma at the end of the JSON string…jQuery will not parse as it’s not valid JSON

4) getJSON function of jQuery eats any errors on the returned JSON so you won’t get any notification that hey, the parse failed. So if you really want to trap errors, I would recommend using the $.ajax method instead. Here’s how you’d do the equivilant above with $.ajax and trapping any errors on failure of the JSON parsing:

       1: $.ajax({

       2:     type: "GET",

       3:     url: "http://localhost:59396/somesite/SomeHandler.ashx?action=getproducts&ids=" + ids,

       4:     //data: "ids=" + ids,

       5:     dataType: "json",

       6:     success: function(data) {

       7:         alert(data.length);

       8:  

       9:         ...some code

      10:                 carousel.add(i, decode(data[d].Image));

      11:         ...rest of code

      12:         }

      13:     },

      14:  

      15:     error: function() {

      16:         alert("An error has occurred. Please try again.");

      17:     }

      18: });

Unit Testing is Not a “Figure It Out Later”

Dave Schinkel — Sat, 06 Jun 2009 06:00:43 GMT

Technorati Tags: Unit Testing,Standards

del.icio.us Tags: Unit Testing,Standards

If you buy into the excuse that “We don’t have enough resources or time to start Unit Testing now”, then you buy into the hack it now, fix it later approach and I don’t respect that. Unit Testing should be something you learn NOW especially when you have a fresh opportunity do so such as a on a new web project that’s being coded from scratch. There are not many projects which you can start fresh on and include Unit Testing like this, and when you have that chance, do not let it pass away. Businesses find it easy to keep adding features to produce scope creep but they can’t fit in extra time for adequate testing which I feel is just appalling.

If someone tells you to wait and do it later on the “next project”, it’s really not their decision. Unit testing is for programmers and is done while you code. It’s a decision done by the programmer because he/she cares about better code and less bugs for the good of the team, the business, and its users.

Unit testing is not a big of a deal. All you are doing is creating very small little tests which only take a couple minutes to code up per method you are testing. If I take and create 5 controller methods today for my MVC Web project for example then I expect to take 10 minutes out of my day to create 5 small code snippets for testing those methods. To me, that is not a big deal. Even if I took 20-30 minutes, it’s not a big deal considering all the time I spend on bullshit with other aspects (email, etc.) in the office. I know that in the end I’ll be able to run these tests and have them tell me where my code breaks when introducing new code in the future.

Now why would I not want this added comfort and savings in the future when I’ll have less debugging because my tests tell me if code fails instead of me manually debugging code that I have no clue why it’s failing? It seems to me Unit Testing is something that’s obviously an item that should be required of every programmer on any team. When we have tests we can run, we can see where code breaks immediately instead of spending 20-30 minutes in some cases doing the contrary…moving through the debugger finding bug after bug and fixing bug after bug and never knowing how many MORE bugs there are to fix. That’s going backwards. Leaving testing to last is ignorance. So I promised myself this time through I’m adding unit tests to my new MVC project. My mentality is not one which can allow things to just go array and I can’t stand when process is backwards.

Testing last or not testing at all to me asks the question why are we coding in the first place if we are doing a half assed job at it? Not testing (QA, usability, acceptance, and unit) is simply saying we don’t give a shit about quality and the business enough to do this. And that we enjoy or are willing to put up with constant fixing of code. I know that personally I did not go into IT with the expectation to keep fixing bugs, I like spending my time on more important tasks for the business.

And who wants to sit all day and talk to QA about bugs that we probably could have caught via Unit Testing? QA's job is not to catch code bugs, it’s to test whether the software has met the business requirements. It is our job as a programmer to add that added layer of testing before it gets to QA. And why would we not want to help ourselves by testing? Why would we not want to save ourselves time through the development process? It’s just a done deal to me and completely stupid not to unit test. It’s not hard to write a few lines of code to build confidence and trap errors which would have taken us much longer and surface many more surprises when not doing so during any project and it’s just beyond my comprehension why developers or management fight this very topic.

And remember, Unit testing is very misunderstood. People think it takes a lot of time to invest in doing so but it’s very small in comparison to the cost and time savings reaped when it’s done concurrently in development as you go.

A couple of books I’m currently reading and highly recommend. They are very short reads so you can get to the points/techniques quickly:

Pragmatic Unit Testing in C# with NUnit, 2nd Edition

ISBN: 0977616673
ISBN-13: 9780977616671

The Art of Unit Testing: with Examples in .NET

ISBN: 1933988274
ISBN-13: 9781933988276

Today I promise that “I will never write an application again without unit tests”, and you should too.

If you care about code quality, business process, the business you work for, and respect for yourself as a quality developer, less bugs for you and your end users, and ultimately getting shit done and going home sooner because you had less bugs today to work on, therefore I can now spend more time with the family, then you’ll promise yourself the very same thing starting today.

Top 10 Reasons Why Employees Leave in IT

Dave Schinkel — Mon, 01 Jun 2009 03:28:57 GMT

del.icio.us Tags: Management

Technorati Tags: Management

Share this post :

In no particular order of weight (but would have to say if I had to give it a weight the highest would be on #1, #2, #4, #7, #9, and #10). Before you read this, you might want to read my philosophy on what a Good Manager / Lead would be.

1) Code & Run Shop

No industry best practices / development standards in place
No time built into schedule for testing, SOLID practices, or time to even think SOLID
expectation of everything big or small to be coded in 1-2 days or other totally unreasonable timeframes and no attention to refactoring bad code (technical debt) leads to chaos
- Timelines are based on no estimates or are pushed by managers who have no insight or care to the process at hand. Estimates are pushed by managers at the blink of an eye and literally pulled out of thin air without any type measure whatsoever
No prioritization on items therefore constant interruptions in projects are the norm leaving projects unfinished due to a shift to “yet another project or task unexpectedly”
Excuse is “business needs it now” instead of lets try to get this thing out in a reasonable timeframe with testing in mind, and attention to quality code
- Working till all hours of the morning fixing hacks or entertaining scope creep due to features added the night before! sad but all too true in IT which ultimately will lead to the good employees jumping ship

2) Absolutely NO structure

this is typical for mom & pop shops or those shops who have people who have never worked anywhere else BUT the company they work for. They’ve worked for the company for 10-20 years and do not know what “reality” is outside their environment and ways of doing things overall

This causes a code & run shop but I’m talking about absolutely NO structure here (see bullet 2). Code & run can come from lousy structure but no structure is even worse
While too much structure is not good, no structure is complete stupidity and ultimately complete Chaos
- No priorities on queued tasks
- No reason why we should even do task A, B, C but just do it cause the boss says so
- No source control
- No true Development, QA, Staging Environment (one or all)
- No Bug system with prioritized task lists
- Bug system has tasks or manager has them in his head but thrown out to the team at random thus interrupting their current tasks at hand without regard to what’s more important to the business. Disrupting someone’s current project and throwing in an unnecessary project prevents progress when there is no structure to these tasks being handed out. Tasks are handed out for no reason other than “I think it should be done”, not “Do we really need to do this or does this have more business impact or am disrupting the flow”
- No testing (Unit testing, QA, Usability) is added to project timelines and testing is only done by developers at best which is NOT testing

3) Lack of regular communication

Everything is kept behind Closed Doors or at an “As need to know basis”
Too many meetings that do affect you but you are not included
Mysterious meetings happen and they are mysterious because the people who hold them hold them off site every time or behind closed doors. This creates a lot of suspision in many cases and therefore it’s a closed environment
Boss doesn’t communicate things that affect the team or you as an individual and makes all decisions without your knowledge only you finding about it later through another source
Not able to get solid answers to your questions (about the business, procedures, decisions that affect the team, you name it)
Emails are not responded to (the important ones). When you attempt to ask them in person, the question is dodged or you receive an answer that completely does not provide you any information at all
Communication mostly done through email. This is not good communication and that’s common sense people. Talk face to face when at all possible, stop hiding behind emails. That’s mom & pop mentality.

4) Micro Managers

Managers that constantly have to babysit rather than trust their employees to do their job. Constantly checking in daily and worse, when checking in just checking in for status checks. Give your employees space or they will leave

5) No recognition of the work you’ve done and effort you’ve put in

Managers do not take the time to show their appreciation by a simple “good job” once in a while
Colleagues or managers take YOUR idea as their own. Lack of credit to the people who gave you the idea in the first place
Managers who only harp on the fact that you can’t get things done fast enough, even if you are doing the “norm or above”

6) Reviews that are mostly all negative most of the time

It’s ok to point out some weaknesses or things that you think your employee can do better, but the entire review should be mostly uplifting if you value that employee. Don’t make it a session for “you suck” but rather motivate them and tell them what they did do right. At the end, talk 10 minutes about what you want them to improve and leave it at that. It’s pointless for your employee to leave unhappy from a review if you value that employee. You want them to leave motivated if you are keeping them long term. Consistent “unfair and demeaning” reviews that make the employee feel that they are never good enough for you drives employee motivation down and eventually away from the company
In most cases, managers completely miss the work you've actually done. Lamely enough they ask YOU to evaluate yourself. This is one of the lamest procedures I've seen and it happens a lot at companies. They ask you to evaluate yourself while it's THEIR job to remember and jot down what YOU did and recognize you for these projects. Instead they focus on what you did not do and where you fall short. This is not a smart review my friend if you're the manager. It completely disregards your employees contributions and efforts.

7) Politics

This plays into many areas but typically it’s caused by bad apples. Those colleagues or managers who play favorites, who always are easily persuaded by other bad apples (cocky arrogant loud mouths), and those who make decisions not based on the situation or how an employee really has done but makes decisions to further themselves or based on peer pressure from others rather than decisions that benefit the employees or company as a whole
Managers who give out or try to promote others up the ladder because they are “friends” rather than based on their “performance”. Managers who fail to promote the very people who deserve it rather than who is popular or who they like rather than who really deserves it and has a great attitude and has worked hard for the company

8) Bad co-workers who do not get stomped out (let go) and hurt the culture

The arrogant bastard
- This guy always has to make a cutting or cocky remark and is typically very very LOUD in addition to his cutting remarks. Always has to act macho and talk in a passive aggressive tone to almost everyone naively thinking that it makes them look like a person of importance. It’s a shield for them as they believe if they initiate a conversation aggressively, that the person will actually listen to them and think they are important. Instead, the effect is disrespect to the to others, and disrupting the culture and environment around them
The Kiss Ass
- This person could also be an arrogant bastard. Often times they play both. They kiss up to people and go to lunch with those people who they are trying to kiss ass to. They do it on purpose to try to change situations which don’t affect them and purposely set events and meetings to go against someone else. They often are paranoid and kiss ass because they are not good at the job that they do. Reality is, they lack smarts
- This person could be dumb or could be smart. But they have no confidence which is equally as bad as being dumb
The Nosey Loser
- This guy always has to be the life of the party in order to find out what’s going on in the office. Constantly interrupting conversations so that they can butt in and shed a light or two on something that completely has nothing to do with him/her
- This guy constantly asks “what are you guys talking about”
- This guy seems to walk into every meeting you have with your boss just to nose in and figure out what you’re meeting about. Typically this person is not in your department at all in fact and has no business butting in constantly. Instead they should stay in their office and get some work done and relax
The Lazy Snail
- This dude always sluffs off. Does half the work and goes home. Not good for the team
The Idiot manager
- This guy doesn’t know technology. Constantly promoting datasets, he thinks he’s a genius. Throwing out management terms even he doesn’t yet understand. Expecting the team to work in IE 6.0 and wonders “what’s this FireFox thing you’re using?”
The Know-it-All
- They’ve done it, seen it, eaten it, created it and in fact much better or more than you. This person hurts a team because they are not contributing, they are bragging and wasting your time

9) No work-life balance

Those who preach it but truly are bluffing are burning their employees out. Eventually they leave. We are humans; build that into the system and let us relax while we do our job, outside of just vacation once in a while
Yes, "business has to get done" (really? ya think boss?? Did not know this), but lets be real people. If we're working hard already, stop using business as an excuse to drive your employees to death

10) No concept of “Team”

Employees are expected not to question anything, just do as told. This is NOT “Team”. Constructive criticism or going against the grain in a constructive fashion (not rude or out of control) is viewed as a problem rather than a positive. Teams work best when they collaborate and are allowed to question what the proposed process or standard is, not just following and doing what is told 100% of the time. If the process suggested or currently ongoing sucks, question it and expect your team to question it!
Manager not listening to and taking advantage of his employees and what they have to offer from their own experiences current or past
Consultants driving the business rather than the internal IT group. Consultants driving bad code or bad practices in environments. Not saying all consultants are bad but often times they do drive a lot of bullshit and unnecessary costs (refactoring, conflicts, self-interest) which hurts the team.
Manager is so stubborn and ignorant that “everything I say is right” and is constantly fighting to make himself “right” even if he is not
Employee has a breadth of experience in many environments but you continually are stubborn as a manager and make all the decisions rather than tap into and ask that Lead or employee a better way or process that could benefit the team as they’ve done it before
Employee comes up with an idea and manager disregards it because “no I’ve always done it my way” even if it’s a 1999 way of doing things
Employee comes up with a better idea than yours and you being the manager continually disregard those ideas that are better it because you are weak. Managers should be utilizing the people they hire including their ideas if they have a better process or idea/reason in mind. If you cannot, you suck as a manager. Your way is not always right, and most often 50% time wrong even if you are a very smart person

And all of these CAN be corrected or prevented if managers did their job to ensure this shit doesn’t happen.

Share this post :

Why Should I go to a Code Camp?

Dave Schinkel — Sun, 31 May 2009 03:46:55 GMT

First off, what’s a Code Camp? Well, it’s merely an extended user group meeting of sorts (in my opinion) that is all day with great presenters presenting on a variety of topics including great food & door prizes. That in sum is a “Code Camp”. The difference is, they are not just presentations but the presenters will also code and show you examples live as they explain a topic (can’t get any better than that!). And a lot of times these presenters are coming from all over the U.S. in many cases to your local camp.

Why should you attend one? To learn code? Sure, but more importantly it’s much more than just code. Today I attended a Code Camp for the first time (specifically this one was in Chicago hosted by LCNUG).

Here are some reasons why YOU should get off your ass :) and take time to attend one:

1) To network with people and have a good time

2) Really motivates you to get into code in those times you’re sort of burned out. Gets you excited about code again

3) Allows you to get a refresh on latest good practices & code patterns that are being used

4) From talking with people or listening to presentations, you’re able to formulate a nice list of key “terms” that you can bring back with you and look up and research / practice to better yourself as a developer

5) Free food & prizes! (great books, software, etc.)

Today I won a copy of Vista Ultimate (yea yea, Vista sucks, but I like it so screw all of ya :P. XP is old hat in my book and windows 7 will allow us to get rid of that XP addiction). Hey, it’s a free OS so I can’t complain.

And please don’t think you’re the only one who doesn’t know certain terminology, code techniques, or the latest code. All of these “presenters” are in the same boat as you but some are just a bit more advanced or versed lets say which is why they have the confidence to get up and preach. Yes the presenters are very sharp and are good at a variety of things BUT they also learn from each other on the sidelines all the time as well and even from sitting into other presentations themselves. Just because you’re not presenting doesn’t mean you’re dumb, not as good as a coder, etc. It just means you’re interested in collaborating and learning what others are doing. Just because you’re already very smart and know lets say design patterns well is no excuse not to go to a code camp. There are MANY smart developers there and it’s just a really great place to collaborate and learn together and ping ideas or trends off each other.

For instance I was talking with a presenter about the Spark View Engine vs. NHaml. Learned that NHaml’s framework was or is being refactored and there are some rendering issues with NHaml such as it adding unwanted line breaks in your mark up whereas Spark doesn’t pose this problem. I have not attempted to use the Spark view engine for ASP.NET MVC yet, so this is good to know and these are the types of things you learn quickly while attending and talking to people at a code camp.

Here is a great a list of terms I wrote down from various discussions or presentations throughout the day, that I thought was a great list for researching more on. Some are basic concepts, some are not and some I really need to just brush up on again after having not used them in a while. Many of these terms I already sort of know but some of them now I’m looking up again in a new light for use with a new technique or purpose. (forgive me if I spelled some of these wrong, I did not look up and verify all of these, just scribbled them down today).

getHashcode
immutable
best way to handle null refs in ASP.NET MVC views
Mutators
Serialize / Deserialize
Factory Method
Visitor Pattern
Repository Pattern
Imperative programming
Immutable strings
Expression builder using mutable symantecs
Expression trees
Expression tree iterators
line of business vs. framework code
Static analysis in code contracts
Debug symbols
Object invariance
Integration testing vs. Unit Testing
The stack
Lambda expressions
Static Classes
Concrete Classes
NDepend
Flipping bits for security (user access)
Observable collection
Observation pattern
Object initializers in .NET 3.5
Mutex
Unit testing multi-threaded code (very hard to do)
Enumerable
Whitebox testing vs. Blackbox testing
Reflection emit
Dynamic Proxies
Method invocation
Mocks vs. Stubs
Partial Mock vs. Dynamic Mock, vs. Strict Mocks
Mocking is really an isolation framework

And Some Good Resources I wrote down:

Book (which I’ve already pre-ordered last month already): Art of Unit Testing by Manning
Jeremy Miller’s blog (stuff on Unit Testing)
MetaLinq on codeplex good example of using expressions
Martin Fowler’s post on Mocks vs. Stubs
Uncle Bob’s Blog – Test Driven Development
John Smith’s blog about MVVM in WPF

So I hope you take a day out and try a Code Camp. It’s not you sitting down coding, the presenters are! You’re learning the entire time and getting up to speed on the latest.

Shout Out to Ryan Reese – CSS Guru

Dave Schinkel — Fri, 29 May 2009 02:18:19 GMT

I want to introduce you to who I think is one of the best resources on the net for CSS and tableless design or just CSS in general. Ryan has been helpful in many occasions in times where I needed to figure out tricks in CSS and his website is full of very relevant articles.

Hats off to Ryan and may you realize this great resource in your daily workings with tableless design and CSS pains.

Keep up the great tips Ryan.

CSS Image Mouseover with <li>

Dave Schinkel — Fri, 29 May 2009 01:48:07 GMT

Technorati Tags: CSS

del.icio.us Tags: CSS

As I said before I’m doing a lot more CSS these days with tableless design. Now before I start on this post, none of this is new or complex. But you know it’s amazing that nobody talks about hover much working on elements other than just a hyperlink at least from what I see on the net overall.

Goal: I had an existing suckerfish menu. My top level nav items in the menu (what you mouse over) are images in my case, not just CSS boxes. So I need a mouseover that switches images when I mouse over my suckerfish menu image tabs.

So big deal right? Back to hover. You know hover of course, everyone does? yea, a:hover, etc. Well, it can be used on other elements and honestly I never really had wonder about this fact until I had a menu based solely on unordered lists where the top nav tabs did not need to be clickable..hence for example a suckerfish menu.

This is not a suckerfish menu per say below (that was just the scenario I had today at work) but for the example here just 3 top level menu tabs that when you mouse over, I simply want to change out the image during rollover to show a bit of highlight with the rollover image.

Well it’s very simple after you figure out how to do it with CSS, here it goes:

<style type="text/css">

    #TopNavWrapper

        margin: 0px auto;

    #TopNavWrapper li

        list-style: none;

    #topnav_1

        background: url(/content/images/navImage1.jpg) no-repeat;

        width: 204px;

        height: 40px;

        float:left;

    #topnav_2

        background: url(/content/images/navImage1.jpg) no-repeat;

        width: 204px;

        height: 40px;

        float: left;

    #topnav_3

        background: url(/content/images/navImage1.jpg) no-repeat;

        width: 204px;

        height: 40px;

        float:left;

    /* hover effect */

    #TopNavWrapper #nav #topnav_1:hover

        background: url(/content/images/navImage1a.jpg) no-repeat;

        width: 204px;

        height: 40px;

        float:left;

    #TopNavWrapper #nav #topnav_2:hover

        background: url(/content/images/navImage1a.jpg) no-repeat;

        width: 204px;

        height: 40px;

        float: left;

    #TopNavWrapper #nav #topnav_3:hover

        background: url(/content/images/navImage1a.jpg) no-repeat;

        width: 204px;

        height: 40px;

        float:left;

</style>

<div id="TopNavWrapper">

    <ul id="nav">

        <li id="topnav_1"></li>

        <li id="topnav_2"></li>

        <li id="topnav_3"></li>

    </ul>

</div>

I don’t have this example running in this post. Here is the code (.asp page + images). I supposed I should have put it into just an .htm but oh well…

CSS Tabeless Design Basics – Positioning Content with Floats instead of Tables

Dave Schinkel — Thu, 21 May 2009 05:13:34 GMT

del.icio.us Tags: CSS

Technorati Tags: CSS

Share this post :

This is the first example in my series for CSS tableless design Basics. I will eventually expose an ASP.NET project later on once I start building more tutorials for free access in which you can see all these examples and more later on for download. And I think the dryer the post is about CSS or a book is, the harder it is to understand so I’m going to try to talk as though I’m teaching someone, not just spitting out technical terms here.

First off, I’m a huge advocate for tableless design especially when coding views in ASP.NET MVC. Even if not using MVC you should really start to get a grasp of it now, and quite frankly people we’re in 2009, there’s is no excuse for it and the web expects it. Your designer expects you to be able to accommodate his creative. And your team expects to be able to maintain good quality mark-up. At first it seems daunting and scary to make the leap but I can tell you first hand once you start to get it, it gets so much more easy and you realize the power and flexibility that you could never get with tables. In fact my design time is cut in half now after spending a good month in tableless design. At first it was a bit daunting and frustrating but that only lasts a couple months. And you won’t believe how your page is simplified and footprint is reduced when you’re not using tables! It’s so much easier to read people!

So now to the topic today. We’re talking about how can I position things when I’m not using tables? Well, there are 2 major ways to position elements in CSS to sort of do what you were doing with tables. Just pick your passion. I personally like using floats. It’s just easier for me to use floats, and until I find trouble with them that’s what I am sticking with even for complex sites. And by the way, personally after all the infighting I see in books and on the net about whether to use positioning vs. floats, I have not found any trouble yet even for a complicated website by using floats. I am starting to really get quite comfortable with it after moving away from tabled design this year.

Bottom Line: In simple terms, what float simply does is put whatever element you’re floating next to the element that is before it. At least that’s how I want to state it.

Float Left

Lets say I want 3 buckets (could be more could be less, doesn’t matter) of content (divs) and I want all 3 to show up next to each other horizontally.

In this case we’d have to float the last 2 elements (last 2 divs) with a value of float:left

We’re using <div> because it’s a container element that is meant to group content. And we’re then going to simply move the content (in each <div> container) around by using floats.

The Code

<div id="FirstElement">

   FirstElement Content

</div>

div id="SecondElement">

   SecondElement Content

</div>

div id="ThirdElement">

   ThridElement Content

</div>

The CSS

#FirstElement

    float: left;

    border: 1px solid #3a486f;

    width: 200px;

#SecondElement

    float: left;

    border: 1px solid #3a486f;

    width: 200px;

#ThirdElement

    float: left;

    border: 1px solid #3a486f;

    width: 200px;

The Result with Float:Left

The Result without floats (they show up just stacked naturally as they occur in page)

Now that I’ve floated element #2 to the let it will show up next to element #1. And because I floated element #3 to the left, it will show up next to element #2. Try taking the floats out. What happens? They all show up stacked underneath each other (vertically), why? Because that’s how they render naturally in the DOM. What you’re doing with float is saying hey, I want you to stack horizontally next to each other instead so lets use a float to do that :).

Now you’re asking why did I only have to float #2 and #3? It’s because #1 doesn’t need to float against anything. It is the starting point. You only float an element (in this case div) to an element before it. Well, #1 doesn’t have any elements before it, so no need to float it.

Float Right

Why would you ever have to float right? After all, you could just stack left to right and be all done right? Most of the time yes, but there are times you will want to float an element right instead of left.

Lets say the 3 buckets above were in one bigger container (div) called a wrapper. And I wanted the first two buckets to show aligned left to the wrapper’s left side. But here’s the kicker. I want the last element to be flush right to the right side of the wrapper’s right, not flush to the second element so that there is a gap between element 2 and element 3. I’d therefore need to float element 3 so that it hugs the wrapper’s right side.

The Code

<div id="Wrapper">

    <div id="FirstElement">

        FirstElement Content

    </div>

    <div id="SecondElement">

        SecondElement Content

    </div>

    <div id="ThirdElement">

        ThridElement Content

    </div>

</div>

The CSS

#Wrapper

    border: 1px solid #45a62a;

    width: 700px;

    height: 100px;

#FirstElement

    float: left;

    border: 1px solid #3a486f;

    width: 200px;

#SecondElement

    float: left;

    border: 1px solid #3a486f;

    width: 200px;

#ThirdElement

    float: right;

    border: 1px solid #3a486f;

    width: 200px;

    display: block;

The Result with Float:Right

Notice 2 things:

a) I added a float:left to what was element #1. Why? because now the main parent here is no longer element #1, it’s the wrapper so we must now float element #1 left of the its parent which would be the wrapper div.

b) I added float:right to the last element. This pushed it to the far right, flush with the wrapper’s right side.

I hope this lesson has helped you understand floats better.

Share this post :

Subversion Key Points Condensed

Dave Schinkel — Mon, 18 May 2009 03:46:57 GMT

Technorati Tags: Subversion

del.icio.us Tags: Subversion

Version Control with Subversion

ISBN: 0596510330
ISBN-13: 9780596510336

As with most of us when trying to master Subversion, you might be slightly overwhelmed with the amount of info you have to learn to become a “Subversion Guru” (not just basic use which is plenty to handle, but also build, branch, etc.) wouldn’t it be nice if someone made sort of a condensed version of the key points from this book and other sources for a nice quick reference? Well, that’s what I’ve been doing just because the book is so damn long and there’s just so much to learn about subversion and I need to become a “Lead” on this in a short amount of time. I use this as sort of a long cheat sheet / learning doc for myself as I become a Subversion master. It gathers key points that I felt were important and I laid them out into bullet points. The docs are just too long and ramble too much into paragraphs in my opinion.

While my shortened key points doc (which also contains my own notes or information from other sources) is not completely done, feel free to use by downloading it Subversion Key Points Condensed. I will also add my build process in here once I figure out how I’m going to do that for our team. The doc behind this link will be continually updated till I feel it’s enough for me to get by.

I’d also be curious to know your team’s build process from tagging to push including branches you have set up for different stages in development.

Summary of Agile

Dave Schinkel — Mon, 18 May 2009 01:57:59 GMT

Technorati Tags: Standards

Share this post :

I’ve been reading up on a lot of Architecture and Design Pattern books including MVC and much more as I am working on a huge project lately to redesign the presentation via ASP.NET MVC for our public website.

Agile is something that a lot of businesses abuse that have no clue what it means and they should never be using the word until they wake up and read about what it actual means to be “Agile” and truly change their environment and get their organization to buy into true Agile processes. They have no right to throw this term around when a lot of companies carelessly claim that they are an Agile development group when they are completely opposite. They think Agile is an excuse and weapon to use against their development team in order to “Code & Run” thus disregarding quality of code and ultimately hurting the business due to the rush rush mentality pushed from top down. I’d like to take a moment to quickly list what Agile is along with my own side notes based on some books I’ve read already.

So any fool can tell you that you can’t have quality and good working code never happens when top down does not give adequate time for:

Testing including Unit, Usability, and QA
Learning, allowing developers to sink in what they’re coding or researching while coding
Attention and time to apply good development practices and time to be able to think before you code. Time to apply principals and really be able to think about SOLID, DRY, etc. When you code & run, this goes out the door because all you’re thinking about is the idiot manager breathing down your neck

What is Agile? Here’s a list of some bullet points I’ve accumulated from various references:

Book: “Microsoft .NET Architecting Applications for the Enterprise” by Dino Esposito

Emphasizes the incremental building of the software
- Dave’s side note: rather than code & run cowboy who tries to fit EVERYTHING into one date…fail
The project goes through a series of iterations that include design, coding, and testing
Each iteration produces a deliverable but incomplete version of the system.
During an iteration, you focus on a single requirement at a time and implement it
At each iteration, the team enters design changes and adds new functions until the full set of specifications are met
Agile Methods focus on people and communicating rather than on software building and processes
Change and refactoring are key in an agile methodology
User feedback is valued over planning
Feedback is driven by regular tests and frequent releases of the software
Working software is the primary measure of progress
- Dave’s side Note: Note that this says “Working”. This means frequent releases but code that has been built well and tested often and has a very low number of bugs. Working means not only bugs but it works for the customer based on their expectations and that the software was built based upon their frequent feedback & usability tests. Code that was not produced in a code & run mentality where the stakeholders value more than just results. Stakeholders (top down) understand that unit testing, usability testing, QA testing are critical, and allow for the Leads to build this into the iterations
Project starts and only a few requirements are known because you know for a fact that many more will show up between now and the end
- This is not an issue because you take a subset of the existing requirements that you know you’re able to implement in a single iteration
At the end of an iteration you deliver a working piece of software. It might be incomplete but it works
If something changes in the requirements or proves to be wrong, you refactor it
The team is highly skilled
- Dave’s side Note: Agile will not work for teams who have only low-end developers. While some people say you have to have all high-end, I also disagree. As long as they are solid in OOP, and care about using good development practices recognized in the community then you’ll be ok. It’s the slop coders that will not do ok on your team or those coders who do not care about SOLID or DRY. You’re not asking for perfection but the developers on an Agile team must be aware of and try their best to code clean testable code
Customers and developers work together daily
- Dave’s side Note: while this might be what agile is, this is a bit too much in my opinion. Every day is a little overboard especially when developers are expected to hit an iteration
Results are immediate and visible
- Dave’s side Note: This means you always have something that is able to run on your test server even though you’re local copy may not be able to run as you’re working on it. Implementing continuous integration helps to ensure that you have a solution that you can run at a given moments notice so you can show to your customer the state of the feature at any time
Iterations are often measured in weeks. Typically two weeks
Agile methodologies is a blanket term. When you refer to an agile methodology, you aren’t talking very precisely. Which methodology do you mean, actually?
- For example, Scrum is a popular agile methodology. It is aimed at managing projects and works very well with Agile development

Book: “Practices of an Agile Developer” by Venkat Subramaniam & Andy Hunt

Creating software is not a linear process or deterministic process. Software development is more like surfing. It’s dynamic and ever-changing. It’s unpredictable and risky.
Iterations are small repetitive cycles
If you have problems with absenteeism, slackers, or outright saboteurs, this is probably not the approach for you
Automate Acceptance Testing
When developing code always choose readability over convenience
Listen to Users
- Every complaint by your customer holds a truth
Use unit testing to provide instant feedback and to make your code robust
Fixed Prices are Broken Promises
- to a customer’s view this is completely reasonable but in reality a software project is subject to all the simple mistakes plus fundamental changes to the requirements
- Given the inherent volatility and irreproducibility of software projects, coming up with a fixed price ahead of time pretty much guarantees a broken promise in the works
- Ask yourself can we make some sort of deal?
  - Dave’s side Note: meaning for example if the task is too large or can’t be fit into the iteration, can we swap features so that we can still keep on track with the iteration?
Justify Technology Use
- Does it really solve the problem?
- Will you be tied to this technology?
- What about maintenance costs?
You don’t leave testing to the end of the month
Integrate early, integrate often
Automate deployment early
- if it works on your development server fine, but it needs to work in the production environment too
- you need to be able to deploy your application onto the target machines in a reliable and repeatable way
It’s ok to have ego but not if it’s unhealthy and negatively affects the team
Let your customers make the critical business decisions based on options you give them
- However they shouldn’t make all the decisions. For those you don’t agree with, discuss them early
Question until you understand
- Don’t accept what you’re told at face value. Keep questioning until you understand the root of the issue
Small reachable goals keep everyone moving forward
A regular rhythm that’s too intense will burn the team out
Criticize ideas, not people
Provide useful error messages
Review code
Be a mentor
Allow people to figure it out
Don’t over engineer, keep it simple
- managing to get 17 of the GOF patterns into code is NOT being agile. You’ve making your code too complex for the team and over emphasizing patterns
Invest in your team’s learning
Keep your balance. Know that you can’t be an expert at everything
Ask yourself whether you’re projecting too much of the old attitudes and approaches onto the new. Unlearning is important. What you knew worked a long time ago could be making your code or team ineffective.
Do not make people defensive on the team by your actions
Do not blame, but work as a team to fix the problem
Quick Fixes become quicksand
- projects seem to attract a lot of time pressure. Pressure that encourages you to take ill-advised shortcuts
You don’t stop gathering requirements and feedback as you being to code
Do not take shortcuts in your code
Make changes as soon as you realize that things are headed in the wrong direction
Always start with and tackle the most difficult problems first
Pay attention to your attitude and the team’s. A professional attitude focuses on positive outcomes for the project and team
Software is never really “done”
Tackle small problems when they remain small and explore the unknown before you invest too much money into it
Be prepared to admit you got it wrong as soon as you discover the truth
Ask the users what features are essential to make the product usable. Don’t be distracted by all the nice features you might possibly have
If there is not enough time in each iteration, then the tasks are too large or the iteration is too short
Timesheets are intended for payroll and accounting and are not really meant to measure progress of work in software projects
- They rarely represent the reality of work completed and therefore aren’t useful for project planning, estimation, or measuring performance. Odds are it probably took longer than you anticipated. Adjust your estimate based on experience. If you underestimated a two-day task and it took six, you were short by a factor of 3. Therefore multiply your estimate by 3.
Measure progress by keeping the road ahead very visible. Don’t kid yourself or your team with irrelevant metrics.
- The best way to do this is by using a backlog. A backlog is just a list of tasks that still need to be completed. When a task is completed, it’s removed from the backlog. With a backlog, you always know the next most important thing on which to work.
As new tasks are introduced, they are prioritized and added to the backlog

As I find more sources I’ll update this post and bullet point those as well going forward.

Share this post :

Intelligentsia Coffee Tour

Dave Schinkel — Sun, 17 May 2009 03:00:51 GMT

del.icio.us Tags: Coffee

Flickr Tags: Coffee

Technorati Tags: Coffee

Share this post :

Intelligentsia is quite possibly the best roaster in Chicago. Their coffee is probably the richest I’ve tasted, second to but tastes close to (in my opinion) Italy’s Illy coffee based on my experience tasting Illy both here in the states and in Italy during a trip I took a couple years ago. Not only is Intelligentsia Coffee very good, but the entire culture around their stores and the way they make coffee is not like your usual roaster.

I had the opportunity to take their coffee tour a couple years ago. And a great tour it was. We got an in-depth look at their facility and the huge roasters inside that ranged from 25k – 50k or more. It was simply amazing to see these machines and to also learn how they test their coffees in their tasting room and actually saw coffee plants growing there as well. So all around it was not only a tour of their facility but we learned how well they control quality and pick their coffees around the world.

Here are a few pictures I took while at the tour. I Hope you like them.

Share this post :

Foo is Gay

Dave Schinkel — Sun, 10 May 2009 20:58:56 GMT

Am I the only programmer out here that thinks the term “Foo” as a generic placeholder just sounds gay? I don’t know why the hell we use it but I just think it’s gay. Thought to share that point useless as this post is. Foo seems like some kind of term that developers deem as “cool” to use but it’s just plain nerdy. Sorry but it just sounds dumb.

How Would You Run a Business?

Dave Schinkel — Sun, 03 May 2009 05:23:47 GMT

del.icio.us Tags: Management,Business

Technorati Tags: Management,Business

Share this post :

I’m sure a lot of us have pondered on starting our own business. Tired of the “ignorant idiots up top” continually making stupid & blind impulsive decisions time after time and disregarding you or your team’s input. But for a lot of us, this just is not feasible. Not because we don’t have the business sense, the passion, the drive, and the persistence to wake up each day with the desire but rather other variables that block it. Some may be the wife, money, kids, time. For anyone who is passionate about starting a business, you know fear is not one of those reasons. For me, starting a business is like the lottery. I most likely will day dream about it simply because of one of those variables. And simply because I do need to focus on my own current job because one of those variables will ultimately prevent me from starting my dream.

Now, a lot of us could simply stop working and get a nice loan or backing from an investor. But again that depends on other variables (wife doesn’t like the risk, etc.) and sometimes you have to respect those variables no matter what. Believe me after seeing so much chaos in IT and just organizations as a whole across many departments and many types of businesses and sizes, it’s enough for someone like me to puke and want to start a business of my own NOW. So for me, again I will dream about this because I don’t know if it’s feasible due to time and wife. And it’s not her fault, it’s because I love her and respect that she doesn’t like the risk. If we had 500k to invest I’m sure it would be feasible but this is the path life has chosen for me for now. I personally would be willing to take out a loan for 200k and start.

I’ve worked at a LOT of places in my career in IT. And I’ve seen so many wrong things that CEOs, VPs, and IT managers do and so many employees get so frustrated with it. Some decisions or actions are so stupid, you wonder how the hell they can even figure out how to brush their teeth in the morning and how the very business you’re working for makes money at all. A lot of it is dumb luck or just a good business idea, and it’s not because the guy high up is smart. So with what I’ve seen and just how I am driven (process oriented, not just $$), I know I would probably be a multi millionaire by now if I did have my own business.

Now obviously I do still think about this all the time and this is what I’m doing here, day dreaming in this post like a lot of us do. I don’t spend time on it because I have a job to focus on at the moment.

But back onto my day dream. Running a business means thinking about inventory, resources, yada yada but I’m here today to talk about people and process. By understanding how to effectively manage and run a business and really utilize your best resources (people), your business will grow and you will be happy. It’s not about $$ and cents 100%. Well it is in sense, but if you undermine the people aspect and the process aspect, you’ll eventually fail. You may not be failing right now and have done very well, but you will eventually if you run it “like a cowboy”.

Well, for a start, here’s my thoughts about people and business in general. It’s just a start and sure I’m not an expert on it but I don’t believe you have to be an expert. You just have to have common sense, smarts, drive, and ability to communicate and listen. What I can tell you is how I’d approach it if I did and I think it’s a good approach. Who knows, maybe some day I’ll have that opportunity but for the long term, probably not.

With that, here is my “philosophy”:

1) Know Your Employees

Do you even know about the people your managers have hired to work for you? Do you know what their past experience was? For example you’ve just hired a developer who has a breadth of experience and has seen a lot of different environments and processes probably even bigger than your IT department. Worked for even big fortune 500 companies to mid-level software shops who were effective, to even mom & pop (all of these). If so, you just hired a gold mind because they’ve seen it all. They have seen what works and what doesn’t in that particular area of work. If you do not even know what they do or what they do or have done in past positions, you should not be running a business. If you do not listen to the ideas they might have, you are shorting yourself as an owner. You’re ROI on that person is going down the drain.

Take a look at their resume. Think about those environments from which they’ve been and think wow, this is something I need to really tap into with them. If you don’t know, sit down and talk to them and listen to their thoughts and ideas. They will respect you. And you will benefit greatly from this experience. Humble yourself as an owner and know them and what they could possibly bring to the table. Mind them as if they were data.

2) Communication and Respect is key

If you hire managers and they do not communicate effectively with their employees, fire them. What is effective communication? This is what I’d expect of my management team:

Do not micro manage your team. Give them breathing room
Keep Politics out of your team or around them
- Stomp it out. This doesn’t just mean an “open door policy” either. Stop making decisions based on politics instead of what you should be doing which is making decisions based on reason or good process.
- Your employees know when you make ignorant decisions. So choose and make them wisely before you go off on a tangent making changes or decisions for your team.
Do not play favorites
Be a mentor
Understand that you do not know everything and they may know more than you..be humble and learn just as you teach them
Respect them and lift them up
Understand there are variables outside work that affect your team and your projects
Do not take someone else’s idea as your own. Give them credit in your conversations with others

3) Agile Corporation is key

Now, I know Agile is a term abused by so many corporations for an excuse to “code & run”. And that most think Agile is a term only for a “development” department. That is not true, Agile can be applied organization-wide. But you need to understand what it truly is first. Read books on it. Understand it before you preach it to your customers, potential hires, etc.

It should and can be applied all departments within an organization. Code & Run can be anything from “Marketing & Run”, to “Manufacturing & Run”, you name it. It means you’re developing products without a controlled environment, scope, iterations, or priorities and therefore producing chaos in your organization and poor quality products for your customers. It means you’re going to fail on those deadlines. That’s why they have Lean Manufacturing, Lean Programming (which is part of Agile), and more to give sanity and organization to a business so you can see results without whipping your employees.

And if you don’t have an inkling of what it is to have priorities and organized structure to your business when you create products, and you’re a cowboy running the shots, you’re lucky that your business has grown or been stable. It is pure luck because you have no clue of what’s going on or what your underlying departments are doing or who is working in it. This is what breaks a business faster than anything and degrades employee moral.

Agile has to do with not only having a good process but both people and process.

Agile Enterprise-Wide is in part these aspects:

1) Communication is key. Face to Face meetings is key. Do not live in your email

2) Having well defined chunks & which means obtainable sprints and iterations per department is key

This also synchronizes departments into nice controllable pieces within your company. Having a Work Breakdown Structure (you know, defining all possible tasks, resources, etc. in a project management tool such as MS Project or other) is absolutely key to help defining the iterations and scope of work. If you do not do this, you’re promising the business failure and if you’re on the CEO side, you’re expecting your team to deliver something of a black hole.

3) Understanding that fixed-price contracts are a recipe for failure with your departments

Be able to Negotiate with your organization as an owner. Do not force feature after feature and still automatically expect that iteration to get accomplished by your teams. You’re pushing failure and broken promises here on your organization! If you come in with new features that you want to add to an existing scoped sprint, you must know as a business owner that you are impeding on the process. You must be prepared to wheel and deal. Know that you have to be able to possibly expect that to introduce new additions to a sprint or iteration that:
- The schedule might have to be extended
- The team says to you that no, we can’t add anything more to meet the already agreed deadline. We can however swap out something but no, we can’t handle that in the existing small chunks that we previously scoped out with you. Be able to stop your pride, your ignorance and accept this trade.
If you are expecting results without reasonable and obtainable scoping of projects from your department, you will be very disappointed and it’s your fault. Stop expecting the “impossible deadline” and start creating solid business plans and understand that that quality comes before speed. Understand that your employees do not have 24x7 to work for you. That should make you desire a solid process when you think about deadlines. That there are always unexpected variables that come up with any iteration.

That a product is always evolving and never completely “done”. Sure, you can get certain features done, and those are chunks of that product and should be done in iterations that are achievable by your resources, not ones that are forcing a chaotic environment and sweatshop which produces bad quality products because everyone is running to create your features. Iteration task lists are to be prioritized and scoped. If you do not do this, all of your departments will fail to deliver because your expectations are based on NOTHING. No substance, no priorities, and no realistic and obtainable deadlines based on the resources you have

4) Testing, Testing, Testing

If testing your products (again does not matter what department here) is not part of a defined iteration, you’re running chaos. I would be sure that all departments have adequate time to test in my organization because I know the product will be reliable, extendable, maintainable, and produce far better ROI than an environment with fires later on
Testing does not happen at the end, but during the entire phase of an iteration
You should complete the work (in development environments we have a formal name for this called “code complete”) far enough in advance to allow QA, Engineers, or others enough time to test it well

5) Investing in Your Existing Team

Your team has skills. They have experience, did you know this? It’s amazing how many CEOs neglect this because they think they know it all or are too busy to invest in who they already have that is capable to help them grow the business. Your employees are a gold mind. Tap into this, don’t ignore this
Your employees are not just worker bees, they are a lot more than this. Stop treating them like just workers and invest in their ideas and what else they have to bring to the table.

6) Letting your Customers Make the Decisions

Grow your products and feature set based on continuous and frequent customer feedback. Seems like common sense right? After all, they are who you are trying to please and sell to.

7) Measuring Real Progress, not Unobtainable/Unrealistic progress

As new tasks are introduced, you need to adjust the list of tasks. Either remove one to fit the new one in, or move the scheduled date. Do not produce iterations that are unachievable due to the “Get the impossible done at an impossible due date”. Setting yourself up for failure and unrealistic expectations by your teams does nobody any good.

Keep department iterations simple and in manageable chunks. This means again, keep features and dates obtainable so that you see continued progress and hit deadlines.

8) Justifying the process, technique, or technology you wish to use or are presented with

Do not just buy into a new system because of some savvy marketer or sales person who came to your door step stating that this “can do the world for you”. Question the backend of it, question the process, question the future and maintenance of this and validity to your business. And same goes to every department. First listen to what they are explaining to you. Don’t rush to negate or to approve. Listen. Understand it first. See the value and justify it then. If you’re a cowboy making decisions by impulse, again what the hell are you in business for? Every business owner knows this is the worse thing you could do for a business. Yet I’ve seen so many business owners do this, so many VPs do this and we wonder why America business is failing
If nobody is able to question things as a team, your team is ineffective because you are not letting them hone in on what could be better for the business

9) Stop micro managing your business and let the people you hired figure it out

Empower them and you will see return on ROI like you’ve never seen. Do not miss this opportunity. Stop hiring consultants and tap into them and empower them. Stop tapping into endless salesmen or consultants who stop at your door and ask your employees if that product or person makes sense in your organization

These are just some common sense practices of an “Agile Corporation”.

3) Understanding that Your Employees Have a Life is Key

Even though to stay in business you have to “be ahead" of the game”, I’ve seen many organization who are so far behind of the game and this is because they don’t understand people let alone process. They have no process, controls, bad communication and their expectation is to deliver x product in 2 days. “I want it now syndrome” and it’s plain ignorance. If you don’t know what goes into a product and you expect immediate results, you should not be in business. What you you want instead is controlled delivery. You want tested delivery, and you want extensible and maintainable delivery of your product. Expecting shit done in 2 days is well, ignorance because you’re expecting your employees not to be able to

Learn some new things while they do it. They have no time but to hack some process, design, or whatever it is together
Spend time outside of work living normal. If you can’t allow your employees to live, your business will DIE.

So what I’m saying here is, you can’t slave drive your employees like this. You’ll wear out the engine and all of its parts will either fly everywhere or eventually fall out (people will leave). I don’t care how much you keep saying that you need to deliver results, if you burn out your workforce, and do not understand that they have kids and they need time for this and that their life is NOT going to revolve around YOU and your organization 100% of the time, then again then you’ll fail and also cause health problems for your employees and their families. You’re expecting YOUR business to be their life and that’s not reasonable. They did not go into business YOU DID. You can expect hard work, passion, ok but then stop. Relax and also enjoy your life also on the weekends or you’re going to worry yourself or make yourself sick as a business owner. I’ve seen it from my very own uncle. And you don’t have to see this. How many CEOs die of an early age because of this micro managed, slave driven craziness? Stop slave driving your business and making expectations that seem to come out of thin air due to your dangerously impulsive tendencies.

One word: “Work Life Balance”. If you’re an owner and you don’t walk this walk, you’re setting your business up for failure and setting up health problems for not only you but your employees because you are totally disregarding what’s “normal”. Many organizations preach it but then their expectations are so unrealistic, that nobody can obtain or practice it in their workforce. Not good.

4) Expecting Your Managers to Practice “Balance” in Managing Their Staff is Key

This goes back again to micro management. Your managers do not need to hound their subordinates to the point of irritating them. If they feel they have to be in every aspect down to every hour of an employee’s work day, they need to be fired. They do not understand the balance of managing a workforce because they typically encompass the following traits which effectively ruin a team:

a workaholic
overly paranoid about everything
driven completely by “self”, not by “team”
do not trust or take advantage of the skill set of their team for which they hired which causes resentment and frustration to the team because they feel and probably are undervalued
Constantly feels he/she has to know what’s going on every hour or else they’ll have a heart attack. Let me tell you, you are interrupting and your getting in the way. By doing this, your team cannot concentrate and neither can you!

Chill. Wait. And you will see that your team can handle it if you’ve put in the proper controls, process, and standards. If you do not see results and have to continue micro managing, then you should not be a manager and you are hurting the business and its employees.

5) Listen to The People You Hired and Utilize Them First is Key

How many times have you seen managers or owners hire completely competent employees to help drive the business and give great ideas based on their own experiences but never utilize this. And what they do is go off the deep end and micro manage them rather than ask them for ideas and let them help drive the business? Stop underutilizing your internal employees that you already have especially if they have been many other places and have a LOT to give you advice and expertise on. A CEO should not be the end all. Good CEOs use their employees and their ideas, not always their own. Any CEO that has been successful would tell you this guaranteed and any management course will also tell you this.

The business is a “we” not an “I”. Trust your employees and utilize their past experience. Don’t go off and introduce chaos or fail to utilize them. Don’t introduce variables that start a feeling as though you’re completely bypassing what they have to offer to the company and to the team. What do I mean? I mean sit down an listen to the ideas they have and empower them to help YOU drive the company. You can reject some ideas but you better do so by understanding the problem domain, listened to what they said (really listen!) and then you can reject but don’t be a jackass and completely close yourself off and deny everything that your employees are trying to tell you.

6) Stomp Out the Politics in Your Organization When You See it is Key

Don’t be blind to the politics happening in your own organization. Observe people. Don’t just observe $$ and inventory.

Sure, in larger organizations this is harder to control. You can’t be everywhere as an owner. But, you can be there. And you can stomp out politics as you see it at various moments. When your management starts to be political, stomp it out and remind them that this is a team. This is not about you, not about them, it’s about working together so watch your tone. If I hear decisions made without research, without my managers listening and instead talking trash and making lose decisions based on non-process oriented techniques or based on playing favorites then I’m going to stomp that out and have a talk with my manager(s) in those situations.

Politics ruins departments and team effectiveness and team enthusiasm.

7) Promote Internally Based on Ability, Contribution & Potential; Not based on Political Reasons is Key

How many times have you seen someone become a manager because they are a kiss ass? Well I can tell you that if I run my business, I will have a good hard look at if a promotion makes sense when a manager of mine suggests it. I will drill them with questions, pretty much interview that manager to make sure he has made a sound decision on this. Does that manager have solid reasons behind it? Does that employee that this manager want to raise up:

know how to stay out of politics themselves?

able to lift others up?

Doesn’t have to be a genius but still smart and capable of becoming 3x better over time - may not be doing everything now, but has great potential?

understand that micro managing and slave driving is not how to manage?

have confidence and believe in what they preach? In other words are not always a follower but lead by giving solid ideas?

able to listen to others before mouthing off or making decisions? Take advantage of their own team’s internal talent and grow that existing talent?

have a good background even from other companies where they can really take off and help my company with things I’ve never even done before? In other words, can I utilize their talent as a business owner?

these are the reasons to promote

8) Invest in Their Learning is Key

If you do not invest in improving your employees in every department, how can you expect your overall business to continually improve?

What do I mean specifically about how to improve them?

a) Team learning sessions by the managers of those teams. Might not hurt for the managers to have brief training sessions or group sessions where even individuals on the team can train the rest of the team. Everyone has something to teach each other so collaborate and meet just to do something like this once in a while. Example on the development side since I’m in IT would be for me to train the rest of the guys on the team some cool jQuery stuff. I may not be a manager but doesn’t mean even my manager or others can’t learn from me.

b) Bring outside training in. Have a day of training. Whether that be HR related, Programming related, whatever, but enhance their skills. And do not bring in lame training. Bring in something that really gets to the gut of things and brings tools to their plate that they can start using immediately in your organization.

c) If they want books on management, personal development, programming, marketing, etc. invest in those books or other online training resources. If they’re willing to take on the initiative to help train themselves, shit you can’t ask any more motivation than this!

d) If they want as a team to go to an event that relates to the job function let them! Invest in that time away form work. Stop the worry about deadlines all the time and let your managers take their teams to some effective day events (trade shows, etc.). It’s less time you have to take to attend them as well and when they come back, USE YOUR EMPLOYEES and what they learned there.

9) Stop the Bullshit is Key

What do I mean by this? Stop the prep talks, stop the fake corporate talk. Be real and be a friend to your employees. Tell it how you feel and listen to them. Don’t tune them out. Don’t give them cheese talks. Understand that your employees are not stupid and they can see right through bullshit.

10) Gestures are Key

Ever see a CEO, VP, ect. walk around like they think they own you rather than respect you? I have. And for example one of my friends was talking about how a CEO with whom he worked closely with related to development projects one day in the bathroom totally disregarded he existed when this lead developer tried to say hello to him. Because this lead was leaving the company on good terms, the CEO felt that he was no longer valuable. Let me tell you that this does not show character of a CEO, VP, or manager. Even if that employee felt that this place was not for them, always respect them as long as they did not do the company harm in some way or another.

If you walk down the hall, put a smile on your face at times. I’m not expecting everyone to always smile because that’s bullshit also but let me tell you if an employee says hi to you, let them know that you’re not a robot. Say hi and engage them in a friendly conversation not even about work. Talk about real life! Ask them how their family is, ask them how they like it here so far. Be real!

A CEO should be respected, not feared. A CEO should be part of the team, not distant. A CEO should be someone anyone feels comfortable talking to no matter if it’s someone from the shop floor, the maintenance worker, a secretary, or anyone else. Because how you act will trickle down to your managers and employees. What you present is the atmosphere that will likely trickle down. And you want your company to reflect positive tones.

Well I must stop here for today. I could go on and on. But this is my personal philosophy as I see it (brain dump from my experience and beliefs). This is honestly how I would run my business and I feel this is just being a smart human, reasonable human, and one who can successfully run a business in the long run.

Share this post :

jQuery Tabs Plugin with Images

Dave Schinkel — Sun, 03 May 2009 01:25:29 GMT

Technorati Tags: jQuery

The jQuery tabs is a nice plugin. But depending on how creative your site is and how aesthetic it’s function needs to be, a lot of times you’re not going to use it as is because it simply looks like a “developer designed the tabs”. So, to pretty up the tabs, you can simply set the images and then when you click just change out the image to show an active image using jQuery selectors.

Here’s how I did it:

<script type="text/javascript">

     $(function() {

         function handleTabSelect(event, tab) {

             if (tab.index == 0) {

                 // tab 1 selected

                 $('img#imgTab1').attr({ src: "/Content/Images/Product/tab1Selected.png" });

                 $('img#imgTab2').attr({ src: "/Content/Images/Product/tab2Unselected.png" });

             else if (tab.index == 1) {

                 // tab 2 selected

                 $('img#imgTab2').attr({ src: "/Content/Images/Product/tab2Selected.png" });

                 $('img#imgTab1').attr({ src: "/Content/Images/Product/tab1Unselected.png" });

         // Set Tab Constructor values & initialize tabs

         $('#tabs').tabs({ selected: '0',

                         fx: { opacity: 'toggle', duration: 'slow' }, select: handleTabSelect });

});

 </script>

The html:

<div id="tabs">

    <ul class="tabImages">

        <li runat="server"><a href="#Tab1Content"><span><img id="imgTab1" width="262" height="67"

        src="/Content/Images/product/tab1_Selected.png" /></span></a></li>

        <li runat="server"><a href="#Tab2Content"><span><img id="imgTab2" width="262" height="67"

        src="/Content/Images/Product/tab2_Unselected.png" /></span></a></li>

    </ul>

   <div id="TabsMain">

        <div id="Tab1Content">

            <asp:ContentPlaceHolder ID="cphTab1Content" runat="server" />

        </div>

        <div id="Tab2Content">

            <asp:ContentPlaceHolder ID="cphTab2Content" runat="server" />

        </div>

    </div>

</div>

So the handleTabSelect event handler is fired whenever you click on a tab. Based on what tab was clicked (index), it will switch out the images. Pretty simple but the tricky part is figuring out how to do that in jQuery if you’re not as familiar with the syntax and are new to jQuery. In jQuery as everyone knows, you can manipulate (do something with…add, changes, remove) any part of the DOM in your page (html elements, css elements, and more) but again, it’s knowing the jQuery syntax first before knowing how to manipulate the DOM with jQuery so study up!. And this is how you would manipulate the images here in this context with jQuery tabs.

And obviously the tab1_Selected.png and tab2_Unselected.png speak for themselves..you’re just going to change the image to show a selected vs. not in jQuery once a certain tab has focus.

I highly recommend (I have these) these 3 books if you’re going to start jQuery:

Learning jQuery 1.3

ISBN: 1847196705
ISBN-13: 9781847196705

jQuery UI 1.6: The User Interface Library for jQuery

ISBN: 1847195121
ISBN-13: 9781847195128

Learning jQuery: Better Interaction Design and Web Development with Simple JavaScript Techniques

ISBN: 1847192505
ISBN-13: 9781847192509

The Learning jQuery book (3rd one above) is a tad bit outdated but not by much. jQuery is in v1.3 but the other is still overall a good book and well worth it to learn jQuery no matter what version. I recommend having all 3 of these books. The internet is nice but you will get up to speed at least with jQuery in my opinion with these books first and internet as a supplement.

And as you can see, there’s no excuse not to use tableless design in today’s presentation layer. There’s no point It’s so much cleaner and easier to maintain. Tables add so much damn clutter to the page. Learn CSS tableless design. Not easy at first but learn it. It shows you care about not only standards but clean maintainable code in the presentation layer. And ASP.NET MVC also works well when you have a nice clean page using tableless design in your views. I cannot imagine positioning all this with tables anymore in my career and I will not if I can’t help it.

I’m not going to post the CSS, because all boils down to is creating the class ids for tabs (required by the jQuery tabs plug-in to work), tabImages, TabsMain, Tab1Content, and Tab2Content. It’s pretty self explanatory and if not just comment and I’ll explain in this post.

Share this post :

Interviewing the Interviewee

Dave Schinkel — Fri, 01 May 2009 03:29:18 GMT

Technorati Tags: Management,Job Searching

Throughout my career I have both done some interviewing and of course attended many interviews. Most of the focus from the candidate is being prepared to answer the employer’s questions. But what many candidates fail to do is look out for their own best interests in terms of finding a job that they will enjoy in terms of environment, technologies, and people.

This is one of the hardest things to do. To gauge whether the employer who is about to hire you is a place that you believe will be one that you will want to stay and enjoy getting up every morning and to spend 75% of your life doing. While a job is not perfect, it’s important that you ask the right questions during a technical interview. You’re not only trying to impress but if you do not look out for your best interests, you’ll end up leaving and that does not do both parties any good.

Now, on the contrary, if you are the interviewer, you have have an obligation to do the following during an interview. This post is about the interviewer.

As the interviewer, do not:

1) Sugar coat your answers

If a candidate that you really like asks you questions such as “Do you have this standard or system in place”, or “Are you using this or that” do not sugar coat these answers. Just as you expect that interviewee to be honest and true, you also must be as well in return. They are investing their time to come on site to interview with you so you should be at your best as well as an interviewer. If you know that sure, we’re going to use this technology soon but you have not gotten it in place quiet yet, be honest. Give the candidate confidence that they have a good vibe of what’s going on in your current environment.

For example:

Bad response: “Yes, we use it” when it’s not true.

Conclusion: You just lied. You’re just as bad as the lying interviewee.

Good response: “Yes, we’ve definitely decided that we plan on using this tool. We have business buy-in and that’s not going to change. Now I can tell you currently we are not using it but we know we need it badly and we plan on starting that project in (month, year). We do not anticipate this plan to change. And actually, the person who fills this position will most likely help to integrate this.”

Conclusion: By giving a more detailed response, you are being forth coming. The same thing you expect from your interviewee. This is a two way highway. Neither side should be sugar coating anything and you should be able to talk to each other in honesty hiding nothing. It’s up to either side to digest what is said and make an accurate decision. By sugar coating, you are taking risks for the business. And sugar coating by the employee is taking risks for themselves and your business. You want a confident enthusiastic employee coming in, and a happy employee staying for good because what they were told was not a lie. This will provide return on ROI the most.

Good response: “Yes. In fact we asked the business x months ago to purchase the source control system. They are not quite sold on that but we are trying our best to get it accepted so that we can move to it as quickly as possible because personally, I know this team needs this.”

Conclusion: The second response is kind of vague but it’s still honest. In your mind as the interviewer you really mean it and it is complete honestly based on solid facts. It’s saying we’re definitely interested. We see the value. We want that particular solution. And we’re really trying to get the business to buy-in on it. This might be just enough to convince the candidate with whom you want to make the offer to accept if that time comes.

They may see that hey, this place knows a good thing, and they care about good practices or whatever the candidate may be seeking to hear. You do not know what the interviewee is going to pondering about about but as the interviewer you do not want them pondering about “hmm, are they serious or what did they mean when they said this or that” when that candidate could be the one you finally decide to go with. You want to be clear and up front with the interviewee in terms of what your current environment is and what you plan on moving to so they feel confident that you are being real to them. Do not lie, do not sugar coat answers on your environment or the business in terms of process and technology.

2) Make the candidate feel uncomfortable

The entire point of interviewing a candidate is to provide an atmosphere where you can engage in meaningful and effective form of communication. Sure, you can absolutely outright drill a candidate. But also throw in some humor, real conversation.

When you drill calm down and act normal and state it in a calm voice so they can concentrate on the question, and not you

Don’t sit there like a nun with a ruler about to slash some wrists with your tone.

Don’t be a robot ask questions.

Write things down for yourself as well as this shows the candidate that you are engaged and listening to them.

Give them friendly eye contact.

Because the candidate which you might have liked the most might get a cold vibe from you and not accept that offer if you decide they were the one after the fact. Does that do the business any good? no. It wastes your time because you were not able to communicate as a normal human being. While you need to serve your agenda, you need to provide an atmosphere that doesn’t force the candidate into trying to sugar coat their answers, or worse lie because you’re so damn rigid in your interview. I believe in technically drilling, but also if you are able to choose smart questions, you won’t need to carry that “scary look or vibe” and still be able to gauge their expertise. The questions you ask should be smart enough to be able to determine whether the person is competent enough without acting like some kind of scary military dictator who is hanging you by the rope when asking questions.

Remember, their impression of you matters just as much as the impression of them. If you’re a complete jerk during an interview, cold as hell, and they sense that you’re there to just make a very uncomfortable interview, that word will travel about the business and the way you conduct business. And their impression of you will be remembered even if you do not hire them. You want them to be impressed and respect you.

3) It’s ok to give a test, but don’t make them spend hours and hours on something because it’s more than just a test but really a mini project

Want to test them? Sure, I’m all for it. But don’t expect them to take 2 days and overnight it, or create a test that takes well over 3 hours to code on-site. Don’t create a test that is not feasibly done in a couple hours. In other words, don’t give them some kind of mini project. The test should take mo more than a couple hours. They have a life also and obligations to their current job possibly. Give them a 2 hour test and be done with it. This is an interview, and you can see what they’ve done in 2 hours by style of code, approach, etc.

Don’t expect perfection either. You don’t code perfection on the job in 2 hours always, so why expect it in the test. If they have a decent understanding of OOP and understand the concepts you’re looking for by what you have seen (based on your analysis) that shows they can do most of it and do it half way decent, then that’s good enough. Looking for a perfect solution during a test is not something you should be expecting. Now if they produce slop, obviously they’re not for you. But you make that decision and also be aware of their time. Also, do not make the test the ultimate variable to hire a possible good candidate. Look at all variables including what they said technically via answers they gave you verbally about topics, where they’ve worked, what projects they worked on and more.

I think as an interviewer I’m smart enough to come up with questions that a candidate can answer without invoking a pressure situation to gauge if they qualify. I know as an interviewer I can ask the right questions that ultimately allow me to gauge if this person is good enough (I’ll come up with a post on this later). If you’re a bad interviewer, that means you have to put on some sort of show to pressure them into answers and this is not effective. Bad interviewers are unprepared, and they don’t know how to ask good questions about code or even business related questions. Interviewees can tell this…they can sense this.

So be smart and prepared when you interview. Be honest and detailed on your answers so that both sides win. Ask smart questions, not the norm. Ask questions that will give you answers that have substance, not canned questions that every interview has asked in the past 20 years.

These are just a few tips, I have many more but maybe another day!

Share this post :

Organize your Personal Resources – Just use a Wiki!

Dave Schinkel — Mon, 27 Apr 2009 03:12:05 GMT

Technorati Tags: Wiki

I don’t know about you but I got sick of adding favorites, printing articles, trying to remember certain tools I used, techniques in code, or whatever the case was. I’d manage this information by adding them to favorites, writing this down on paper, tossing it in the garbage because I can’t stand clutter and then wish I hadn’t, etc. The point? Other than your team’s Wiki (if you have one), just use a wiki for yourself to organize YOU at work and to keep a nice repository of information for the following items to keep your productivity up:

Work Urls
To-do List
Things you worked on list (good for a resume)
Urls to websites or articles you like or has most value to you
Example code you’ve done that you want to remember
Organize your project docs
Keep a list of passwords or contact information
Keep a list of cheat sheets for code

You name it, a wiki can allow you to keep a running tally of resources you like to work with when you go from job to job. keep adding sections for new places or clients and add to the wiki. It is like a personal knowledgebase and you only need one thing, a wiki! It’s much easier to keep things in one place and runs over a database.

I recommend a .NET based open source wiki called ScrewTurn Wiki for this as it runs over SQL Server. Back up your wiki and port it to whatever computer you like in the future. A wiki lets you add all sorts of information (Urls, docs, lists). The latest RC 3.0 is in .NET 3.5.

And here is the ScrewTurn Blog to learn even more about recent happenings.

Some sites currently using ScrewTurn Wiki (easiest way to find these is search by “Powered by ScrewTurn” in Google):

Dario Solera (Owner of ScrewTurn)

Cruisers Running Club

MyCloudApp.net (Azure Services Platform Info)

Hooked on LINQ (really nice example of utilizing Screwturn)

TFS Examples

SQL Injection Wiki

Jasinski Technical Wiki

OpenNETCF Community Wiki

AirData Wiki

Team Foundation Build Recipes

Projee.com

IOS Crash Analysis and Rootkit Wiki

BritishMicro

SIROY WIKI

Also see the ScrewTurn Wiki Plug-in List including a Syntax Highlighter.

Please digg, dzone, & kick if you found this post interesting or useful.

Getting up and Running Quickly with ScrewTurn Wiki & SQL Server

Dave Schinkel — Mon, 27 Apr 2009 01:34:59 GMT

Technorati Tags: Tools,Open Source,Wiki

The docs are “ok” at best so here are my quick instructions to help you understand quickly how to get ScrewTurn Wiki configured to use a SQL Server Database.

This is based on version 2. of the wiki. The RC0 3.0 has improved the process a LOT so if you are not using the RC, this should help you save a lot of time and frustration for older versions of the Wiki.

Steps:

1) Download the ScrewTurn wiki source code

2) Compile it

3) Run it and once the site comes up, on the left nav, choose “Administration”

4) Log in. The default username for ScrewTurn Wiki Administrator is “admin”. The password is configured in the following key below in the web.config and is typically “password” out of the box:

<add key="MasterPassword" value="password"/>

5) Create a blank database in SQL Server (2005 or 2008, works in both)

6) Give adequate rights to that database (modify, etc.) to a user you specify in security for SQL Server for that database

7) in ScrewWiki Administration, click on the Providers tab. Select on one of the MSSQL providers and then click “Configure”

Paste in your connection string. This connection string must work and make sure it’s not malformed! Because once you put the connection string in then save, ScrewTurn Wiki does an automatic check for auth and it will fail if the connection string is malformed or the values are not correct, or the user you setup in SQL Server is not right or doesn’t have the appropriate security to the DB you created. If the connection string fails, you’ll get a strange generic message such as “The provider refused…blah blah blah”. If you get weird errors, check the log under the System Log tab.

8) Once you’re able to save your connection string without error, highlight the provider again and click the Enable button.

9) Repeat these steps for the other SQL provider.

10) Once you have both providers working with that connection string and enabled, check the database to ensure that the tables were created. By configuring and enabling the providers, ScrewTurn Wiki automatically creates the needed tables in your blank database:

11) Now you need to perform once more step. Change all the default providers to use the MSSQL providers instead of local in your Provider tab and click Save:

12) That’s it! Anytime you add data such as categories or content to ScrewWiki, it should show up in your SQL Tables, not the local file system.

Please digg, dzone, & kick if you found this post interesting or useful.

C# Regions are not Useful? Give me a Break

Dave Schinkel — Mon, 20 Apr 2009 03:05:51 GMT

Technorati Tags: C#,Standards,Opinion

I often see arguments about use of regions in C# code. And this is one of the most annoying things I see on the Internet in my opinion when it pertains to code structure.

Whoever says regions are not to be used, I’d love to see your code and know what standards you have established as a team with your code base. I bet you it’s a mess and the reason you don’t like regions is because the developers on your team has abused use of them and that there is no logical pattern or team standard established.

I’ve been on plenty of teams who have used regions effectively and at a top level grouping that made classes and finding things much faster overall. I definitely agree that unorganized use of regions and overuse should not be, but to say not to use regions at all is like saying put all of your damn html on one line and don’t indent…another thing I can’t read.

If you have a team who can’t use regions effectively it’s either because of one or more of these three issues:

They don’t care about team standards
There is no pattern in place and standard that expected of the team
There are no code reviews to help keep that standard and pattern in place

There is absolutely no excuse to say that regions are never helpful. It’s part of development, part your team standards/patterns people and then code reviews can help to reinforce it. It’s called caring about code structure which goes along with name spacing, file structure of you project, and pattern structure of your code. To single out regions is foolish and only means you can’t figure out a standard practice on your team and template to force and use that is top level..simple as this:

#region Methods
#region Properties
#region CRUDs

…whatever

Who wants to scroll down a class all the time when you can go to a region quickly to find what you want as a starting point. And your classes should never be very long (SOLID) but still, regions do help. If Code Generation did not use regions or non-generated code did not, can you imagine? Granted I am not using code generated code now but was and it was nice.

I always use regions and always will, they are not chaos in my application so they are extremely useful when not used like a code & run team who has no clue of standards or patterns. The argument not to use them should never come into play. If you see a bunch of regions and they are not named well, talk to the team and have a team meeting about it and come up with a template that works.

But never say they are ineffective and never to use them. Give me a break. You can say that about any aspect of code that is not organized and has no pattern or standard! Every developer is going to have to change code, and maybe regions will change but if used correctly not that often. That’s why it’s nice to use tools such as ReSharper to create and manage them as well. Having no regions with this type of “excuse” is just plain ignorance.

Piggyback on Derik Whittaker’s Post on Refactoring Project Structure

Dave Schinkel — Thu, 16 Apr 2009 04:23:38 GMT

Technorati Tags: Standards,Design Patterns

I agree 110% on my friend Derik Whittaker’s post about maintaining & refactoring project structure not just code structure and I’m sure many will agree but most do not put in to practice weekly on their teams.

Breaking your code into physical projects and solutions is a no brainer so I’m not going to ramble on about that.

I'm currently working on a new UI layer for our website in MVC and making a structure that is much more logical even down to the Images folder itself...why the heck not?

Example: Images\Site (means it is used site-wide), Images\Product , Images\[whatever other business function], etc. so that you don't have to jumble through a huge mess of pictures in one huge folder. Obviously I’m not going to create a folder with just one image in it but sure is much more clear when you separate into function. This is just one minor example out of many in the new structure.

One reason I like ASP.NET MVC also is because of physical folder structure out of the box with controllers and views. Logical folders for Views and controllers and you name each folder corresponding to function. It forces you to have a logical structure because the routing engine uses it and RESTful names help organization a lot as well. Excellent!

Controls also need to be more organized. Sounds simple but how much easier is it to see this physical folder structure as your application grows huge: Controls\User and Controls\Custom
rather than one folder Controls\(with a huge messy list of both in the root). You could even go a step further and include function which makes it even more clear:

(mini example here for folder structure with your controls)

Controls\User\Cart

Controls\User\Checkout

Controls\Custom\Cart

Controls\Custom\Checkout

Controls\Custom\[thridpartyname]

…etc. you get the point

Who cares if you can see the extension on your controls, that's not the point and no excuse not to organize them into well named folders. Point is I want to go from A to B quickly in a solution and without effort and find stuff quickly.

Having too many folders is bad, but lack of folders is also a bad thing. If you have a huge pile of files in some folder roots, you need to refactor and use more folders, projects, or solutions to organize your files to make things quickly discoverable. One thing I cannot stand is just a ton of .aspx files (even intermixed with too many other file types) in the root of a web project. Organize them into very basic clear logical folders! My eyes are getting blurry just looking at this list! I’ll soon need a pair of reading glasses after my eyes go bad! As far as folders, as long as you don't go lets say 5+ folders deep and they are very straight forward in their naming and very organized and generalized, I think you're just fine. If you're starting to get too many folders created (but you know it's making the project well organized and discoverable) then maybe it's time to move it into a new project and/or solution as part of your main application.

Structure of an application does not stop at code. Like Derik said basically is that it is an extension of your code and your patterns. Why? Here’s my own set of reasons:

1) Project file structure IS and at all times should be viewed as a form of pattern and directly relates to good process. I say process loosely as process relates to many aspects of development so having a project pattern is essential. Just as there are patterns in anything we do in development, code or otherwise, physical file structure should have a recognizable pattern.

2) It helps complement a manageable and sane build process..it's critical for managing, maintaining and pushing logical standardized builds across departments so that you structure is idiot proof clear.
3) It helps newbie's or even existing programmers find things quick. Makes your project discoverable immediately before even the code
4) overall maintenance is reduced
5) Having a good structure encourages and sets an example for other developers on your team to keep the goodness that's already there (because it is already easy to see what's going on) when extending it. It's called having team development standards and this just is one example of that! In fact, you can view structure of projects as a pattern. If it's clean and discoverable and logical, most likely other developers will follow that pattern and if they don’t then that’s what reiterating team standards is all about to them. However if it’s always a huge pile and it's just chaotic mess of folders and files, you would be certain to receive chaos back when it’s continually being extended by developers on the team. You find this in a lot of code & run shops because nobody cares to slow down and manage it properly. Developers who really care about team usability and WANT to refactor this can’t if nobody cares about structure. And that’s poor management of a team when you let your project structure grow to chaos.

You should name your projects, solutions, folders, etc. to be very understandable and familiar terminology. Don't use terms that only your mind can infer; use words that anyone can immediately infer no matter if they are an Architect lead, Jr. Developer, or mid-level. Obviously if you have frequent questions come up about “what does that mean” from other developers in terms of naming convention or structure, you may want to refactor and look at how to improve it or clean it up.

Your physical abstraction names should be very clear and familiar. If it's a Data Layer, state that in the name. In fact stop using the “DL” acronym as an example. If it's a Service later, etc. call it ServiceLayer…you get the point. I’m not saying you need huge long words, but use full words if you can. Being too short with names just so that everything looks so “compact” can be dangerous and can also product more code smell and waste time for developers trying to learn the application or just simply find stuff. Be careful of the total # acronyms you plan on using overall in your projects and how much you shortcut names. Not everyone infers the same or wants to dig to figure out what 100 acronyms mean after just opening a solution. Sure you argue “hey if you don’t know what the acronym is, just look at the files inside the folder” but that again is not the point here and drives directly against the whole point of project structure. I agree that there are going to be some acronyms that are business related but don’t abuse it just to be “sexy” with your application because everything looks so concise. It's just like variable & method names, keep them short but also keep them meaningful. Keep it sexy but there’s a fine line between “sexy” and “discoverable”.

Finally, code reviews should not only go over code but structure. Did a developer add a new folder(s), project(s), etc. this time? if yes, then talk about it if it does not seem logical to you or organized or too much. Don't immediately be a dictator though and say “move this and rename this” type type type and it’s done without them being able to discuss what they did with you. Maybe the developer had a good reason to do so. Talk about it and discuss as part of the code review which will help you maintain you project structure for the long haul. Hold team code review meetings and include talks about the team .NET file solution structure standards in addition to just patterns all the time.

Subtext Admin Password Does Not Work

Dave Schinkel — Mon, 13 Apr 2009 06:01:15 GMT

Technorati Tags: Subtext,Open Source

For some reason, some Subtext blogs may have an issue whereas no matter if you use the reset password or not, you can’t log back into your Admin interface. That is, the url http://www.yoursubtextblogdomain.com/admin.

I ended up having to actually update not the Subtext_Host table (as outlined here) but rather the Subtext_Config. What’s the difference? Well, the Subtext_Host holds auth information for signing into the Host Admin tool: http://www.yoursubtextblogdomain/hostadmin while the Subtext_Config table has config settings for your blog including username & password for your blog, or in other words, to log into http://www.yoursubtextblogdomain.com/admin

So to reset your password on an existing account manually if the reset password functionality is not working, just run this to set your password back to “password” on the Subtext_Config table (not Subtext_Host), then log into your blog admin and change it later again to a new password once you’re in:

UPDATE subtext_Config
SET Password='sIHb6F4ew//D1OfQInQAzQ=='
, Salt='SPYxRrEmM0CGLgjg0ikCgQ=='