Strings in .Net 2.0

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/strings_in_net_20.htm]

Jeff Atwood at Coding Horror summarizes a lot of interesting points about strings. I especially like the new .Net 2.0 "String.IsNullOrEmpty" method.

A junior dev code-reviewing a senior dev

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/a_junior_dev_codereviewing_a_senior_dev.htm]

We all know that Code Reviews are a good thing, especially for a senior dev to review a junior dev's code. But it is also beneficial to have the junior developer code-review the senior dev's work:

• The junior dev see what good code looks like
• The junior dev may still catch something - even senior devs make mistakes.
• It sets a good role model - if even senior devs are having people review their code, then certainly junior devs should be too.
• It offers humility to the senior dev - If you only review other people's code, and no one ever reviews yours, it becomes one-sided, and is easy to get into an ivory-tower mentality of only criticizing other code without accepting criticism of your own.
• It prepares the junior dev to possible take over easier parts of the senior dev's code, freeing up the senior dev for other important tasks.

Certification: Pro vs. Con.

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/certification_pro_vs_con.htm]

In the consulting world, I saw a constant pressure for devs to get Microsoft Certification. This has benefits:

• A certification implies at least minimal knowledge, commitment to the technology, and initiative to take some tedious exam.
• They're great for younger developers trying to get their foot into the door, or consultants who want to bolster a resume.
• They're good to ensure at least a general, broad knowledge
• They tell you what Microsoft and the Industry thinks is important to know.
• They're good when competing with another candidate for a job, to match their credentials. I.e. if they have certification but you don't, then it's an edge. But if you also have certifications, then it nullifies that advantage.

Many managers would point out that a certification is better than nothing, and distinguishes you from your peers. While this has some merit, I think certifications (at least the MS ones) can be overrated. Speaking as someone who has several MS certifications, I think that they have several limits:

Tests only broad and shallow knowledge, not the ability to think: A MS certification essentially requires broad, but shallow, knowledge in an area. That is important, but it has many limits. Developers need the ability to think and solve very complicated problems. Certifications don't really test in-depth problem solving.

There are other good things: Sure, a certification is better than nothing, but most developers aren't doing nothing - they're doing other constructive things:

• Reading up on other technologies
• Practicing technologies that are too complicated to have certifications for.
• Open source projects
• Extra features at work
• Their own personal pet projects
• Writing articles
• Mentoring other junior devs

These activities all can help make someone a better developer.

They can be cheated: Somewhere out there, there's got to be a black market for exam answers. Microsoft recognizes this is a problem, and wants to enforce exam security and integrity. Of course, the exams are straight-forward enough that if you need to cheat on them, you have bigger problems.

At Paylocity, any developer we hire needs to write code on a whiteboard. This quickly lets us see more of someone's thought process than a multi-choice certification exam. Certifications are good, and of course they have benefits, but they're not a silver bullet for everything.

Ideas to be a better developer

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/ideas_to_be_a_better_developer.htm]

Here are some practical ideas to become a better developer. Of course people write entire books on this stuff, but here’s a brain-storming list (and that’s what blogs are for =)

1. Budget your job on an eight-hour day. Deliberately planning for a 12 hour day will just spin you into a downward spiral by burning you out, preventing you from learning new things, and constantly make you feel behind. Ideally try spending any overtime doing optional exciting learning or experiments that energize you (or improving code that already functionally works), not required features that just burn you out. If a feature does take longer, make sure management knows that, i.e.: “This is a 5 day feature, but I’ll work overtime to do it in 3 days.”

2. Get a blog aggregator, such as SharpReader or RssBandit: http://sourceforge.net/projects/rssbandit/. Then spend at least 10-20 minutes a day reading blogs.  This will give you a pulse on the community, alert you to new techniques, and introduce new creative solutions.

3. Keep a kudos list of positive things you’ve done. This helps build confidence (“I have done positive things”). This prepares you for a review. This is a service to management because it helps “jog their memory”, and management already has enough stuff to remember. If you can’t remember the good things you’ve done, why will anyone else?

4. Do incremental checkins, especially when working on a critical path. This results in much lower stress. Two small changes are easier to integrate than one big one. Check in what is needed to make sure you’re not blocking anyone, especially if you’re on the critical path. Ideally try to check in at least once every other day.

5. Think beyond your current feature. With each feature, try to make at least one reusable component/utility that improves the project as a whole. For example: reusable logic for the application’s framework, a global UI component, refactor an existing component to make it better, or make reusable validation/formatting logic. This will give you stepping-stones (and positive reputation) to do bigger experimental components.
 

What to do while waiting for a batch process

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_to_do_while_waiting_for_a_batch_process.htm]

Sometimes you'll have local batch processes that block you from development while running. For example, you may have a 20-minute checkout script, a set of longer tests, or a long-running analysis tool. While such tools have benefits, developers are reluctant to use them because they don't want to be blocked from developing. However, there are many constructive tasks you can do while a process is running:

• If you can choose when to run the process, then kick it off right before you leave your machine:
  • Lunch
  • Meetings
  • Breaks
  • Any legitimate reason for being away from your desk.
• If the process must be run at a certain time, then you can still do constructive activities while it is processing, like:
  • Design out the next task (read the spec, think out the code, etc...)
  • Catch up on technical, work-related, blogs. You're still using your computer, but the bandwidth is minimal for this kind of reading.
• Of course, you can always kick off the batch off the clock when you're away from your machine, such as before dinner or even overnight.

The idea is to multitask - the batch process runs in the background (doing useful things that benefit you), and you're still actively thinking in the foreground. It's the best of both worlds.

SQL Server 2005 has try-catch

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/sql_server_2005_has_trycatch.htm]

I used to do error checking in SQL Server by adding a check after each statement, something like this:

 if @@error != 0
    begin
    RAISERROR 50001 'Some error message'
    RETURN
end

This has obvious problems (lots of extra code, what if you miss an error message, etc...). However, SQL Server 2005 has try-catch statements!

BEGIN TRY
{ sql_statement | statement_block }
END TRY
BEGIN CATCH
{ sql_statement | statement_block }
END CATCH
[ ; ]

This is definitely a convenient thing.

Technical Confidence

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/technical_confidence.htm]

I was talking to a friend about confidence with technical skills. Here's a brain dump of my thoughts:

Technical skills are good, but when working with people we need people-skills too, like confidence and leadership.

Knowledge + Experience will drive up confidence

Some people view confidence as a Darwinist "survival-of-the-fittest, no-one pushes me around", self-empowering ordeal. I think that's crap. Rather, I view confidence as a service to your coworkers - by being confident (and having the track-record to back it up), you can give you coworkers peace-of-mind as they know that you will solve the problem, and they don't need to worry about it.

What confidence is:

• Knowing what you know and acting it out
• Giving people the peace of mind that the buck stops with you. You can be confident even if you don't currently know the answer IF you know that you can figure out the answer, and no one else has to worry about it.

Confidence Is not:

• Arrogance
• Never admitting you're wrong
• Bluffing people

Ideas to practice confidence:

• Work on extracurricular projects that you care about. This gives you both experience and knowledge in a potentially new area. If you only do what is required at work, you'll be funneled into a very narrow skillset.
• List to yourself the reasons you should be confident in something, like (1) I know the material, (2) I've done this before, (3) I've run this idea past others
• During dead times (waiting in line, driving, walking) practice interview yourself. As yourself "what are ways to make a WebForm perform faster, how could I solve this testing problem, why is a DataReader better in this case than a DataTable, etc..."
• Teach & Publish - teaching others will make you more confident.
  • Writing your own blog
  • Writing online articles (anyone can submit articles to www.CodeProject.com)
  • Teaching a class, or just volunteering to provide free mentoring at a local college
  • Submit a component to the open-source community
• Look at leaders in the field and see what they're doing. For example, read MVP Scott Mitchell's online resume. Wow.
• Get connected with the community. This lets you know of new concepts and trends in your industry
  • Read other developer's blogs
  • Check out forums to see what common questions there are
  • Visit a user group
  • Try to attend a trade show, focus on meeting at least 1 speaker.
  • See the latest books out in the bookstore.
• When talking, give a direct answer, avoid space-filling "Um", "well", "maybe", "Perhaps", "I'm not sure of this, but...". Uncertainty is okay (it's actually inevitable given how much stuff is out there), but always follow it up with a certain action plan. Compare these two answers to the question "Can C# handle operation overloading?":
  • "Um, I think so, I heard of that happening somewhere, but I don't know"
  • "I'm pretty sure, but I will quickly verify that in the C# specification".
• When asked an interview question, don't just reply with "yes" or "no", but expand. This (1) demonstrates that you're pro-active, (2) keeps the ball in your court (you get to talk about what you know, instead of them following up asking questions you might not know), (3) gives you the chance to tie in other knowledge. Which of these sounds more confident to the question "Do you have experience with C#":
  • Yes.
  • Yes. I have three years of C# experience. I know C# very well.
  • Of course. Over the last three years I've built many applications with it. I especially like how it's type-safe, especially with delegates. Most of my blog entries use C# code samples because it's such a clean language.