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/

 

Continually learning better coding methods

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

Coding requires constant learning. Here are some ideas to help with that:

1 - Be prepared to spend not just time, but mental energy.

2 - Find ways to get input:

• Other Opinions:
  • Code Reviews - both having people look at your code, and looking at other's code.
  • Read blogs
  • Read articles
  • Read the documentation. If you're using a collection, read the documentation to see how it suggests enumerating through or referencing it's items.
• Experiment on your own code
• Reflect back on your code
• Ask yourself, "does this make sense?". If your own code doesn't make sense to you, it probably won't make sense to others.
• Make sure that you're not re-inventing the wheel. Look for resuable components.

3 - Make the intent of your code clear so that others can help. If Bob doesn't know what you're trying to do, Bob can't easily help you.

• Use smaller methods
• Add helpful comments that explain intent, not just repeat the steps that the code is doing
• Abstract out context and dependencies such that it's easier for people to understand what you really want.

There's obviously a lot more to say on this, I'll make some follow-up posts.

How to send the Console output to a string

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

Sometimes when writing a tool or automated process, you want to read in the console output and send it to a string. From there, you can do whatever you want to it, such as parse for info. For example, a third-party tool (not necessarily even built with .Net) may display result information to the console, and you may want that info as part of some bigger process. The classes to do this reside in System.Diagnostics.

    public static string GetConsoleOutput(string strFileName, string strArguments)
    {

      ProcessStartInfo psi = new ProcessStartInfo();
      StringBuilder sb = new StringBuilder();
      try
      {
        psi.WindowStyle = ProcessWindowStyle.Hidden;
        //Need to include this for Executable version (appears not to be needed if UseShellExecute=true)
        psi.CreateNoWindow = true;   
        psi.FileName = strFileName;
        psi.Arguments = strArguments;
        psi.UseShellExecute = false;
        psi.RedirectStandardOutput = true;
        psi.RedirectStandardError = true;

        Process p = Process.Start(psi);

        sb.Append(p.StandardOutput.ReadToEnd());
        sb.Append(p.StandardError.ReadToEnd());

        p.WaitForExit();

      }
      catch (Exception ex)
      {
        sb.Append("\r\nPROCESS_ERROR:" + ex.ToString()); ;
      }
      return sb.ToString();

    }

USNAF - Microsoft's National Architect Forum

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

I just got back from Microsoft's National Architect Forum in Vail, Colorado - and wow! To be at a conference with 200 top architects was humbling. There are several big things I saw:

1. Microsoft is really maturing on Enterprise Architecture and agile processes.
2. Paul Glen spoke (author of the great book Leading Geeks). A lot of good insight about how to manage geeks.
3. There's a lot of good architects out there.

Perhaps the easiest thing to describe was Paul's closing speech. He had several good points from his book:

• Geeks are different than other people because their productivity is based on thinking not behavior.
• Power is useless with geeks because power only controls behavior, but Geeks deliver productivity via thought.
• "Geekwork" is different than normal work. For example, in geekwork because technology moves so fast, the moment you step away from implementing code to become a manager, technology moves on. Therefore managers often know less about direct coding than the geeks they manage. In most other fields, managers know more than the people they manage.