Agreed, we make it a requirement in our shop that each person pick a topic of their choice that they are unfamiliar with, potentially not useful to the company directly i.e. Ruby etc. which would would likely not adopt. Each day they spend 30-60 minutes to learn the material. At the end of the week each team gets together to teach and reflect on what they have learned and did / didn't like. When we first started doing this you could see the resistance, however, after a few weeks you can see that they are enjoying it. This has improved our process significantly over the time we started doing this.

One example:

One of our developers started reading about haml because of our recent switch to ASP.NET MVC and the availability of the nhaml view engine. When he started to explain what it was, another developer was quick to say, why would we ever do that, what's wrong with brackets. I was quick to point out that was exactly the mentality we were trying to avoid, and that we should always be open to new ideas, not necessarily jumping to incorporate them, but at least open to the idea. The following week he chose to spend his time learning haml as well, and even liked it.

With regard to patterns and OOP fundamentals:

In the process of switching to MVC from MVP, I think at least for us the pattern understanding began to make a whole lot more sense. MVP always seemed like webforms, but unit-testable. MVC and dependency injection lend itself to better patterns IMHO. Code camp server as a running example for MVC is filled with all kinds of useful patterns that we have picked up pretty quickly.

Agreed, what you find are deadlines and a lack of management understanding that force internal groups to program software in the organizationally acceptable way.

Pingback from  Business » I might be an elitist, but you’re a misanthrope

Very well put! This is exactly what I was arguing about for this post (intofactories.net/.../the-role-of-team-system-in-a-software-factory -> also read the comments): "don't flip the bozo bit".

Who you calling an alpha geek?!

From my perspective it's not that developers are worried they won't be able to follow your genius but that you don't represent their needs. The vast majority of developers are required to solve complex problems within ridiculously short time constraints, with poorly defined requirements and with clients who don't understand the relevance of agility or it's offshoots. Learning about the intricacies of mocking, dependency injection and the like are so far from the immediate pain points of these guys/gals that they remain academically fascinating yet  don't address the real challenges of development.

I see the ALT.NET movement and thought leaders in general is incredibly important in the industry. They are the way of the future - but for many, the ideas remain in the realm of research and development and until they and the tools that support them reach a critical point, the masses are unlikely to follow.

Most of the ASP .NET developers I have worked with program ASP .NET via literal controls and string concatenation when left to their own devices. Quite possibly to avoid the horrors of the page lifecycle, but mainly because of a lack of motivation to go out and learn what was different from 'classic' ASP. This is with a framework 6 years old and directly supported by Microsoft that has does have significant productivity benefits when used correctly on the right kinds of problems.

It's quite probable that approaches that do not try to abstract the protocol and document will get enthusiastic adoption by guys who worked with ASP and the many web developers who work cross platform and just don't get or care about ASP .NET's a-little-bit-like-winforms-but-not-when-it-matters idioms. It's also pretty probable that many will find way even then to produce an ongoing maintainence nightmare by travelling the path of least immediate resistance, so we need to make that the right path in the first place.

Developing in .NET is like driving a car when you're an average joe vs a mechanic; the point of the abstractions on top of the engine (the gas pedal, the brake, the steering wheel) are so that people who just need to get from point A to point B can do so with a minimum of fuss.

Visual Studio (and the universe of drag-and-drop-style tools that it fosters in the .NET community) are like those same abstractions: they allow people who know (next to) nothing about what's really going on to be (somewhat) productive with a shallower learning-curve.

But just like the mechanic who can get more performance out of his car, better maintain it, etc. because they have a more complete understanding of what's going on under the hood, any developer who  bothers to learn what you term 'alpha-geek content' and I would term 'the specifics of our profession' is by definition going to be more productive, more valuable, and produce a better, maintainable product.

But there needs to be room in the world for both: the pragmatist concerned only with getting from point A to point as simply as possible with no concern for what's going on under the hood, and the mechanic interested in fine-tuning his engine for maximum output.

In the end, if all we ever had for .NET development tools was notepad, I think it goes without saying that (at least) two things would be true:

1) there wouldn't be ANY .NET developers out there who didn't know what the heck they were doing

2) there would be ALOT fewer .NET developers out there

Resonable people can certainly argue about whether those things would result in a more coherent community that had a higher average level of understanding of CompSci fundamentals, but the practical reality is that the very things that MS has stressed in their tooling in an effort to 'catch up' with the sheer numbers of Java vs. .NET developers has resulted in a stratified caste system in the .NET developer community where the vast majority of people have no clear idea what the tools they use are actually doing for them...AND DONT CARE TO.

As somebody responsible for hiring people from this community, I dearly wish that last part wasn't true but it is.  Some of this is the result of history (e.g., these people came from the VB3 years where you COULDN'T know what was actually going on under the hood <g>) and some of this is the result of the abject failure of higher education (my opinion) to teach fundamentals instead of language proficiency, but I think its (sadly) unrealistic to expect the misanthropes to become alpha-geeks.

Instead we alpha geeks need to acknowledge the misanthrope probably has a place in our .NET society; its a place at the bottom, to be sure, but its a place none-the-less.

Pingback from  Business &raquo; Business ?? I might be an elitist, but you???re a misanthrope

Pingback from  Education without jargon | Lazycoder

When it comes down to it, the issue is people, not technology.

I think its important to stress the different between aptitude and attitude. I agree, Jeremy, that most folks have the aptitude to grokk these things. In general, folks can grokk anything that they're interested in!

But like Steve said above, I think the issue is with attitude - some people just don't care ENOUGH to use it. Playing the devil's advocate, why spend the time (and incur the stress) of grokking something to meet a deadline when you can use whats 'worked' for you 10x before? We all know that in the end, it'll likely better for the developers' skill-set (and career) as well as the product if the alpha approach is used.

However, people are people, and under stressful conditions (deadlines, your bonus is on the line, etc) people will take a 'safe' approach that they know will work.  The key is to provide an environment in which risk taking and learning is 'built into' the schedules, budgets, and estimates. This is not to say that one should write a blank check for development which is pure R&D and no 'business value'; but perhaps instead provide the opportunity to apply the new learnings in the course of building software for the client.

Hey Jeremy

I was in one of your sessions in Redmond. It was great.

Anyway about your blog post, yea, I do detect the stench of elitism oozing out of some developer's this weekend but for everyone of these, there are two other people who may not be as advanced or may be even more advance but are 100% more interesting as people!

The trouble is, people begin to believe their own Hype. They only want to fly with birds they feel are just as "good" as they are. I wonder why they coe to these event at all? Maybe to show off.

It's so much more interesting to speak about the decent folks who will shake your hand and share their passion openly with new and old developers alike. I feel I made a lot of friends this weekend thaks to this attitude.. I look forward to seeing everyone sometime soon and hopefully have more to share next time!!

Pingback from  links for 2008-04-21 | Lazycoder

I agree with your comment about expectations, and a well-known study was performed in the '60s called the "Pygmalion Study" (www.nwrel.org/.../cu7.html), which appears to support this.

It seems like it should be common sense, but it isn't.  All too often I've seen management express low expectations, and their employees' performance mirrored those expectations.  And I've seen the reverse, also, some of which has even resulted in an amazing transformation for some people.

People are #1. Technical strength, .NET kung fu, etc. are (mostly) secondary. For me when I interview, I look for someone that is going to adapt to the environment and be an asset to the entire organization, not just a small part of it. However there is a caveat here. If the guy is dreaming of enterprise datasets floating in a world of VB6 apps and isn't open to new things the discussion usually ends there. Also if the person can't logically think their way out of a paper bag and give me nothing but textbook answers to non-textbook questions I'm going to pause. Aptitude on logic is the utmost importance for me. I can teach C# or Ruby or whatever the flavour of the day is and those kind of skills can be tuned and honed on projects and day to day work. Heck even someone with a waterfall background can get into agile, but the need the core aptitude in the first place. I look at it like art. I'm a long-time-ago-in-a-galaxy-far-far-away graphic artist and designer. For me, learning new things (since I was mostly doing my artwork on paper not the computer) was eventual. It had to happen. For me, the core skills of drawing, composition, expression, movement, weight, etc. was all needed no matter what the medium is. Same thing today. The medium will change and expect it to. I take the Scott Hanselman school of thinking and learn a new language or technology at least once a year (these days it's 2 or 3 a year). People are #1 and they need this type of attitude or else you'll be a maintenance coder who goes nowhere. We still need those people but times move on and the legacy apps you build today in .NET 3.5 are the apps people are going to have to support tommorow.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Well, I was going to post, but @tokes said damn near exactly what I was going to say (and said it probably better than I would've).

Please, ALT.NET advocates - read @tokes comment, please really READ it.  Until you get this, you won't reach the audience you claim you want to help.

@tokes +1

@tokes The Art of computer science is to learn "the techniques used to control the intellectual complexity of large software systems." I find it disappointing that you dismiss the central theme to Jeremy's post, which is that Alt.NET is about making yourself and those around you better. Yeah, you have unrealistic constraints. So do I. So does/did Jeremy. But the most effective way to deal with those constraints is to _be_ a better dev.

From my experience, nobody (well, maybe a minority) is in Alt.NET to chase the "alpha" status or prove they have the larger pair. They are involved because they want to be better and work with better devs. And they have found that the way to get there is to be better at OOP fundamentals and interact with other devs constantly. So that is what they sacrifice and donate their time to focus on.

I wasn't at Seattle, so I can't speak to the elitism of the conference. But I do know that Austin was not very elitist, and I tend to assume that the folks in Seattle weren't. But let's not forget that absolutely everything about Alt.NET has been done before. The only thing new to the concepts and ideology of Alt.NET is the ".NET" part. Its lame to be elitist about something you didn't create, and the criticism has come up enough that I think it should be actively addressed.

Jeremy, I have to agree with your position, and I’d like to add my two cents worth. I have been spending a lot of my own time over the last number of months trying to “catch up” with the great number of bright thinkers like you that I guess are now being called the Alt.Net community. Whatever the name, you guys seem to be seeing things differently from the rather simple examples that Microsoft gives us and that I have always been frustrated with when trying to really learn a .Net topic. Since I discovered the blogging community I haven’t enough time to read it all nor download and learn the various tools. What I am very frustrated with are people that don’t seem to be willing to step outside their very comfortable areas of knowledge. As Jordan Lee said above, it is just easier to do what has worked 10x before. Sure it may work, but with that attitude we’d still have punch cards! I can accept that there are often pressures to just get it done, but I am dismayed at the lack of interest to do better. I have often said that I am very disappointed with “twenty something” year olds espousing “thirty something” year old ideas. They can’t be just stuck in the past, but have had to have been taught old ideas in school. This is another problem, and it doesn’t do much to help the first one! I’ll get off my soap box now.

@Mike

I think Tokes was questioning Jeremy's assumption about the underlying message of the refrain:

"That's great and all for you alpha geeks, but what about Joe Schmoe corporate developer at BIG CO?"

being "obviously" about

"... the average .Net developer just isn't capable of grokking things like OOP fundamentals and some of the coding techniques we use in Agile development."

Suprisingly, I have seen multiple ALT.NET advocates miss the point that Joe Schmoe is struggling with cranking out code from day to day within unreasonable, restrictive constraints that are more common than many realize.  

As @tokes points out, the problem is not just (and is arguably less often) a matter of grokking the concepts and learning new (old) development principles.  Instead, the issue is about convincing Joe Schmoe that it's worth going home and learning these things after his 10 hour day because some alpha geek said so, or because it appears to be "proven" by blog posts, screen cams, or other limited empirical evidence.

If ALT.NET advocates want to reach the Joe Schmoes out there, then they need to take at least one chapter from Marketing playbook: talk to J.S.'s "pain points", especially, as @tokes points out, his immediate ones.

If, however, ALT.NET advocates don't want to reach J.S., that's fine, as well. I say they cash in on their own expertise -- they've a great advantage because they've chosen to handle their constraints by "being a better dev".  They may not have a Silver Bullet, but they potentially have a Golden Hammer.  Time to build the Golden Buildings and enjoy the spoils.

@tokes,

I participated in two sessions at alt.net Seattle directly aimed at finding ways to get developers who didn't have any experience with DI/IOC/AOP/ORM either by making the documentation more accessible to them or showing them how using some of these techniques properly can save them time during development and during maintenance. There may have been other sessions related to education/information that I can't remember right now.

I usually stay out of these kinds of discussions, but I have to admit, the term "alpha geek" is really starting to wear on me.  Any person can be an "alpha geek".  Just because you might be the alpha geek in .NET, there's likely to be someone else who is for PHP, or SQL, or Ruby.  For some reason I can't stand the term.  I guess it just sounds pompous and arrogant.

@tokes and @Troy,

I think it is a mistake to think that the alpha geeks are not dealing with the same realities that you are.  We all have deadlines, we are all creating complex software.  This is not ivory tower, this is about doing things better -- and still hit our deadlines.

The thing is, we/they/them think there is a better way to do things that not only saves time, but creates better software that is better able to adapt to change.   Also, the tools are there (the documentation could be better, but the tools are there) and are in use.  The tools just don't necessarily come from Microsoft, which has proven too much for some developers to handle.

@Chris

It's not that alpha geeks don't struggle with similar reality/restraints as Joe Schmoe does, I never said that.  Granted, things are a bit different than with J.S., since alpha geeks are often so driven to the bleeding edge or dedicated to "Proper Development" that they will even change jobs or drop contracts in order to find a job that is more congruent with their views.  This is not unlike what we have seen happen in the twitterverse with Jeremy and Chad Myers.  And I have a great respect for the two of them for standing up for integrity in their career.  They will be much stronger and happier because of it.  They are not J.S., and that is exactly my point.

The point is that .NET alpha geeks love spending A LOT of their free time learning new things and not-so-new things that have their genesis in other platforms and languages.  It's a enjoyable pasttime.

However, IF ALT.NET is actually trying to reach J.S. to evangelize the good news, the problem is NOT just about how much J.S. can grok of the new (to .NET) generation of widgets, widgetizers and widgetmaking.  I see this fact repeatedly being overlooked by ALT.NET advocates.

So, after J.S. has spent his 10 hour day AND after his ever-ongoing study of v.Next of .Net and related core MS tech required in order to stay marketable, it's unlikely he wants to commit even more time to learn ALT.NET tenets and technologies (however great they may be) just because some alpha geek said so, or because it appears to be "proven" by blog posts, screen cams, or other limited empirical evidence.

J.S. can be all for doing things better, and is likely striving to do better, but "doing things better" is not the same thing as ALT.NETing/AlphaGeeking, to which I am referring.

Many may shame or blame J.S. saying he needs to do things "better", telling them "the status quo is not good enough", etc.  Regardless of who's right or wrong and to what degree, if some ALT.NET advocates' goal is to show J.S. the 'better path", then they need to understand the current mindset of the J.S.'s in the industry.  Asking them WHY they think that this "alpha geek stuff is overkill or impractical" is a much better start than _assuming_ they just have too little faith in their ability to grok it all.

+1 for @TroyDeMonbruen

I was at the event in Redmond over the weekend.  To me, it definitely did NOT smack of elitism.  Just a lot of folks passionate about their craft.  

However, I think the debate on this thread is representative of varying viewpoints on how to "evangelize" alt.net that I observed from folks at the Alt.NET event.  

It's not fair to say J.S. can't grok new things.  Like it or not, it's more about the environment J.S. works in and J.S.'s personality himself.  My experience in consulting at lots of big Co's has shown me both.  I have witnessed environments where folks do strive to improve despite their constraints, as well as ones where they aren't easily able to.

Many of the folks from Microsoft who are involved with alt.net (myself included) want to help evangelize these practices.  But as with evangelizing any 'new' (or old) thing, it requires a solid understanding of WHO the folks are you are evangelizing too.   The message for any given technology/tool/practice may be completely different depending on the audience.

My advice to date for alt.net folks is to lead by example.  Even if you don't call out the practices you are following as "alt.net", just DO it.  People will follow as you lead.  At the same time, as Troy & Tokes said, be sure to address the pain points of the people you want to reach.

I feel the need to explain a bit more about what I was trying to say. In particular about JS's pain points not being addressed by ALT.NET. My perception (and I'm happy to be convinced otherwise) is that the ALT.NET movement is primarily focused on concepts like testability, robustness, code elegance... To them it's all about the code, the frameworks, domain driven development... In some ways it's an all or nothing approach. This is the way you should do it regardless of who you are or what you're developing.

But is that really the case? Should an application that has to be built in a month, will only be used by a handful of people, that will be rebuilt by something newer and better within a year or so, that doesn't have complex workflow or business logic, that really only needs to persists data back to a datastore... really need to contain the level of abstraction and testability of other projects? This is further exacerbated by the reality that most non-product development efforts get one shot to get it right - they don't have the luxury of months (or in some cases years) of refactoring a code base to make everything hum. It's all about "just enough" development.

I get the feeling that (at the moment) to implement a solution based on ALT.NET'ish best practise is simply not appropriate in a lot of situations. It doesn't necessarily get me to production quicker.

A lot of developers would like to have a "Create Shopping Cart Application" button on their toolbar and not have to worry about any of the plumbing. On the other (closer to ALT.NET'ers hearts) extreme we have people who are only worried about the plumbing.

I do not accept that it is the job of Alt.NET to address the "average" developer's pain points! At least, not in the way that the "average" developer wants them addressed. You may think you know what you need to be told to address your pain points, but if that is really the case then why don't you just relieve them yourself? The role of those in Alt.NET is to espouse the principles of Alt.NET. Bonus points if they show how those principles can alleviate your pain points, but not required.

The message of Alt.NET needs to remain constant, while allowing for variation in the delivery. I see the detractors in this thread as arguing against the message and not a delivery. If I'm wrong then so be it. Alt.NET should be a big enough tent to allow for multiple opinions and deliveries. But at the same time, it certainly seems like folks want a clean and sanitized message they only have to read to grok perfectly, without putting any real work into understanding. And that is simply not the case with Alt.NET. You have to be challenged in order to learn and grow. Learning the principles behind Alt.NET/Agile/OOP is hard work, and requires active participation.

@tokes I'm glad we agree that Alt.NET values testability, robustness, and code elegance. You ask if Alt.NET believe that you need framework after framework in order to produce valuable code. The problem with that question is you take the bite-size problems from MSDN examples and apply what the Alt.NET folks are promoting to it. No, you don't _need_ to add all that ceremony to a simple task. (Unless you want to verify your code works, and then it is probably a good idea.)

But I believe that most Alt.NET folks would argue that you can and will benefit from the Alt.NET approach even on such simple projects. And if you were to measure the time and effort required in both approaches, they would be the same. If you try it I believe you will see that Alt.NET does not add an overwhelming overhead. So, would you rather have an app built with untestable spaghetti code? Or would you rather have a clean, elegant, robust app that can be verified with tests?

Also, I can't believe you are seriously asking Alt.NET to address "just enough" development. That seems obviously antithetical to Alt.NET, and makes me think you are trying to bait someone.

Alt.NET is not about plumbing, although some folks do unfortunately get caught up in that. Alt.NET is about producing testability, robustness, and elegant code.

"that's great and all for you alpha geeks, but what about Joe Schmoe corporate developer at BIG CO?"

My question is, "what about them?"

Seriously, people under-rate themselves daily and they should quit.  People are much more capable than they often think.  It disgusts me when they suppress themselves or worse, when management suppresses them.

Developers need to get out there and make Agile standard, CI standard, peer review standard, etc., etc., etc... then maybe we could focus on what we could actually do for the industries we work for.  At least, that is what I generally demand of the groups I work for.  I don't care how "stupid" a developer thinks they are, or how "slow" management thinks a group is.  Gimme some time and we'll start kicking some ass and taking names.

I do have to say thx for the blogs entries and such, it drives home the point as more voices bring up the points.  I hear less and less resistance to the general competance of Agile and "groups" that develop...  and it has a lot to do with you, Hanselman, ScottGu, Haack, and others of your ilk (hopefully someone is reading my blog too)...  so keep up the good work and motivation u guys send out thru the communities.

My question is: if I'm in mixed company, and someone calls me an alpha geek or an alt.netter, do I:

1. smile and nod

2. turn red and look at my feet

3. take up arms and smite the speaker for defamation of character.

Which do you feel is appropriate?

Phew - this is getting interesting and I'm not sure I can get my message across properly in comments. But here's some more fuel to the fire.

- I do understand and our projects use many of the ideas and concepts espoused by ALT.NET

- I don't think it is as simple as do it this way otherwise it's wrong - horses for courses

- I do think the ALT.NET movement is important for setting a vision for how we can do things better and (in some part) educating users on how they can achieve this

- I think that you can still write good code that is still maintainable/robust/elegant without necessarily employing all that ALT.NET espouses

- I do not agree that if (!ALT.NET) { code = SpaghettiCode; }

- I do think that "Just Enough" development is worth considering and I wasn't trying to bait anyone (honest). My implication is that there is no point writing code that goes beyond what the client/system requires - for example, if an application is essentially a CRUD interface over a database do you really need an ORM. Or if an application is going to be built once and never updated (or will be replaced in the near future) do you really need a comprehensive set of test suites. Obviously there are cases where you need to do these things but not always - as I said "Just Enough".

@tokes Here are my thoughts on your latest comment:

"I don't think it is as simple as do it this way otherwise it's wrong - horses for courses"

Nobody is calling anything or anyone "wrong". There are no litmus tests in Alt.NET. Just because someone voices an opinion of what they think leads to clean and maintainable code, it doesn't mean that they believe that all code ever written needs to conform to that exact standard. Nobody is accusing you of a bias or prejudice, why do you feel the need to accuse Alt.NET?

"I do think the ALT.NET movement is important for setting a vision for how we can do things better and (in some part) educating users on how they can achieve this"

If you replace "users" with "developers" then we are in perfect agreement.

"I think that you can still write good code that is still maintainable/robust/elegant without necessarily employing all that ALT.NET espouses"

Alt.NET espouses maintainable/robust/elegant code. If you get maintainable/robust/elegant code then you are doing exactly what Alt.NET is encouraging. Where is the conflict?

"I do not agree that if (!ALT.NET) { code = SpaghettiCode; }"

Nobody said that all code not written "the Alt.NET way" is spaghetti code. But I think we can all agree that Alt.NET does focus on avoiding spaghetti code.

Nobody should be telling you that unless you use IoC and DI frameworks with unit tests that include mocks you are not a real developer or aren't worthy of inclusion in Alt.NET. Everyone that wants to be a better developer and has an open mind should feel welcome in Alt.NET. If that's not the case let me know and we'll rustle us up a posse and kick some ass.

"I do think that "Just Enough" development is worth considering"

Nobody is claiming that Alt.NET means you remove your judgement. I think the point that can be made about "Just Enough" development is that it does not scale. In all my years developing code in large enterprises I have very, very rarely seen when "Just Enough" development is justified.

OK - 2 final comments

@mike

1. I don't think we're miles apart in what we are saying - while I do have my pragmatism hat on at the moment, I can still see where ALT.NET is coming from. If I come across as accusing ALT.NET of anything, that's not my intention. Just voicing the concerns of the community for you and others to consider.

2. I've just seen Mike's mugshot in his blog - I now agree with everything you say - do you moonlight as a bouncer?

"If you replace "users" with "developers" then we are in perfect agreement."

If you change it to "users and developers" then you match what I saw at alt.net Seattle last weekend.

@Chris

#3, because it has the word "smite" in it.

@tokes

"I do think that "Just Enough" development is worth considering"

I think you are both right and wrong about this.  This is about evolutionary design and the last responsible moment (both have been blogged about by Jeremy).  You might not want an ORM for a CRUD application but if the management say "That's a great little app you go there, let's put some heavy analysis/calculation in!" it will cost you a lot to do the changes.

Always do the minimum effort as long as you're able to change the code/the patterns quickly without too much pain.  Be aware of the futur need of the application and keep an eye open for better way of doing.  The most important I think is not to be caught off-guard when changes occurs in the requirements.

My last post, I might be an elitist, but you&#39;re a misanthrope , has kicked up a great conversation

Pingback from  misanthrope