Inspiring Developers to Greatness

How freaking pretentious is that title! And you thought my arrogance knew no bounds. Silly mortal.

Anyway, this is a question that I have been pondering, and asking, for a while. I wish there were a simple answer, but I also wish I could lose weight while continuing to eat like I do and never exercise.

What I have come up with so far are two factors that contribute greatly to the inspiration of developers, but do not actually guarantee anything.

First, you need to give developers some ability to control their destiny. Developers are naturally curious and creative people, so given a little freedom, they are likely to do something interesting. Or maybe they won't, but they will do something out of the ordinary and they will extend their way of thinking and that can only help their ability to do their jobs. [Thanks to Jason Staten for crystallizing this for me.]

The second common thread in these discussions is "where I work, we do..." The company culture of giving a crap about continual improvement seems to be a key ingredient. I know that before I worked with a team of excited developers, I just thought of this as a job. Their passion spread to me and I am trying to spread it to others. This is a pattern that I have heard over and over. (This usually, but not always, includes time to work on what you care about as part of your workday.)

Conversely, if you work in a culture of disinterest, you will either find your interest waning, or you will get frustrated and leave. Chad Fowler would tell you to just get out. I have applied this strategy a couple of times. It isn't worth your sanity or your passion to stick it out at a crappy, soul-sucking job.

Things like reading books on development, trying new languages, attending conferences, watching videos, going to user groups and participating in forums all keep the flames hot and help me continue on the path, but I don't know that any of them will get someone on the path. I have noticed that most of the dispassionate developers I know don't (and won't) do any of those things because they are third or fourth order ignorant. They don't even recognize the existence of the problem.

If you have any thoughts, suggestions, tips, tricks or money for me, please leave them in the comments.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more