I have been working with a team of 3-6 developers for quite some time. Recently we moved offices and ended up sitting around a big round table; and our productivity went to hell as a result. It didn't take very long before the team scattered, with many people working from coffee shops or home, and the remaining devs claiming vacant desks.

The problem is that development is done in two phases: You work with others to develop a plan, and then run off and get into "the zone" and get stuff done. The problem with "the zone" is that it is very fragile, and so all it takes is hearing two devs laughing about something through your headphones and now you aren't working either.

In other words, putting all the devs tightly packed together all day means that every time one dev is distracted for any little reason, suddenly they all become distracted.

If your dev team is important to your company's product and/or revenue, do everyone a favor and give them each an office with a window, as well as a common room to "hang out" in when they need to collaborate.

A bunch of volunteers fixed a lot of the big bugs, but because there was no developer that could make the commitment to be the maintainer of the port, they decided to drop support. If you checkout the source and install two little C libraries into /usr/local, you can still compile and run it on OS X.

There are also a few people that are distributing their various OS X compilations. I seem to remember that near the end of the tt-forums thread on the dropping of Mac support, there is a link.

The one thing that stuck out to me about this post was your suggestion of using Excel to do scientific computations. As a physicist and a software developer, this idea sends (bad) chills up my spine. I have seen so many real-world engineers struggle to make Excel do what they need (rather for computation, data analysis, or data plotting), rather than spend a weekend learning how to use a much better tool.

Somehow, learning to use Excel to solve your problems ropes them in so that they just continue to use it to solve their problems, no matter how difficult it is for them to wrangle Excel into doing it. Excel is a *financial* program that MS had added some scientific functionality to in order to sell more units to naive individuals who were never taught that there was anything better.

You talk about calculation packages, so I'll start there: If you want a calculation package, you could look at finding a freeware alternative to one of the big computing programs like MatLab, Maple, or (for more symbolic kinds of math) Mathematica. There are a number of ones out there. Alternatively, you could just as easily teach them how to do calculations in a programming language like Ruby or Python, so that the knowledge they learn will set them up for using a real programming language later in life.

That all being said, I'm not sure that Chemistry class is the best place to be teaching a computer course. There is plenty to teach in Chemistry that can be made interesting via hands-on experiments. Additionally, it is important to build the paper and pencil skills for each empirical law, before one can write or understand any (even simple) program that will aid in their calculation.

However, there is one place where I do think a computer is helpful: processing experimental data and plotting. Again, Excel is a horrible choice for this! There are a number of ones that are useful for students, such as DataGraph for MacOSX. These need to be able to take a columns of data, create new columns that apply formulas using previous columns, and *scientifically* plot the data, complete with real regression curve fitting and even error bars. This may sound similar to Excel, but it is not! Excel's plotting engine is written for financial applications, and produces awful quality scientific output. (Indeed, I've had college professors that would not accept any chart formatted in Excel!)

Probably because there are a *LOT* of people, many of them Slashdot readers, who don't understand what the GPL actually does, because they go off of all the weird touchy-feely "spirit of" misinterpretations rather than reading the text of it themselves.

This post serves as an excellent illustration of the surprises some naive developers can get when they make this mistake, and as a caution for other developers that have the same naÃve misunderstandings.

In other words, this is an education campaign for the readers of Slashdot. :)

Software is part creativity (e.g. design, architecture, misc problem solving) and part busy work (e.g. filling out methods and entering domain table data). Some people are better at one part or the other.

Personally, I find that the busy work part is straight forward and easy, requiring no brain thought, but is also boring and unmotivating. To do it, I just have to buckle down and start filling things out line by line, data point by data point, method by method, taking frequent 5 minute breaks of doing something fun to keep from getting burnt.

The creativity part can be tougher. When there are problems to be solved and the creativity stops, what do you do?

The first thing I do on *any* project is break it into a bunch of modules, and then break those modules into their components, and so on. I can then outline the behavior of each piece, and usually that is enough. Like I learned form "What About Bob?", baby steps often helps.

Sometimes, however, (or often, if you are me) a problem will need real thought. The problem is complex and the solution isn't a straight forward application of the design patterns you already know. It can take a lot of creativity to work through these. In cases where I feel stuck, there are a few things that often do the trick for me:

1. I find *someone* to talk it over with. The more they know how to code, the better. That being said, often just having to explain the problem to anyone that will listen will be enough to clarify what the problem really is, and the solution will dawn on you.

2. In the complete absence of a willing participant (and if you feel stupid describing it to a teddy bear), write out an outline of the *complete* problem, and a first stab of how you might be able to solve it. Then write what is wrong with it. Repeat.

3. Sometimes the issue is that you are in a stale environment. I've had times where I sit at my desk all day and can't get anywhere on a problem and cut out early from frustration, just to find that the solution comes to me while driving home listening to news radio. In other words, sometimes going for a drive or a walk--some place where you can change environment and relax and think about nothing--is enough to make you think. :)