Eclipse has three task tags built in by default.  A TODO tag, a FIXME tag, and an XXX tag.  When you see a TODO tag in a comment, you know that something still needs to be done.  The FIXME tag is a more serious problem that should be addressed right away.  The XXX tag–well who knows what it means, but I think somebody failed to think about the name they are using.

Even though Eclipse defines several task tags for you, you can use whatever task tags you want.

There are several that I find very useful:

• TODO:  Marks something that still needs to be done.  Lots of people use this.

• TRICKY: Marks a section of code as a tricky part of the code.   When you come back to the code, you will quickly see that you don’t want to mess with the code unless you know what you are doing, or you could mess things up pretty badly.

• HACK: Marks a section of code as being a hack.  Though everyone tries to aways write perfect code, sometimes we end up hacking things together to meet a deadline, or simply because it is easier.  We then go on with our lives and the hack remains in there forever.  Marking these sections as a hack makes it obvious that there is a better way.  In fact, whenever I put in a HACK tag, I try to also include what I would have done had I had more time to work on it, so that the ideal solution is clearly marked.

• BUG: This is maybe similar to the FIXME tag built into Eclipse.  I put these in my comments if there is a bug that I know about in it.  Obviously, these should have a high priority for fixing, because they’re a known bug.  For various reasons though, sometimes they don’t get fixed for a long time.  Perhaps it is a bug that is rare to see in normal use of the program.  When a developer does finally get around to fixing the bug, if there is a BUG tag there to indicate what might be going on, it helps them quickly get up to speed with potential problems with the function.  Of course, good unit tests will keep these kinds of bugs in check.

Perhaps you have your own that you use.  Please share your ideas in the comments!

The site is primarily for web designers, but it just goes to show you that the customer isn’t always right.  Sometimes, clients and users have no idea what they really want.  Or worse:  they think they know what they want.  I think it is important to remember that you are in this field for a reason.  You know what works and what doesn’t.

To drive this point home, here’s a link to a prime example of this.  This is a committee of people trying to design a stop sign, which was featured on Today’s Big Thing: http://www.todaysbigthing.com/2008/07/23.  Seriously, you’ll enjoy it.  And you’ll never forget that your clients don’t always know what they want, or, more importantly, what is going to make the program the most useful.

It is seriously worth watching out for this, or you may hear what one client on Clients from Hell said: “Oh, no!  You did what I asked you to do!”

The screenshot below shows Dependency Walker in action:

The program is extremely easy to use.  Just browse and find your DLL and load it, and it tells you everything that tries to get loaded after that.  Dependencies that don’t exist (or have some other problem) show up in red.

It is one of those nice utility tools that I wish I had known about a long time ago.

1. Technical Writing Skills

Technical writing involves writing about technical products (what you make in the rest of your time) to a non-technical audience.  The prime example that comes to mind is a User’s Manual.  Some of the larger companies have their own team of technical writers, and if you work for them, then you won’t need to worry about this.  But many other smaller companies assume that their programming team can produce user documentation like this, often without even bothering to check to see if they actually know how to do it first.

Obviously, technical writing will involve knowing proper spelling, grammar, and punctuation.  In addition, it requires you to be able to take all of the technical junk that you know and explain it in a way that your users/readers will be able to understand.  As people who know the technical world so well, it is difficult for us to comprehend that our users often don’t understand the difference between a browser, the Internet, and Google.  Another part of technical writing is in understanding how people will be using your writing.  For example, with a user’s manual, few people are actually going to read through it from start to finish.  Instead, they’ll go to it when they run into trouble.  A big part of writing a user’s manual is in learning how to structure the document so that these users who have come across a program can quickly find the solution they need.

2. Presentation/Public Speaking Skills

Let’s face it, we’re all at least part nerd.  You have to be to survive in this industry.  Nerds, unfortunately, don’t have a reputation for good interpersonal communication.  This is another area that all developers should conscientiously spend time working on.  At some point (probably frequently) in your career, you will be expected to present your ideas or your work to a group of people, such as your team, upper management, potential clients, or shareholders.  In these events, the quality of your speaking and presentation can cost the company both financially, which in turn could mean people losing jobs (maybe even you).

In many cases, for such high profile meetings, the company will usually try to find someone capable of giving a good presentation, but in some cases, your detailed tecnical knowledge of your software will be more valuable to the presentation than whatever public speaking skills another person has.  Now, if the people you are speaking to understand that you’re a developer, not the company’s PR specialist, they’ll likely be fairly forgiving.  It is still important, though, that you can do a good job.

By the way, good public speaking skills during an interview will set you apart from other applicants in a significant way.  You will get hired if you could present yourself clearly to the interviewer, while another person had better technical skills, but was unable to clearly explain it to the interviewer.

3. Artistic Skills

OK, no one expects you to be able to paint like DaVinci.  That takes a lifetime of practice, and a good eye for art.  If you were that skilled at it, you probably wouldn’t be in a technical job.  However, having a basic set of artistic skills can significantly improve your program.

I remember in college, along with virtually everyone else in the department, making fun of all of the “easy” majors like art.  (I mean, what are they going to be able to do with a degree?  Teach?)  After all, we slaved away all weekend making programs that could solve mazes, while our roommates ran around partying.  (OK, it was Utah.  The partying probably wasn’t quite on par with what might have been seen elsewhere, but still….)

What came as a surprise to me was as I was nearing the end of my schooling, I suddenly began to feel really lopsided.  Like my left brain had grown to epic proportions, while my right brain had shriveled to the size of a pea.  I felt a need to balance all of that computer/math/physics stuff out with some art.  (Let me set the record strait, though.  I would definitely not call myself an artist by any stretch of the imagination.)

The point is, having some basic artistic skills will help with your programs in many ways.  Knowing what colors go together well will help in a GUI.  Being able to produce stand-in artwork for your program will help it feel more professional during the development cycle.  I’d bet that a fairly significant amount of stand-in artwork actually ends up in final production anyway.

Having some artistic skills will help your program in a number of ways, and it will help you be a more rounded person as well. 

I realize that as a developer, you have a lot of things to learn and work on.  If you can’t keep up with the changing requirements of your job, you’ll soon lose it.  These skills, while not technical, will make you much more valuable as a developer, and the best part is, they won’t go obsolete (unlike that time you learned J++).

Are there any other non-technical skills that would be helpful to developers?  Leave a comment and let us know!

Being a guy, my initial interpretation of pads is, well… not what a woman thinks of first.  But now that I have heard about it, I can’t help but think about it.  I would venture a guess that most women would think of this as a pretty poor name for a product.  The fact that #itampon is a trending topic on Twitter is proof.

Now, I don’t think that the product name is going to kill Apple.  They might feel some effect from it, but in the end, probably not much.  They’re lucky.  They’re a huge company with a pretty high reputation, and they’ll likely do well, not because of the name, but in spite of the name.  Few other companies could pull this off though.  With the small company that I work for, this would likely kill us off.

So my first reaction is to think about what led them to this name?  I’ve heard some people say that they must not have thought it through very well.  I seriously doubt that.  I’ll bet they had many long meetings discussing the name, and chose it from a large collection of other names only after a great deal of thought.  If Apple is like much of the rest of the technology industry, then there is unfortunately a very small number of women there.  Had there been a few more, they could have avoided this disaster.

Apple isn’t the only company to create not-so-perfect names.  In the past, I worked on a program whose name had to be changed because it was already taken.  Instead, our company chose an acronym that unfortunately sounds way too much like a game from EA.  Anyone who I told about the program immediately asked “oh like the game?”  Our boss doesn’t seem to be too interested in changing the name before it is too late.

This is only the beginning of the list.  Many companies have made mistakes like this.  Don’t let it happen to you.  You may not come out of it as well as Apple will.

So the important thing to discuss is how to actually come up with good names for software.  Here’s a few suggestions that I have.

1. Tell as many people about the intended name as possible.  Tell your spouse, tell your friends, and above all, tell a pessimist and a cynic.  See what their first reaction is.  The focus should be less on sheer quantity, and more on variety.
2. Google it.  Or google it with Bing.  Whichever.  The point is, the name may be taken, or it may have a meaning that a team of nerds didn’t realize.  (Yeah, we aren’t all nerds, but, I’ll admit it, I am.) Failblog is full of dumb product names that could have been avoided with a simple web search.  And let’s be honest, if Apple had done this, they likely would have found MadTV’s iPad spoof.
3. Don’t decide on a product name overnight.  Spend the entire development cycle of the program deciding.  You don’t need a name until you are ready to start marketing or making big announcements.  I realize that there is a desire to put an interesting title at the top of your program besides “Form1″.  And you also want to be able to discuss your program without needing to say “the program that does ____”. Many companies use code names for their projects.  I’d definitely recommend taking advantage of project code names to give your team or company plenty of time to brainstorm and explore plenty of good ideas for the final name.

What interesting things does your company do to help pick creative (and safe) names for your software?  Leave a comment and let us know!

Of course, the problem is, I have over 100 source code files, and somehow I need to get them into a Word document.

Solution: batch file.

I’m sure many of you know your way around a command prompt.  So I guess my point with this post is not to say “you all ought to go learn how to use a command prompt” but rather, I guess I’m just trying to say aren’t batch files cool?!

Batch files and command prompts give you quite a bit of power.  It is something that I think many of us forget easily.  Or at least I do. 

So here is my sample code, which takes all of the Java files in a directory, and combines them into a single output text file, separated by the contents of another file (separator.txt) which in my case contained the text “/*REPLACE ME–REPLACE ME–REPLACE ME*/” so that I could go through and replace all of them with page breaks once I copied and pasted the output file into my Word document.

I want to discuss an important tool that can help development teams improve as they move from project to project, or to a new version of a program: A post-mortem.

In the real world, a post-mortem is something doctors will do after a person has died to determine the cause of death.  This is often called an autopsy.

While, hopefully, most of our projects don’t die, there is great benefits to doing the same kind of process for our software projects, once it is over.  The goal is to review what went well in the project, and what didn’t, and analyze how to keep doing the good stuff in the future, as well as how to fix the bad stuff in the future.

I would break the post-mortem into the following steps:

1. Plan for it.  Set up a meeting for it, and let everyone involved know they are expected to contribute.
2. Hold the meeting.  Depending on the size of your team, you may have the entire team meet, or just the key people, such as the QA lead, the lead developer, the project manager, and so on.  Have everyone share their ideas, and make sure someone is taking notes.  Pay special attention to the things that come up more than once, or that everyone seems agrees with.  These are either the things you did really well, or the things you did really poorly.
3. Write a Post-Mortem Report.  Take the list of things you discussed, and create a report about it.  Make sure everyone on the team gets a copy of it, and that they read it before getting underway with the next project.  This allows everyone to make the changes needed to do better on the next project.

Post-mortems can be a huge help to improving the quality of software you produce, and streamlining the way your team works.

I found myself needing this kind of a thing today when my application would execute just fine, but when the designer was trying to display my form, it would crash, forcing me to manually type in GUI code, or use other less efficient hacks to make my application.

I discovered that there is an extremely simple solution for doing this, and it is useful enough that I think all programmers who use Visual Studio ought to know how to do it, or at least, that it exists.

The following piece of code takes care of this:

I have to say that while I can’t completely agree with him, console windows are often black windows of death indeed. 

There are occasional times where a simple console window solves the problem quickly and effectively, and there is no need to do anything more.

But let’s face the facts:  only computer people will know what to do with a console window.  A “normal” person (as in not a computer person) will not have the slightest clue as to what to do with your console window.  If you are the only one using it, you’re fine.  If only other tech-savvy people use it, they’ll probably be able to handle it as well.  But as soon as a normal person is supposed to use it, they’ll be staring at a black window with no clue what to do.

There’s no excuse for sticking a user with a console-only application.  GUIs are so easy to make these days in programming languages like C# and Java.

So, while there may be times where a console window is the ideal choice, you should at least consider throwing together a simple GUI instead.

If there is some sort of real value to a console-based app (scripting, for example), perhaps you could consider the option of providing both a GUI and a console/command-line interface to your program.

Image Source: codeoffsets.com

Bad Code Offsets, they’re kinda like Carbon Offsets. The announcement of the project essentially says “bad code is lame, let’s collectively work to guard against it”, only, it’s being marketed better. Today’s update on the project announces how much money has been raised, what projects are getting what money, and how you can get $500 for your own project!

Check out the project’s home page to see find out more about it and see how you can buy bad code offsets.

Personally…. I think I’d rather just buy their T-shirt. I mean, you’re contributing to the project all the same – but you get to both flaunt it around the office on casual Friday’s. But, since you might keep your offset stocks mounted in a frame in your office for your co-workers anyway, the advantage of the T-shirt is that you can flaunt it at your local watering hole. Oh, and did I mention their logo is awesome?

I mean, we all write bad code and  need clothes.  The next time I have a few bucks to spare, I’m totally gettin’ me a shirt.