You are not alone

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/you_are_not_alone.htm]

I continually try to get more involved in the developer community (such as via user groups and tech events). This gives me the opportunity to talk to developers across a wide spectrum of different projects. One type of developer, for whom my heart really goes out to, is the lone developer struggling in isolation. They're trying, but they're on a team of one - the only consultant on a project, a remote developer working from home, or the only developer in a one-person "department" of a small company.

The problem is that software engineering is too hard to do alone. It's easy to feel like you're on the outside looking in - while other departments have niche experts and devs to cover your back, you're left all by your lonesome to figure out the entire thing yourself.

Sometimes you can get out of the situation - switch jobs or press the business sponsors to hire a secondary dev (do they really want the entire project resting with one person, without any backup if you become unavailable?)

However, even if you cannot change your department or project's headcount, you are still never alone. Especially with the online developer community, blogs, forums, user groups, conferences, books, and the like. It is one joy of software engineering in today's world - you are never alone.

Related: What if you're a big fish in a small pond - life without a mentor?

How will you learn the next wave?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_will_you_learn_the_next_wave.htm]

New technology is constantly coming out. Some of these are small - a new tool, a special trick, or some open source library - and these can be learned easily enough. However, every few years, there's a fundamentally new wave of technologies that makes the previous wave obsolete. For example, classic ASP to ASP.Net 1.0, to ASP.Net (3.5 with Ajax, JQuery, and MVC) to Silverlight. - every few years there's a significantly more powerful UI technology.

So, the question becomes, how do you continually keep up with the next wave?

You have three main categories of options:

• Your company trains you. This was popular during good economic times. Some companies have a training budget based on a percent of the employee's salary.
• Your company doesn't train you, so instead you train yourself.
• You don't keep up, and eventually become obsolete.

The last option speaks for itself - but there's a difficult balance between the first two. Every developer should be able to ask their manager "What role, if any, does the company have in assisting me to learn the next wave of technologies?" Every manager should have a ready answer.

Realistically, you need both internal motivation and external support. For example, if your company won't even pay for a $30 book on a hot new technology, then you're screwed. On the other hand, you simply can't learn a whole new technology by passively skimming blogs during your lunch hour.

Personally, I'd emphasize the concept of an upward spiral. If you want to be a decent developer, be prepared to invest:

• Time - prepare to spend on average of at least 8-10 hours a week doing continual education. Maybe you're working 60+ hour weeks at your company, and the 10 hours is part of that. Maybe you have a "cushy" 40-hour week job and you do the 10 hours on your "free time". Sure, there are weeks (or even entire months) where life needs you to take a break. Likewise, there will be other times when an in-demand tech first comes out that you may be sprinting.
• People - Try to get to a live-person event at least once a year, such as a user group or conference. Also, explicitly seek out peers who you can collaborate with (even doing informal code reviews with your coworkers, or discussing ideas during a lunch break).
• Blogs - Use a blog aggregator to continually monitor the industry leader's blogs. This will give you a heads up of new techs coming down the pipeline, so you can prepare. If the tech actually has potential (as opposed to just some other buzzword), you'll see it light up on multiple people's blogs.
• Books - Especially for a new wave, or for matured design patterns on existing techs, try to read a full book at least twice a year (I think once every other month is more ideal, but there's a balance).
• Projects - If you have the opportunity, put in the extra work to get on a project that uses a new technology that appeals to you. Ultimately, the best way to learn a new tech is to actually use it, and unless you use it on a real project, you'll always remain a hobbyist.

Essentially, learning a new technology takes hard, pro-active, work, which many devs are already willing to do. The question becomes how to best maximize your investment on that hard work.

Real Life: Copying code is easier than copying snow dinosaurs

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_copying_code_is_easier_than_copying_snow_dinosaur.htm]

In Chicago, we get snow at the end of March. The warmer weather makes the snow packy, so we could finally do useful things with it, like make snow dinosaurs:

 

Actually, it was just one snow dinosaur - which brings me to my point: In the physical world, it's expensive to reduplicate work. For each snowball, I need to find an open patch of snow (material) and manually roll the ball (labor). Unlike software, I cannot just create the "code" once and copy it five times. It's not like some million-line application framework that you can just reduplicate with a single copy command. Hence, after an hour of exhausting snow-ball rolling and lifting, to my son's disappointment, we stopped at just one snow-dinosaur. Now if we just made a Silverlight game with snow dinosaurs, we could add as many as we wanted.

BOOK: Making Things Happen

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_making_things_happen.htm]

I got to finish reading another good book: Making Things Happen: Mastering Project Management, by Scott Berkun. Scott worked for 10 years at Microsoft, which included projects on IE, MSN, and Windows. The book is practical and engaging - definitely not one of these ivory-tower things that bore you to death. All the book drawings also look like sketches on the back of a napkin - no MS Visio here.

Perhaps what I find interesting about it is that so many developers think that the only thing they really need is super technical knowledge - "If I'm just brilliant, then everyone will recognize my brilliance, and life will be good." This is simply not true - there are non-technical factors that can kill projects and careers: people skills, politics, bad management, etc... My entire software career, I've seen people significantly smarter than myself who crash and burn because, although they got the tech skills, they are clueless about how to convert those tech skills to "make things happen".

Scott divides his book into three main parts:

1. Plans
2. Skills
3. Management

Amongst those three main categories, he covers a broad spectrum of vital, yet non-technical skills, such as figuring out what to do, making good decisions, how not to annoy people, what to do when things go wrong, and actually getting things to happen.

Some quotes I liked:

• "failures force us to pay attention." (pg. 5)
• [about schedules] "attempting to predict the future - something our species rarely does well." (pg. 31)
• "The more change that is expected, the shorter the milestones should be." (pg. 39)
• "Volume should never be confused with quality. Unfortunately, because volume is easier to produce than quality..." (pg. 79)
• "innovative work often occurs when one person has both requirements and design authority" (pg. 94)
• "programmers tend not to be interested in writing things that don't compile." (pg. 140)
• "If I can't come up with more than one choice, I clearly don't understand the problem well enough: there are always alternatives." (pg. 161)
• "For most tough decisions, the problem isn't a lack of data. Tough decisions exist no matter how much information you have." (pg. 167)
• "You have to  be willing to get burned if you want to develop the skill of putting out fires." (pg. 222)
• "if you can't say no, you can't manage." (pg. 265)
• "As a rule, the further a team gets from reality, the harder it is to make good things happen." (pg. 267)

Tips to be a good code-reviewer

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/tips_to_be_a_good_codereviewer.htm]

Code reviews are essential to high-quality code. Imagine back in high school when you're taking a difficult math test, and then in the last few minutes, the teacher lets you pair up with another student to compare your answers. You almost always will catch extra errors that way, and it's the exact same result with a code review. So, given that we all know that we should do some sort of code review, here are ideas on how to be a good code reviewer:

• Always keep in mind that the other person worked hard on it, and they probably have an emotional attachment. Someone once said something like "Their code is like their baby - don't say 'he looks so ugly', rather make a nice comment like 'Oh, he looks just like his father.' "
• Start with major things first. Don't start nit-picking ("your naming convention isn't good"), if they have major other issues. Focus on their biggest need. If they want your opinion on the data access strategy, that's what they'll be most receptive too.
• Don't just be a rubber stamp - it wastes their time by giving them a false sense of security and tells them nothing new.
• Look to affirm good ideas as well as discourage bad ones.
• Unless they are really missing the basic concepts, don't just tell them to go read some 500 page book - they'll see it as you dismissing them. Give them a tangible example and perhaps provide a web link to a short article or reference guide. If they read that (or they ask for more material), then suggest the books.
• Keep the session relatively short, short enough to fit within their attention span.
• Keep in mind the goal is to make better code for the good of the team, not show off how smart you are.

Why code generate something after it is already written?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_code_generate_something_after_it_is_already_written.htm]

If you've already written something, why go back and code-gen it? There could be a couple reasons:

• You're going to write a lot more of it, so you might as well leverage code-gen for all that existing code.
• You need to extend it with more functionality. Sure, the current stuff is already written, but you need to add new (tedious) features, like recording which properties of a class have had their setters called.
• You want to make it easier to maintain. Manually-maintained code counts as technical debt. Such code grows, get copied into off-by-one, and gradually gets customized. By code-generating it now, you'll make maintenance easier in the future.
• You want to document the rules. As codeGen essentially acts as documentation, this will give you a place to clearly define all those boundary cases.
• The code is already easy to generate. If the code is already prepared to be generated, might as well go ahead and migrate it.

Preparing your code to be code-generated

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/preparing_your_code_to_be_codegenerated.htm]

Sometimes you're not sure if something should be code-generated. If you do end up code-generating it in the future, there are several guidelines you can follow to make your life easier:

• Physically place the code in separate files. One of the hardest things to do with code-gen is to merge generated and custom code. By isolated the potential code in its own file, you'll spare yourself this pain.
• Standardize and simplify your code. For example, if you prefix all variables with Hungarian notation, your code-generator would need to do extra work to determine what that prefix is.
• Refactor as much as possible first. The less unique code you have, the easier it will be. there's also a good balance between code-generation and refactoring.
• Document the rules. If you're writing code based off a set of rules, document those rules - they'll come in handy as you try to generate the edge cases.