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.

Wikis and web content management

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

Wikis are an interesting concept; a wiki is a website that lets users directly edit the content using a simple syntax. Wikipedia is perhaps the most famous, and biggest, wiki around. By letting anyone edit any page, this allows a lot of community feedback. It removes much of the red tape and bottlenecks that slow down other collaborative sites. Of course there are problems – such as vandalism (a malicious user ruins a page), but there are ways around this, such as reverting the page to the previous revision, or giving only certain users access to certain “controversial” pages.

Several developers have made FlexWiki, open-source, ASP.Net-based Wiki. It’s quick to set up, and built in .Net so it’s easy to modify or improve.

An interesting paper explaining the technical issues of Wikis is Mattias Beermann’s Collaborative web content management – Wiki and beyond.
 

Paylocity in Chicago is hiring for a Software Engineer

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

If there's any sharp Software Engineers in the Chicago, IL area looking for a new job, my company, Paylocity (www.paylocity.com) is hiring. I've been at several good companies, and this is by far the best Software Development place I've personally seen. We're developing a .Net application for Payroll. Here are some of the perks:

• Great Learning Opportunities: Working with cutting-edge .Net development (migrated to .Net 2.0 in November, 2005)
• Work-Life Balance: Local software department - no travel. Dress code is casual. Office hours 8-5. We have laptops and can do extra work at home.
• Working from home Tuesdays and Fridays.
• Job Security: Smaller company (100 people total, 20 in software department), so we're too small to be outsourced, and privately owned (and owner refuses to sell), so we won't be sold.
• Company has been profitable and grown every year (for all 8 years) - even during the IT crash we still grew.
• Stable Group: 0% involuntary turn-over. Maybe 1 person voluntarily leaves each year.
• Interesting work: There are separate IT and Internal development departments. Even within our department there are separate QA and Busines Analyst teams. Therefore you can focus on development.
• Great, collaborative team. Average person has maybe 8 - 10 years experience. Team is large enough that you can specialize in areas that interest you (UI, Business Tier, Database, etc...), yet small enough to still get an interesting variety.

You can see an official description here.

If you're interested, just contact me at tims@paylocity.com.

Web Accessibility Toolbar

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

A coworker of mine suggest this tool to test web page accessibility, looks good:

http://www.visionaustralia.org.au/ais/toolbar/