C# Lambda Expressions

For quite a while now I have been wondering about lambda expressions. I've started seeing more and more of them in code examples, and there has obviously been a lot of talk about them. But most of the examples I've seen have not been very intuitive. I finally decided to see what they we're all about, and was surprised about how simple they are to understand. They are not really anything new, just a new shorthand for doing things that C# could already do.

I started my journey be reading chapter 11 of Pro C# 2010 and the .NET 4 Platform (As a side note I've read a number of the other chapters, and it looks like a decent book so far.) I thought it was interesting that lambda expressions we're grouped in the same chapter as delegates and events, but after reading the chapter, it all makes sense now. This is probably oversimplifying it, but lambda expressions are just "syntactic sugar" for creating anonymous functions, and working with delegates. They allow a developer to easily write a basic inline function for event handlers or anywhere else a delegate is needed.

The basic format for lambda expressions is arguments => statement. The expressions can have 0 or more arguments and 1or more statements. The most common case I've seen is probably one argument and one statement, and the nice thing about a single statement is that the result of the statement is the "return" value of the expression. One of the other great things about lambda expressions is that in most cases the parameters can be implicitly typed, so that can mean a few less characters to type, and simpler, easier to understand expressions.

I still don't know how often I will use them, but it is nice to know how simple they are and how easily I can define event handlers now. What would have taken a significant amount of boiler plate code and definitions and a function, can now be done in a single, quick line of code.

The Future of Computers

Over the last few years it has been exiting to see how computers have changed, and how they have changed the world. Mobile devices have become ubiquitous, almost every new computer has 2-4 cores, and software drives business throughout the world. How will things change over the next few years?

Computers will get faster
As we have started to see over the last little while, computers have started plateauing on overall speed and raw MHz. Instead computers have started getting multiple cores. I think this trend will continue, we will see 4 cores become standard and 8 eight cores become common.

Mobile devices will rule the world
Already many people are using mobile devices, but with smart phones becoming more popular and more functional, we will the web become even more important, and also more critical that it supports devices with smaller screens and different input methods like touch screens

Software Engineers will continue to be needed
Since software is already critical to the world, businesses will continue to need to buy software and hire programmers. This is good news for those of us that are in the industry, and even better news for those that are just getting started.

The future of computers looks pretty exciting. We will continue to see new technologies, and we will continue to see increases in speed. the only thing that is for certain, it that things will continue to change...

Web Development with JavaScript and AJAX

It seems like JavaScript and AJAX are becoming more and more necessary to create professional, interactive web sites. Basic HTML and even CSS just won't cut it. People expect the "bling" that JavaScript provides. I have mixed emotions about JavaScript though. It can really make a website stand out, but compared to traditional languages and development environments, it can be a pain to develop, debug, and maintain.

Part of me would say that Silverlight or Adobe Flex provides a easier environment to develop in, but they can be very heavyweight for most web sites. Maybe I just haven't found the right JavaScript framework or toolkit that really works well and makes sense. It seems like jQuery and the Google Web Toolkit are two of the most common and well known systems. jQuery seems a little more flexible, and the Google approach seems to be very tightly coupled with Java. Since I do most of my development with C# and ASP .NET, jQuery looks like a more promising solution.

Training Software Engineers

As I mentioned in my last post about hiring software engineers, I generally categorize software developers as either programmers or software engineers. Programmers have the basic skills to get the job done, but software engineers truly understand and apply all of the techniques and ideas that come with their craft.

Given the fact that no one is a perfect software engineer; how can we help train and educate team members to reach their full potential? Here are some of the techniques that I have used, but I would love to see what successes others have had as well.

1) PowerPoint Presentation Training

This is probably one of the most straightforward techniques, but one that I have the most mixed feelings about. I believe that this type of training is necessary and important. It can be very useful to get a group of people together to review, learn, and/or discuss something. But I also think that it can have the least overall impact of the different training ideas I have used. People tend to not participate much, so the presentation is very one sided, which means it's hard for attendees to focus.

2) One-on-one training

Sitting down with someone to review something specific, or explain something can be very powerful. Since the target audience is one, it is much easier to tailor the training to the individual, and they are much more likely to provide feedback and ask questions than in a group setting. This can happen formally as code reviews, targeted training, etc., or even informally as a brief discussion based on a question or comment. Sometimes I think the informal training, even though it is generally spontaneous, can be more effective than any preplanned training. With one-on-one interaction I find that the effect can be more dramatic than in group settings.

3) Training by Example

Another approach I use is to show developers good examples of how to be a software engineer. This can be including people in design discussions, reviewing "good" code, or asking them questions to help you work through a problem. This approach also works well, and is probably the least obvious form of training from the trainees standpoint. They may never know that they were being "trained."

Overall it seems to be one of the most difficult and important parts of my job: helping people reach their potential. It's a slow and time consuming process, but it can also be very rewarding for everyone involved.

Does anyone have any other techniques they use, or more ideas on how to improve or refine the ideas I already have? Also has anyone read any good books (or other resources) about how to manage software developers? I'm always looking for new ideas.

Hiring Software Engineers

We recently went through a round of interviews for software developers where I work. Ever since then I've been reflecting on how to hire software developers. I wanted to outline some of the ideas that I have, and see if anyone has any feedback or other ideas.

1) Where to post job openings?

We have tried a number of different free and paid sites for job postings (state job sites, dice, careerbuilder, etc) , and most of them seem to be pretty hit or miss. We get a fair number of completely unqualified candidates, and only a few that are even worth interviewing. Does anyone have any other suggestions or ideas of where to find candidates? One of our most useful resources has been the local university, but that only works when we are looking for interns or recent graduates.

2) How to filter through resumes?

Many of the resumes we get are for individuals that aren't even experienced or trained in software engineering (Do people not ready job postings?). But after the first pass, here are some of the things I generally look for, other than some of the obvious ones:

• Is the resume just full of keywords, instead of really focusing on skills that the individual has?
• What variety of projects have been worked in recent years (Web, back-office, database, etc)?
• How long does the candidate stay at jobs - are they a job hopper?
• Is the resume well organized and clear - or does it look like a computer generated it?

These kinds of questions help me to see the potential that someone might have as a good employee. What over ideas do people have for sifting through resumes?

3) How to interviewing candidates?

I wrote about a year ago on Job Interviews. I wanted to touch briefly again on some of the techniques that I use, and some of the areas that I continue to work on. Here are the key things that I want to get out of the interview:

• Do they have a solid understanding of software engineering?
• Can they communicate well with others (even non engineers)?
• Can they analyze information and problems?
• Do they fit with the culture and environment of the company and the team?
• Are they dedicated and a hard worker?
• Can they lead a team and mentor other developers?

I find that I can get a pretty good feel formany of these within 45 minutes or so, by covering 5-6 software design concepts, a story problem or two, and a little pseudo code. One of the items that I continue to think about and refine is how to make sure they have a solid grasp of software engineering.

With interns and candidates with little or no experience, I find that it is generally not too hard. Developers with 5+ years of experience seem to be much more difficult to interview. Most of this comes down to my belief that there is a significant difference between a programmer and a software engineer. A good programmer can be given a small to medium sized task, and can be expected to complete it in timely fashion, meet the requirements, and the end result will be decent code. The programmer focuses on getting the job done. A software engineer will do all of the same things, while at the same time taking into account overall business strategy and goals, code maintainability, design opportunities like refactoring, and many other things.

Trying to determine who has the experience, knowledge, and skills to really be a software engineer instead of just a programmer is no simple task. Given a finite amount of interview time, what things can you look for or ask about that can really help determine which category someone will fall into?