Dealing with pressure-hacks

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

Life is tough, and sometimes that forces us to make tough decisions. For developers under time and money pressure, that means occasionally writing code hacks that you’re not proud of.

I’ve met some developers who think that the only reason that hacks exist is because other people are dumb. Certainly many hacks are caused by ignorance, but many are also caused by unrealistic time, money, or features constraints that pressure someone into writing bad code. The critics seem to think that if only the world were as smart as them, then all code would be perfect – just like theirs (sarcasm). Ironically, these critics never seems to have had to dealt with the pressure themselves – they can tell you how you’re supposed to do it, or how their last company (that’s 10 times bigger) did it, or what the “Best Practices” are, but they don’t actually implement it themselves.

The best way I can think of to handle pressure-imposed-hacks is to:

1. Acknowledge that it is not ideal, and identify the problems.
2. Ask if others have a better idea (that can be implemented under the same pressue).
3. Document your hack, ideally in the source code or wherever else it matters.

The first step brings everyone to the same page. The second gets others’ feedback – maybe they know a helpful trick that will make everyone work. The third reaffirms to your fellow developers that while you’re aware that this isn’t ideal and you’re not trying to hide it, the code needs to be completed and this gets it done. These steps require humility and confidence from the coder: they admit what they don’t know something, but they can be confident that their approach at least solves the problem. Ultimately the company stays in business not by the critic who points fingers at everyone, but by the developer who makes the project work – even if it has an occasional hack.

Open question to readers - what do you think about hacks due to excessive pressure? Any interesting stories?

Giving good feedback

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

Software is complicated, and we therefore must often get feedback from other people. Some people do not know how to give good feedback; they:

1. Blindly stamp it with approval - maybe they're shy, don't want to offend, or just don't know how to give feedback.
2. Point to useless details that don’t really help - maybe they don't understand how to improve it, but still feel compelled to say something.
3. Give completely impractical advice - maybe they don't know what's going on, or didn't want that feature in the first place.
4. Use it as an ego booster and try to rip the other person apart - maybe they're just a jerk. (Or, another theory: many socially awkward nerds go into software development. Perhaps they're just desperate for affirmation, and want to dim your candle to make theirs look brighter).

Feedback should be constructive and practical - it's goal should be to make something better. Here are some ideas how:

1. Do you understand what the thing is that you're evaluating? If not, save everyone time and admit that ("I'm sorry, I'm not really sure what this is supposed to do, so I can't really comment on it."). You can always learn more about it such that you can have an opinion later.
2. Point to something positive. The developer invested time and effort in what they're showing, so affirm something ("this took a lot of effort", "I like how it functionally works", "that's a nice algorithm").
3. See what you can practically improve (an algorithm, refactor it, better performance, etc...). Start with the most important improvements first, limit your suggestions to what they can handle, and make it practical.
4. If they did something poorly, and it's a touchy subject, try comparing it so something else good that they did. Compare these two feedbacks: (A) "Your first module had great performance, any way to make this second one perform well too? Perhaps we can run the profiler on it?" and (B) "This second module performs too slowly. Fix it."

Giving good feedback doesn't just help the recipient, it helps you too. You can help influence things for the better, others will respect you more, and it can be more mentally challenging (and therefore grow you as a developer).

Strings in .Net 2.0

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

Jeff Atwood at Coding Horror summarizes a lot of interesting points about strings. I especially like the new .Net 2.0 "String.IsNullOrEmpty" method.

A junior dev code-reviewing a senior dev

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

We all know that Code Reviews are a good thing, especially for a senior dev to review a junior dev's code. But it is also beneficial to have the junior developer code-review the senior dev's work:

• The junior dev see what good code looks like
• The junior dev may still catch something - even senior devs make mistakes.
• It sets a good role model - if even senior devs are having people review their code, then certainly junior devs should be too.
• It offers humility to the senior dev - If you only review other people's code, and no one ever reviews yours, it becomes one-sided, and is easy to get into an ivory-tower mentality of only criticizing other code without accepting criticism of your own.
• It prepares the junior dev to possible take over easier parts of the senior dev's code, freeing up the senior dev for other important tasks.

Certification: Pro vs. Con.

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

In the consulting world, I saw a constant pressure for devs to get Microsoft Certification. This has benefits:

• A certification implies at least minimal knowledge, commitment to the technology, and initiative to take some tedious exam.
• They're great for younger developers trying to get their foot into the door, or consultants who want to bolster a resume.
• They're good to ensure at least a general, broad knowledge
• They tell you what Microsoft and the Industry thinks is important to know.
• They're good when competing with another candidate for a job, to match their credentials. I.e. if they have certification but you don't, then it's an edge. But if you also have certifications, then it nullifies that advantage.

Many managers would point out that a certification is better than nothing, and distinguishes you from your peers. While this has some merit, I think certifications (at least the MS ones) can be overrated. Speaking as someone who has several MS certifications, I think that they have several limits:

Tests only broad and shallow knowledge, not the ability to think: A MS certification essentially requires broad, but shallow, knowledge in an area. That is important, but it has many limits. Developers need the ability to think and solve very complicated problems. Certifications don't really test in-depth problem solving.

There are other good things: Sure, a certification is better than nothing, but most developers aren't doing nothing - they're doing other constructive things:

• Reading up on other technologies
• Practicing technologies that are too complicated to have certifications for.
• Open source projects
• Extra features at work
• Their own personal pet projects
• Writing articles
• Mentoring other junior devs

These activities all can help make someone a better developer.

They can be cheated: Somewhere out there, there's got to be a black market for exam answers. Microsoft recognizes this is a problem, and wants to enforce exam security and integrity. Of course, the exams are straight-forward enough that if you need to cheat on them, you have bigger problems.

At Paylocity, any developer we hire needs to write code on a whiteboard. This quickly lets us see more of someone's thought process than a multi-choice certification exam. Certifications are good, and of course they have benefits, but they're not a silver bullet for everything.

Ideas to be a better developer

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

Here are some practical ideas to become a better developer. Of course people write entire books on this stuff, but here’s a brain-storming list (and that’s what blogs are for =)

1. Budget your job on an eight-hour day. Deliberately planning for a 12 hour day will just spin you into a downward spiral by burning you out, preventing you from learning new things, and constantly make you feel behind. Ideally try spending any overtime doing optional exciting learning or experiments that energize you (or improving code that already functionally works), not required features that just burn you out. If a feature does take longer, make sure management knows that, i.e.: “This is a 5 day feature, but I’ll work overtime to do it in 3 days.”

2. Get a blog aggregator, such as SharpReader or RssBandit: http://sourceforge.net/projects/rssbandit/. Then spend at least 10-20 minutes a day reading blogs.  This will give you a pulse on the community, alert you to new techniques, and introduce new creative solutions.

3. Keep a kudos list of positive things you’ve done. This helps build confidence (“I have done positive things”). This prepares you for a review. This is a service to management because it helps “jog their memory”, and management already has enough stuff to remember. If you can’t remember the good things you’ve done, why will anyone else?

4. Do incremental checkins, especially when working on a critical path. This results in much lower stress. Two small changes are easier to integrate than one big one. Check in what is needed to make sure you’re not blocking anyone, especially if you’re on the critical path. Ideally try to check in at least once every other day.

5. Think beyond your current feature. With each feature, try to make at least one reusable component/utility that improves the project as a whole. For example: reusable logic for the application’s framework, a global UI component, refactor an existing component to make it better, or make reusable validation/formatting logic. This will give you stepping-stones (and positive reputation) to do bigger experimental components.
 

What to do while waiting for a batch process

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

Sometimes you'll have local batch processes that block you from development while running. For example, you may have a 20-minute checkout script, a set of longer tests, or a long-running analysis tool. While such tools have benefits, developers are reluctant to use them because they don't want to be blocked from developing. However, there are many constructive tasks you can do while a process is running:

• If you can choose when to run the process, then kick it off right before you leave your machine:
  • Lunch
  • Meetings
  • Breaks
  • Any legitimate reason for being away from your desk.
• If the process must be run at a certain time, then you can still do constructive activities while it is processing, like:
  • Design out the next task (read the spec, think out the code, etc...)
  • Catch up on technical, work-related, blogs. You're still using your computer, but the bandwidth is minimal for this kind of reading.
• Of course, you can always kick off the batch off the clock when you're away from your machine, such as before dinner or even overnight.

The idea is to multitask - the batch process runs in the background (doing useful things that benefit you), and you're still actively thinking in the foreground. It's the best of both worlds.