As we were wrapping up the last night I received what seemed like an innocent enough question from one of the students. "What kind of job do you think I should look for?"

It really caught me off guard, although I should have seen it coming. I didn't have a good answer on the tip of my tongue, and that may be because there isn't one. The CIS program is not designed specifically to churn out developers, but introduces students to all sorts of disciplines so they can pick a specialty later. For example thy study project management, requirements analysis, some programming, some networking, you get the idea. So the question really was bigger than it seemed.

Let's assume for this post that the person in question wanted to be a developer. Even if the person is looking to become a developer, the question what kind of employer to seek out isn't an easy one.

My father has worked 45 years as a mechanic for 2 employers. He is happy doing that. Many people, in fact most, are content with an occupation just like that. There is nothing in the world wrong with this; the world turns, people still live and love, people die, babies are born, all without making a life out of their career. Other people don't see things that way. They are passionate about their work and want to contribute to a higher vision of their chosen profession. I would guess if you are reading this, you see yourself in a similar light.

Someone develops code for the state government agencies. In fact, I have met many competent people who do exactly that. Are those developers missing out on something? Probably not in their mind, or they wouldn't be there. The point is simply that for some people a job is a job and there is no dishonor there.

This means my answer can't be glib, it must be realistic. You can't just say, "Go somewhere Agile," or, "Find a place where you can write Ruby." This is real life and sometimes grown ups balance security and risk and boredom and excitement because they have kids at home, or need special medical accommodation, or any one of a host of other considerations.

All that said, if you are passionate about the craft, if you want to drink in the industry, if you do want to learn as much as you can as soon as you can, I say this: Go work for a company with fewer than 50 employees building web solutions.

Locus of Control

As a company grows larger, the locus of control individuals have inside the organization grows smaller. This is easy to see.

In smaller organizations, people tend to be jacks of all trades. If a server goes down, you care. If a defect is found, you care. If there is a client in the picture, you tend to actually know them. In short, small organizations provide first hand experience with many aspects of developing and delivering products.

In larger companies and teams, people tend to be expected to focus on a small niche of expertise. I cannot begin to tell you the number of resumes I have seen from people who spent years poking at HP's test harness suite or Micron's order entry system. This kind of "specialization" is not usually a recipe for career growth.

Technology Exposure

You'll get to go deep on technology because you are part of a small group that simply must make it work. There is no passing the buck, because there is no one to pass it to. You'll get to know whatever the technology stack is inside and out.

I recommend web development for a simple reason, the web isn't going away! Additionally, the technology involved in delivering to the web is growing at an astounding pace. I don't know what the web will evolve to  in years to come, but it will be on hulluva ride.

Comradery and Mentorship

In a small organization, it is easier to foster a genuine sense that we are all in this together. The esprit de' corp in a smaller organization is typically tighter than in large organizations. This means you stand a better chance of falling in with someone who can actually mentor your career and take a genuine interest in your development.

Of course this exists in larger companies and is lacking in many smaller ones. I do think it is more generally found in smaller organizations, though.

Conclusion

So, what's the right answer? There isn't one, of course. There are just too many options and factors.

I will say that instead of ensuring your potential employer can pass Spolsky's Joel Test, it is more important to ensure you will be empowered to help them pass it if you come aboard.

Have you ever looked at the website HotOrNot.com? It turns out that pretty much everyone from Quazzi Modo to Angelina Jolie ranks from a 4 to a 7. This is a prime example of our poor ability to estimate on a closely related value scale. It is pretty tough to tell if something is a 2 or a 3, but it is pretty easy to see the difference in size between a 5 and a 13. 13 is more than twice as big as 5, right?

Think about it this way: Does it really matter if something is going to take 3 hours or six hours? In software development, it typically doesn’t matter.

So the relative estimation model looks like this, in pursuing an estimate for piece of work A:

1. Is this piece of work bigger or smaller than that piece of work B that we already did?
2. Bigger? OK, how much bigger? 2X bigger? 3X?
3. OK, 4X bigger.
4. Here is piece of work C that we already did. It was estimated at 4X bigger than B. Is it roughly the same size as A?
5. Yes.
6. Cool, we are done.

Once we understand that we can trust these relative comparisons because we are better at them than empirical estimation, it becomes much easier to size our work. Look at things you've already done and estimate the new one in relation to the previous work. We get our relative size and convert it into time, dollars, or whatever the project managers need and we are done. This is a much faster (and accurate) thing to do than to break it down into tasks and estimate each task. Why? Because we will never get the tasking right.

There is a ton more that could be said (and has) on relative estimation, but remember this: The next time you have to estimate a project for your manager, make it easier on yourself by doing a relative size first. You'll get back to coding much faster and you'll find the numbers are amazingly accurate.

I started playing with the words and making them resemble singleton. "Complexton" did not sound right to me. I should mention that I was washing my hands as I was contemplating this. I lifted up my head, looked into the mirror, and thought, "SIMPLETON." The opposite of a singleton is a "simpleton."

If the opposite of a singleton is not a "simpleton," then what is it? Until I find a plausible answer, I will try and insert this new term into my next design discussion.

So let me state for the record: today's elegant code is tomorrow's drivel.  Don't feel bad, many writers have the same problems.  What was super amazing back in the day is now rubbish or near unreadable.  I am thinking of the Victorian writing that Hemingway usurped, and now Hemingway himself is almost unreadable (to me anyway).  Tastes change with the times.  That is a simple fact.

So what can you do about this?  As I say that old writing sucks to read (read Washington Irvine lately?), great works of literature still abound (for instance, Hemingway is still a great writer -- even if I prefer Tolkien) .  So take some notes from them, and from other crafts in looking for the answer.  If you want a cliff notes version of what this is going to tell you, it is this: you must always push yourself to get better.

1. Find a good teacher.  Nothing is better than sitting at the feet of a master who can nudge you along in the right direction.  While early mistakes can often be corrected easily with a little bit of guidance, after they have had some time to fester all bets are off.  I believe a fare number of "Anit-patterns" were created by self taught developers (find SQL Ejaculation on this site). 
2. Read.   Good writer are first good readers.  Start with Code Complete, move into a good Patterns book, get MSDN Magazine, find some bloggers your like, but keep moving.  You will NEVER be done reading.  I imagine that even Martin Fowler has a "to read" booklist a mile long.
3. Read code.   There are a plethora of open source project just waiting to be read -- do so.  This is the single best way to expand your coding repertoire, find things your language can do that you didn't even know about..   Scott Hanselman has recently popularized this idea, and I thank him for it.
4. Practice.  This means writing small applications at home.  You get an idea that you want to try out -- do it.  I don't mean you have to write finished applications, just have some exploring time.  I remember talking with an 80 year old master woodworker (he lives down the street from me), who was telling me how many time he would practice making dovetail joints before he felt competent.  It was years worth.
5. Pay Attention.  Being good at anything really amounts to that.  And don't just pay attention when reading, writing, or talking about code.  Inspiration come from everywhere, any good artist will tell you that.  Pay attention when you cook, when you work on the car, when you are wood working, playing an instrument, whatever it is that you do.  This will help you in the end, event if it is just learning the amount of dedication it really takes to become good at something.
6. Beware of preferences.  Any time I hear someone start a statement with "I prefer code to ..." you know things are going downhill.  If you find someone who cares more about how your code is formatted then how it is written you have found yourself in a mess.  More importantly, beware of them in yourself.   Having code style standard is important, but it isn't worth loosing sleep over.  This also pertains to inheritance, patterns, use of particular classes (e.g. always using the generic list class in C# when a Dictionary would be better). 
7. No Sacred Cows. Believe no single source of information.  This means not thinking that Microsoft, Sun, IBM, Richard Stallman, or anyone else will have all of the correct answers.  Apply the scientific method and do some research, experiment, and question the authority.   There should be no sacred cows in programming.
8. Talk with others.  Join a user group, show up every now and then, heckle the presenter, and -maybe- speak.  You want a broad range of people who you can talk to and bounce ideas off of.  This will help you from becoming that crazy guy in the corner who vehemently states that all your code should be in one file.  Having a mentor (mentioned earlier) is great, but having people around to push you from multiple directions is also good.
9. Learn languages.  This gets back to the "read code" idea. Make that multiple types of languages as well.  If you know C# or Java and SQL, learn Python or Ruby, get really good at JavaScript.  If you want something really out there, learn MDX.  This is also a repertoire thing.  Seeing how other languages work will make you rethink your ideas about what your current code, in whatever languages you are working in, should look like.
10. Keep Thinking!!!  That is possibly the most important point.  Keep thinking.  Don't just evaluate something once and never return, go back and reevaluate. Did the technique work?  How could it have been better?   The idea is continual improvement.
11. Switch jobs every now and then.  When I announced I was leaving my first programming job out of college, the VP of R&D had me sit down with him and talk.  He wasn't trying to keep me (he knew I was moving to be closer to family), he wanted to give me some advice.  He told me to change jobs every three years.  After you have been with a place for three years you have probably learned everything you are going to learn and it time to move on.  This doesn't mean changing companies either.  I've been with the same company now for four years, but I've had three different jobs.  If you have been writing commercial applications, become a consultant - or vise-versa, become a test engineer, expand your boundaries.  Again, this is about pushing yourself to be better.
12. Have a Hobby. But don't ask about me, I have too many.   Creating software is about creating things.  So I suggest picking a hobby that involves creating something.  Popular hobbies amongst programmers I know include: cooking, music, woodworking, beer making, and BBQ (which is different than cooking).  But don't discount sports (golf is always popular), computer games, and board games.  Anything that promotes the development of skill levels can't be a bad thing.

And I'm stopping there.  This is my beginner's guide to how to become the writer elegant code.  If you have others you think I missed, add them too the comments.

1. I'm not much of a moderator (I talk to much)
2. Code coverage is a art in divination
3. Mock/Stub/Fake Objects are hard to explain
4. Over use Mocks could be a code smell
5. The discussion format actually works pretty well for talking about unit testing
6. If you give geeks a chance to talk, they will talk

1. Unit testing forces you to write better code
2. Unit testing forces you to use better object oriented principles

Test Technology

Code Coverage

Testing existing code

UI Testing

Testing Database code

After the meeting

Most of us got into this business because we liked making computers do things we think of as cool. The most successful among us still get that rush when our new creation spools up and runs.

Tinkerers like us tend to gold plate the pieces of our systems we find most interesting. This is why developers will often find themselves the go-to-guy for certain specialities. A dev likes making services, she makes good ones because it's fun, she gets to make more of them. Sounds perfectly reasonable and symbiotic, no?

It can be.

Ignoring the Boring

When we get to focus exclusively on the parts of the system that really flip our bits, it can come at a price. Although we might be jazzed about services, that data model still needs our attention. It is fairly common to focus on that thing that really gets us excited and forget (or outright ignore) that part which seems boring. Just because you think someone else will come along and sweep up after doesn't make it happen.

The most common instance of "Ignoring the Boring" is documentation. Let's face it, we want to write in languages other than English, right? Documentation is in the elegance of my self-describing code, right? Not so much. Whether we like it or not, documentation is often a deliverable of our system and as such deserves the respect we might give to our WSDL or interface definitions. Just because the reader is a human rather than a machine doesn't mean we should short change her because it's boring to do the work.

Smells of Sub-Optimizing

It is easy to see this kind of monocular behavior can result in a really clean UI with a messy back end, or visa versa. Whatever gets the short end of the stick will tend to show up in the system as a glaring deficit. We can then measure the deficit in the ignored sub-component in observable ways. Some failures of attention to detail might include:

• Lack of enforced constraints or relationships in database tables
• Code in the view, because it's just this one little thing
• Leaky abstractions, because wrapping that data model in business logic can be a real PITA
• No check in notes
• Not taking the time to do code reviews, even informally

The System Isn't Your Playground

On the other end of the spectrum, what happens when we get to play with the things that are fun? The results can depend on what the implementer really enjoys.

One recent real world story I heard told of a hardware engineer who designed 7 different chips within a device, each with a fundamentally different way of representing logic circuits. The chip engineer had a great time applying all the different techniques he read about in last month's Nerd Fest Quarterly, but the team assigned to test this Franken-board was rightly annoyed.

Another symptom of playground development is needless abstraction layers or design patterns applied to simple problems. If a system is implemented with a gazillion abstraction layers where only a concrete implementation will do, you can bet someone is reading the Gang of Four in bed at night.

If your passion is trying new tools and technologies, how many of these shiny new toys are incorporated into your system without deliberate attention? How many logging libraries does one team really need? How many unit test frameworks?

YAGNI, 'nuff said.

Keep Your Passion Alive

So, what are you saying, Starr? Stop trying to extract pleasure from my work? Just bang the keys and give my 40 to the man? Of course not!

I am simply asserting that there is a degree of professionalism needed at all levels. Let's care about the system as a whole and be good stewards to the craft, not just the shiny bits. And, yes, documentation is a justifiable deliverable. Cowboy up.

Learn new techniques that fire you up and apply them wisely, not with wild abandon. Delayed gratification means not always getting to use WPF to make a draw a button, or SilverLight to make a logo spin (<-- bad example). Sometimes this means capitulating to use the prescribed framework so we can get a systemic optimization instead of trying to roll our own multi-tenant web portal, yet again.

Having more tools in our toolbox is a great thing. This is the essence of youthful fun in our work. Knowing when to use those shiny new tools is the wisdom part. Now go learn something new.

• XHML
• CSS
• JavaScript
• JSON
• JQuery
• Asp.Net Ajax framework

1. Address the unknown that the team identifies. If they don't understand something in planning, clear it up before execution begins.
2. Some architectural decision must be big and early. These are often based on business requirements, not technology. Java vs. .Net, as an example.
3. If metrics are prescribed to a team, explain how they will be used. Metrics cause fear, mitigate that fear.
4. You can prescribe Agility, but not hyper-performance.
5. Part of the maturation process of Agile is the tendency for people to over-analyze the holy heck out of it. This is relly a reaction to the cost of software development and the incredible amounts of historical waste in the industry.
6. CEOs do not care about code coverage. Speak to them appropriately about quality.
7. Earned value reporting is ridiculous.
8. "Don't wait until the customer is screaming to optimize for performance." -- Thanks, Kevin.
9. Deliver less, but sooner and more often.
10. "Daddy, is that your new OOBE?" - My kid when I opened my new MacBook. "Yes, it is, son. Yes, it is."

1. Carry a model at all times to express your understanding to others.
2. Look for patterns in all systems at all levels. Seeing them is the very essence of insight.
3. At the application level, architecture and design are synonymous.
4. "BizTalk is overkill" is a typically overheard comment of Drive by Architecture.
5. Developers would never prescribe BizTalk or a TIBCO or any other message bus system. That type of decision is typical of a CTO or someone who reports directly to one. These are strategic decisions. "I think that, generally, if you're looking at something like BizTalk, you're probably looking at somebody, a directory port of a CIO or a CTO, I would say." -- Roger Session
6. "Anything that is architecture and is specific to a particular technology is kind of an oxymoron." -- Roger Sessions
7. Good design allows for emergent functionality, which we can also think of as purposeful evolution.
8. The Open/Close principle doesn't mean you can't recompile. -- Allan Shalloway
9. Fewer keystrokes != Elegant Code. Damn it! -- Dave Starr :)
10. Architectural decisions are those that will kill your business if they are wrong.
11. To introduce a new technology into a system, have the entire team immerse in an architectural spike, then estimate.
12. Schedule riskiest work first. Try prioritizing a backlog by risk.
13. The work of a developer is to uncover complexity, the work of an architect is to simplify it.
14. A legacy system is one that is already making money.
15. “The Winchester House in San Jose is the perfect example of following a vision without a plan.”

So let me state for the record: today's elegant code is tomorrow's drivel.  Don't feel bad, many writers have the same problems.  What was super amazing back in the day is now rubbish or near unreadable.  I am thinking of the Victorian writing that Hemingway usurped, and now Hemingway himself is almost unreadable (to me anyway).  Tastes change with the times.  That is a simple fact.

So what can you do about this?  As I say that old writing sucks to read (read Washington Irvine lately?), great works of literature still abound (for instance, Hemingway is still a great writer -- even if I prefer Tolkien) .  So take some notes from them, and from other crafts in looking for the answer.  If you want a cliff notes version of what this is going to tell you, it is this: you must always push yourself to get better.

1. Find a good teacher.  Nothing is better than sitting at the feet of a master who can nudge you along in the right direction.  While early mistakes can often be corrected easily with a little bit of guidance, after they have had some time to fester all bets are off.  I believe a fare number of "Anit-patterns" were created by self taught developers (find SQL Ejaculation on this site). 
2. Read.   Good writer are first good readers.  Start with Code Complete, move into a good Patterns book, get MSDN Magazine, find some bloggers your like, but keep moving.  You will NEVER be done reading.  I imagine that even Martin Fowler has a "to read" booklist a mile long.
3. Read code.   There are a plethora of open source project just waiting to be read -- do so.  This is the single best way to expand your coding repertoire, find things your language can do that you didn't even know about..   Scott Hanselman has recently popularized this idea, and I thank him for it.
4. Practice.  This means writing small applications at home.  You get an idea that you want to try out -- do it.  I don't mean you have to write finished applications, just have some exploring time.  I remember talking with an 80 year old master woodworker (he lives down the street from me), who was telling me how many time he would practice making dovetail joints before he felt competent.  It was years worth.
5. Pay Attention.  Being good at anything really amounts to that.  And don't just pay attention when reading, writing, or talking about code.  Inspiration come from everywhere, any good artist will tell you that.  Pay attention when you cook, when you work on the car, when you are wood working, playing an instrument, whatever it is that you do.  This will help you in the end, event if it is just learning the amount of dedication it really takes to become good at something.
6. Beware of preferences.  Any time I hear someone start a statement with "I prefer code to ..." you know things are going downhill.  If you find someone who cares more about how your code is formatted then how it is written you have found yourself in a mess.  More importantly, beware of them in yourself.   Having code style standard is important, but it isn't worth loosing sleep over.  This also pertains to inheritance, patterns, use of particular classes (e.g. always using the generic list class in C# when a Dictionary would be better). 
7. No Sacred Cows. Believe no single source of information.  This means not thinking that Microsoft, Sun, IBM, Richard Stallman, or anyone else will have all of the correct answers.  Apply the scientific method and do some research, experiment, and question the authority.   There should be no sacred cows in programming.
8. Talk with others.  Join a user group, show up every now and then, heckle the presenter, and -maybe- speak.  You want a broad range of people who you can talk to and bounce ideas off of.  This will help you from becoming that crazy guy in the corner who vehemently states that all your code should be in one file.  Having a mentor (mentioned earlier) is great, but having people around to push you from multiple directions is also good.
9. Learn languages.  This gets back to the "read code" idea. Make that multiple types of languages as well.  If you know C# or Java and SQL, learn Python or Ruby, get really good at JavaScript.  If you want something really out there, learn MDX.  This is also a repertoire thing.  Seeing how other languages work will make you rethink your ideas about what your current code, in whatever languages you are working in, should look like.
10. Keep Thinking!!!  That is possibly the most important point.  Keep thinking.  Don't just evaluate something once and never return, go back and reevaluate. Did the technique work?  How could it have been better?   The idea is continual improvement.
11. Switch jobs every now and then.  When I announced I was leaving my first programming job out of college, the VP of R&D had me sit down with him and talk.  He wasn't trying to keep me (he knew I was moving to be closer to family), he wanted to give me some advice.  He told me to change jobs every three years.  After you have been with a place for three years you have probably learned everything you are going to learn and it time to move on.  This doesn't mean changing companies either.  I've been with the same company now for four years, but I've had three different jobs.  If you have been writing commercial applications, become a consultant - or vise-versa, become a test engineer, expand your boundaries.  Again, this is about pushing yourself to be better.
12. Have a Hobby. But don't ask about me, I have too many.   Creating software is about creating things.  So I suggest picking a hobby that involves creating something.  Popular hobbies amongst programmers I know include: cooking, music, woodworking, beer making, and BBQ (which is different than cooking).  But don't discount sports (golf is always popular), computer games, and board games.  Anything that promotes the development of skill levels can't be a bad thing.

And I'm stopping there.  This is my beginner's guide to how to become the writer elegant code.  If you have others you think I missed, add them too the comments.