Friday, March 15, 2013

A Couple Recent Articles

Yep, it's been ages. On the off chance anyone's actually reading this, I recently wrote two Code Project articles.

1. Unobtrusive AJAX Form Validation. A basic guide to walk you through some surprisingly poorly documented functionality.

2. Dynamic Querying with LINQ-to-EF and Expressions. A kung-fu level data access approach that could be used to provide data from a service to a searchable/sortable grid.


Wednesday, August 3, 2011

Becoming a Better Software Developer

I've been asked a number of times how to improve the quality of the software developers on my teams.  It's an interesting thing to think about.  How did I get good (assuming, of course, you think I'm good)?  What do I recognize in others that makes them better or worse?  Are good developers' qualities intrinsic or learned?  It's naive to think that simply knowing more C# or WCF makes you a better developer.  Surely pure knowledge is critical, but knowledge alone does not make a good developer.  


For example, I worked with a guy who seemed to know all the compiler switches by heart.  I was stunned and assumed this guy must be a rock star.  However, it turned out he couldn't get any work done and was an anchor to the team instead of an engine.  Joel Spolsky also summed it up well: "Smart and gets things done".  This guy had only the first half.  As another example, I've worked with people who were experts in their subject area, but simply could not take a step back, reframe the problem, or look at the big picture.  Here, I think Einstein said it well: "The gift of fantasy has meant more to me than my talent for absorbing positive knowledge."  


So following are my [unscientific and opinionated] thoughts and extensions on these premises about what it takes to become a good developer.


Analytic
I think being analytic is core.  When you get down to it, the process of developing business software is essentially taking the chaos of human beings' work and turning it into logical code that automates that work.  There's no way to do this other than through decompositional analysis of large problems into smaller problems and into yet smaller problems that can be logically handled in code statements.  It was an clever analyst who quipped, "How do you eat an elephant?  One bite at a time."  A developer's job is determining a good first bite, and second bite, and so on until the elephant is eaten.


But the analytic quality doesn't end with being able to decompose business problems.  A good developer must be able to make good analytic decisions, evaluating the pros and cons of different options.  If one line of reasoning leads to a certain dead-end, it's foolish to keep trying that approach.  But it's equally foolish to prematurely determine the situation is a dead-end.  What if the developer's knowledge had simply been maxed out, and there was actually an approach the developer didn't know?  Knowing when to move on, when to ask for help, when to keep digging - these are more intuitive facets of analysis that are equally important.


Creative
Some people who don't know anything about software engineering, who view it as some form of technical wizardry, often think it must be dry stuff.  Programmers simply fill their heads with bits and bytes and gotos and gosubs, and through proper application of magic/engineering, produce software.  I have to break it to these people, creativity is essential to being a good developer.  Without creativity, a developer is locked into rigid, narrow thinking.  On a recent project, I saw a legacy database where I could just imagine the conversation that occurred prior to implementation.  Lead Developer said to someone, "Set up the new tables with a unique ID."  The outcome?  Each new table has a column named "uniqueid."  Ugh.  (And for the morbidly curious, no, primary key constraints were not in place.)


The creative mind nimbly and constantly changes focus from the details to the generalities, to the future and back to the present, from fantasy to reality.  It asks "why?" a lot.  It considers the business implication of a technical decision and the technical implication of a business decision.  It is not constrained by precedent or mandates and thirsts for inventing new and better ways of doing things.  As much as analysis, creation is foundation of the development process, and the stronger these skills are, generally, the better the developer.


Honest
I think honesty is a big deal.  More than anything, good developers must be honest with themselves, and then in turn be honest with their colleagues.  I think the first and essential thing to admit is you can't know everything.  If you think you do know everything, or that you "should," you're not being honest.  As technology advances, it's non-linearly harder to keep up with it.  You are one person, and the whole of technology is driven by a growing global brain trust.  Keeping pace is a more intractable challenge every morning.  Admit to yourself what you do and don't know, and honestly commit to learning something new from time to time.  You can expect no more.


The other aspect of honesty to me is summed up as "Don't talk s***."  I've met more folks than I can count in this field who (because I think they're not honest with themselves) refuse to say "I don't know" in response to a question.  I've never understood this, and I guess it's some form of machismo.  Some of these s***-talkers are really good at it, i.e. they are assertive and convincing, and it takes a while to learn that what they just spewed was just that: spew.  My advice to them is to learn "I don't know."  Say it a lot, because there is a lot you don't know.  If nothing else, consider the damage done to the business because you wouldn't admit ignorance, yet you asserted something anyway, and people wasted time doing the wrong thing.  If you're in a situation, say in front of a client, where "I don't know" is a politically poor response, try "let me get back to you on that."


Disciplined
I've heard "developer discipline" called an oxymoron.  Sadly, I think this may be true in general.  There's something about the left-brainedness of the analytic and the right-brainedness of the creative that tends to lead to scruffy-brainedness, which is to say, undisciplined.  Not all is lost though: discipline can be learned.  I'm a bit lucky in that my college education was in English, and across the board, my professors were sticklers.  One-inch margins, double-spaced, MLA-formatted, no spelling or grammatical errors.  I learned discipline in writing because it was required to get As.


Professionally, I have habits, maybe even reflexes or twitches.  These are intentional habits, such as formatting code (Ctrl-K, Ctrl-D *twitch*), consistent naming, letting people know about breaking-changes, asking/understanding before coding.  I find that creating habits helps me be disciplined, since I'm prone to forgetting to be disciplined.  Some discipline can be aided by tools (I'm looking at you, ReSharper), but some require a change in habit.  I've heard various numbers on how long it takes to form a habit, somewhere between 10-30 regular repetitions.  That's not really a lot of effort to move a good behavior from conscious to unconscious.


Inquisitive
Good developers ask a lot of questions.  When they don't know, they ask "how can I find out?"  When someone gives them vague requirements, they ask a barrage of follow-ups until the requirements are clear in their minds.  Conversely, a weak developer takes vague requirements and writes vague code, code that's a partial solution or that's buggy, ignorant of a whole array of use cases.  It's important the questions asked are on target, so I'm assuming the developer is a good listener and capable analyst.  If those are in place, there's no such thing as a bad question.  In fact, I find most SMEs love (and I mean love) to talk about their subject of expertise.  If you're getting it, they'll keep talking and thank you for the result.


Inquisitiveness also leads to research and play.  Someone gave me the words "recreational programming" many years ago, which I thought was great.  I wrote code in my free time (utility apps and games) because I loved writing code, and suddenly I had professional-sounding words for it.  I always want to find out more.  I got the beta-bits of .NET in 2000 and started messing with .NET Terrarium.  I wrapped some System.Net classes into simplified packet-handlers for a business idea I had that required networking.  I wrote a Mancala-playing program to explore AI and GDI+.  Inquisitive people love to learn.


Developer Psychology
So what I've set forth is a brief essay on developer psychology.  Entirely my own opinion, but based on a number of years of professional development and a decent breadth of experience.  I think most of the good qualities I described above are able to be learned, though if you happen to have them natively, you're better off.  Creativity, especially, seems hard to learn, though I don't see why a determined person couldn't set some creative exercises for themselves.  The Dr. Ecco series is full of fun programming problems to stretch your brain.  Discipline seems a close second on difficulty, but without it, you'll never be more than a hack, so start training up some habits.


If ever a college motto applied to what I think makes strong developers, it was my alma mater: non satis scire.

Wednesday, July 27, 2011

Day 0

Figured I'd begin my first blog at the beginning...  


Back in 1972, I came kicking and screaming into the world.  I remember the look of horror on the doctor's face...


OK, not that beginning.  How about circa 1997 when I had just hung up a illustrious|terrifying career as a high school English teacher.  I was going to be all Dangerous Minds and get those unruly kidz to learn them some good English.  But then I came to my senses and packed it in.  Fortunately for me, I was working with the uber-geek Kyle who suggested I check out this Perl script he'd been writing.  Before then, I'd always been a closet geek at best.  I had associated computer expertise with pocket protectors, punch cards and a gut that hung over the belt.  I had quietly "programmed" (I put this in quotes, because c'mon, I was 14) in BASIC at the public library on an Apple 2e in the 80's and always seemed to know how to fix my own computer problems, and then in college you'd hear me say I had "computer-phobia", while I actually built my own PCs from parts.  I would never admit to my love of the machine.  But Kyle had none of the attributes I feared must come of a career in computers.  He was blonde, funny and ridiculously smart.  And he also made more money then than I would likely make until 20 years of teaching.  "Maybe I should reconsider my stance on computers," said I.  I bought the "Camel Book", which by the way, I absolutely do not recommend as a first programming book (maybe as the second, better the third), installed Perl, and started reading and hacking.


So on I went to establish a career!  Basically, I read volumes and always found excuses to automate whatever boring work there was at hand, slowly proving myself as a programmer professionally.  And if ever there was a "recreational programmer", it was me.  Man, did I write some good shelfware at home.  But man, did I learn!  Those early apps I wrote that actually saw the light of day were horrible: epic subroutines, copy-paste inheritance, abbreviated names, all the worst-practices you would imagine.  But as I worked and read and coded and experimented and learned from and talked to other programmers, I discovered faster, smarter, better ways of making computers dance.


This blog aims to capture some of my experience.  Various "tips and tricks" I've learned.  Perhaps a slick solution to a recent problem.  Or maybe a nasty workaround.  The importance of discipline and humility.  Some business knowledge or insight.  And hopefully some moderately amusing writing.


Until next time...