Non-leaders

So I've been having a bad day.  Wake up to a bunch of work bureaucracy bullshit - web forms that do not have working links, Satanically bad UI design, a ton of 'jobsworth' types telling me I have to do X, but not providing anything other than links to 47GB of text and no pointers.

Now the project that the team is supposed to be working on together is cobbled together by a guy who does not provide a working build script, has both JSON and XML format config files, and so on.

I/m fucking furious

Bad API behavior

Ok, so we were running test code yesterday evening to get some data for a presentation, and there was a typo in a text string that a downstream system didn't like.  So this morning I get angry emails about the "bad data" and have to roll back the changes.

But what really pisses me off is that the downstream system was coded to expect exactly certain strings in that field, and if the contents did not match, IT FUCKING CRASHED.

This is not good software design.  It can complain, log errors, ignore the messages, all sorts of annoying things, but it should not, EVER crash when it can easily avoid doing so.

The Perfect Office

Screw open plan offices.

They suck in all ways.

The ideal office plan has individual real offices for each developer -walls all the way to the ceiling, real closing door, etc.

Each cluster of 3-7 offices opens onto a common space with a few tables and whiteboards for group work, etc.

Several clusters all share a common kitchen space, where at least once a week there is a company-paid lunch.  Access to the cluster space is only through this common space, so you can get the (limited) benefit of people mingling for "collaboration", and the common free lunch means people will see other groups from time to time, and trigger any serendipitous synergies.

Adjustable sit/stand desks in each office, at least 2 large whiteboards in each office (Minimum 10x10 ft space).  Two or more monitors, wireless mouse and kayboard.

Logging advice

Ok, an actual post about doing things right, instead of me venting my spleen.

So, let's talk about logging messages.

When writing logging messages for technical use - monitoring, statistics, etc, pick a separating character that is not part of the various fields you have interest in.

For example, most log messages will include a timestamp, so use of ':' is out.  Likewise, if the timestamps include the date, the '/' or '-' is right out.

A good choice for the field divider is the '|', and then the use of spaces as separation of the subfields.

It's the goddamn 21st century....

Why is someone declaring a message string with only 256 characters on a server-side program?  I mean, we are running on systems with hundreds of gigs of RAM, and it's for a freaking LOG MESSAGE, local variable, on the fucking stack.

But 256 characters it was, and  we decided we wanted to log a command line for a Java program, so between the log4j path argument and the Java binary path, it was 270 chars long, and it stomped on the stack, leading to a premature exit.

The Mismeasurement of Code

Christ on a crutch.

My PM is suddenly gung-ho on getting measurements for "KPIs", and beaing able to "get ahead of things" when event volume changes.

Never mind that speaking up gets everyone and his brother pointing fingers at you for their problems, even when it's someone else in the middle who has screwed up.  The corporate mindset is such that whoever says they have a problem is suddenly the cause of the problem.

Never mind that we have a cient to who *not* in production, but acts like any small time out of service is like the Fires of Hell are burning their ass and it's all your fault.

Been sayin that for years

Just read an article in the PyCoders weekly list about refactoring functions to have multiple return points.

The article is well-written, but I was floored by the need for it.  I've been an advocate of multiple return points for 2 decades.

The only reason to hold to a single return point in a function is to guarantee release of resources, and every OO language has had a means to do that with a local variable and destructor for over 25 years.

Multiple return points make the logic clear, handle special cases better, and allow better refactoring later for all purposes.