I know I'm not the only software developer on this forum, and I thought it might be nice if we had a thread where we could vent about some of the vexing issues we are faced with occasionally.

Does one of your coworkers consistently neglect to comment his Subversion commits? Is one of your in-house development tools a buggy piece of shit? Is there some seemingly simple task that your development environment makes you jump through several unnecessary hoops to achieve? Come in here and tell us about it! Together we can... Well, together we can agree that it sucks, but maybe someone can occasionally also offer an insight to make it a little easier to deal with.

I'll start off.

Why is it that seemingly every Microsoft program except for SQL Server Management Studio has a file auto-recovery function? If Word, Excel, Powerpoint, etc. crashes with unsaved changes to a file, the next time you start it up, Presto! "We've recovered these unsaved files, would you like to restore them?" "Not really, it was just my shopping list from yesterday, but thanks for asking."

However, when you've been debugging a complicated service for two days, and made a gazillion complicated queries to compare two sets of data, in order to find out what's being saved wrongly to the database, and your SQL Server Management Studio suddenly crashes, what do you get on the next startup? Nothing whatsoever, that's what. "Oh, you had several hours of unsaved work in there? No, sorry, we couldn't be bothered to include functionality we've already developed in this expensive professional development tool. After all, SQL code is plain text with no special formatting, which is obviously much harder to recover than the proprietary over-complicated file formats used by our range of other programs." Microsoft, sometimes you suck!

There, that feels better :-)

we need to create a thread where we can nagg man, i have so much nagging to do.

Which version of SSMS are you using ? Because at least 2008 and 2012 have an auto-save option ("On" by default) :

c:\Users\<user>\Documents\SQL Server Management Studio\Backup Files\Solution1

It's 2008. So what you're saying is, it does actually auto-save all files to some weird location, it just doesn't inform me of the fact? Damn... Well, I'll definitely look through that folder tomorrow at work.

Yay! I'm glad I made this thread now :-D

Right, I've started using KDevelop, which is utterly brilliant, except I can't for the life of me figure out how do you locally store your github password and username, and so I can't push my commits via the interface and have to use terminal to do so.

The worst bit? The IDE even gives me the error, "No username entered" or something like that, but the darn thing just won't prompt for it. How hard is that!? And seriously, how's that a 'full git support'?

It does tell you........... just not always :). it's pretty random.

That's to keep the feeling of suspense :-P

Ah, you mean like the "remember password" checkbox that only works every other time, and has done so since SQL Server 2000?

Use a private/public keypair, easier in situations like that. I believe github allows this.


Here's mine, why do we still rely so much on IRC and email lists in our industry. They are pretty bad at preserving content for future reference. In a perfect world some guru would come along and wiki-fi all the discussed items in blog posts and/or a wiki. In reality, I'm going to be slogging through IRC chat logs on the off chance I can figure out a grep that brings back what I need (which may or may not be easy).

Also, when you write examples, and you're trying to impart knowledge of how to use a library, think of scaling, saying "this is how you do a SOAP call" is all well and good, but in real life some people need to know how you do a SOAP call when the response is 1GB of data. Scaling people!

Also, the no comment thing (or using "." as a comment) pisses me off too, one time I had to harangue my then tech-lead into putting in comments. Guess who the biggest commiter of code that broke the build was...

Our internal commit message rules are:
1. you can use any message you want when you commit to your own repo/branch;
2. when committing to the integration branch you must respect a pattern (usually [bug_number][component_affected]short commit info - newline - full description of changes made)
3. when committing to the main/production branch you use the same pattern as 2 + code review url (we use CodeCollaborator for that)

If rule 2 or 3 isn't respect the reviewer mustn't merge the commit to the branch and close the issue. This keeps things clean most of the time, unless you need to pull something from a developer repo/branch.

---

As for me bitching, I recently had to deal with a bug opened on the component I'm working on because a dependency written by another team does its work in the UI thread, which means it can get canceled at random either by the user or by other threads and my code stops executing.

It was so much fun trying to diagnose that thing, especially since there's no set condition that causes my component to stop working.
I think it's more force of habit. At work we have dedicated wiki's where things are being described and explained, though at times the info in them can be outdated or not that helpful, but it still beats going through and digging through emails to find some piece of information. The wiki + commit messages + component release notes = things get pieced together easily and fast.

As for outside, most of the stuff happens on GitHub for me where the issue tracker and wiki and commit logs/pull requests hold all the info needed. I mean, sure, we talk things on IRC and propose changes, but it isn't official until it gets written on GitHub.

Look, when you provide something that can be used to do something, write some damn documentation about how that something works, and save your users the trouble to pirate some random books or decompile related stuff, just to get the general idea of how that something works.

Running a particular game in debug mode and then figuring out each damn API call through trial and error isn't really addon making friendly and productive. :/ Or reading random stuff on the Internet and hoping that random stuff makes the game do what it says that it does without crashing or dying.

Same goes for release notes. When you update your software and only write "fixed some bugs" with no additional information there are high chances that I'm going to uninstall your application.

It's sad to see big corps do it (seen it done by Google and others), but even worse in my book when small devs make this mistake and don't get smacked down for it, because when they'll grow up they'll continue to use the same shitty release notes with little to no valuable information in them.

Oh yes, it works now, thanks. Now I can commit like a noob via graphics interface!

Watching my skills wither while only maintaining VB6 code.