Thursday, May 31, 2012

How is a senior developer different from a junior developer?

There is not one right answer. It’s easy to say “a senior dev knows more and does more”, but I think there’s an additional dimension – a junior dev is merely expected to code to the spec, whereas a senior dev fundamentally takes responsibility and ownership for improving everything they encounter.
Here’s a braindump; obviously my opinion. Not a complete list, and not a one-size fits all. I was light on the exact technical requirements (as that changes), and focused more on the concepts. Perhaps in another blog post I’ll do a braindump of what a senior dev is not  (i.e. how is a senior dev different than a tech lead or architect). I’m using C# and .Net as an example, but you could easily substitute those.
There’s also an interesting matrix here.
Writes good code that just works
·         Be able to code to specification is assumed. Should be able to leverage experience and past domain knowledge to fill in some gaps in a spec. Does not need everything explained in complete detail.
·         Writes working code that handles non-happy path and has low bug count. Can quickly create code – does not need to continually refer to reference documentation.
·         Codes for non-functional requirements, like performance, maintenance, testability, security, etc…
·         Can write code with the minimal length and complexity.
·         Thoroughly unit tests applicable code.
Respected by peers
·         Has written a module or tool directly used by others on the team. A senior dev does not just write code in their corner.
·         Can review other’s code and suggest improvements that others will actually implement.
·         Other developers ask for your technical opinion
·         Has built end-to-end products, through all tiers, that ran in production for multiple  releases
·         Has written 10,000+ lines of C# code that passed code review
·         Has created at least 4 different Visual Studio project types (WinForm, web, WinService, Console, etc…)
·         Has created developer tools and utilities besides just visual studio. I.e. has used a profiler or visual studio plug-in or code analyzer or code generator.
·         Has troubleshot a production security or performance error.
·         Has written multi-threaded backend code
·         Has at least 1 technical niche of expertise
Takes Responsibility
·         Does actions to make other developers better, such as writes reusable code, mentors, solves critical path problems, automates a previously manual task, etc...
·         No longer just focused on development, but helps improve the process of development.
·         Can refactor legacy code without a formal project
·         Can resolve unanticipated coding or validation problems without pulling in a more senior resource
·         Can pick up new technologies without formal training (may need formal training for an entirely new platform)
·         Continually looks for code reuse and ways to decrease technical debt.
·         Can tell management what the developer needs in order to be more productive
Has platform-specific knowledge
·         This is the standard list you’d see on a job description (“Knows threading, diagnostics, reflection, IO, etc…, Can explain 5 design patterns, etc…)

Wednesday, May 30, 2012

Free WMI Code Creator - WMICodeCreator.exe

I’ve tinkered with WMI in the past, usually to find some IIS, network, or process information on remote machines where there wasn’t a readily-available API. I realize as the world of .Net APIs expand, the need for WMI shrinks, but it’s still an underlying technology that lets you do “magic” when there appears to be no other way.
However, the problem I’ve often had with WMI is finding the exact query to run. To my knowledge, it didn’t have intellisence, and I never clicked with the reference manual. I recently found a tool that makes it easy to generate WMI snippets – the free WMI Code Creator v1.0. Yes, this tool is from 2005, yes that means I am absolutely no WMI guru, but I still wanted to pass it along.
The tool provides a GUI to select the various namespaces and classes from which to construct your WMI query, and then lets you select the properties (“columns”) to return.  Then, it lets you execute the code on the fly. The tool just worked. Here’s a snippet of what it returns for querying process information.

using System;
using System.Management;
       ManagementObjectSearcher searcher =
               new ManagementObjectSearcher("root\\CIMV2",
               "SELECT * FROM Win32_Processor");

       foreach (ManagementObject queryObj in searcher.Get())
              Console.WriteLine("Win32_Processor instance");
              Console.WriteLine("Family: {0}", queryObj["Family"]);
              Console.WriteLine("ProcessorId: {0}", queryObj["ProcessorId"]);
              Console.WriteLine("ProcessorType: {0}", queryObj["ProcessorType"]);
catch (ManagementException e)
       MessageBox.Show("An error occurred while querying for WMI data: " + e.Message);

Wednesday, May 23, 2012

Chicago Code Camp 2012

This Saturday, we had another successful Chicago Code Camp at the CLC campus. About 400 signed up, and we estimate about 180-200 showed up based on sign-in logs. It was a "free" event thanks to our dozen sponsors and 30+ speakers. The courtyard was filled with impromptu developer discussions. Our morning registration and lunch lines flew  with almost no wait time. All around it was a wonderful event. I'm always honored to be a part of such an event.