Skip to main content

Survey

Some months ago I read an article which said programmers usually do their hobby projects much better than their working projects. There are several reasons like time-pressure, predefined set of useless tools and pointless procedures, rubber specifications etc.

I've made a little survey about that. Do you feel sometimes it would be better to be a shepherd somewhere on a sympathetic highland in, say, Scotland and to forget all office crap? Or do you arrive at yor workplace every morning that you know you will change the world a little, of course in the right direction?

The survey is here at the right. Thank you for giving an answer if you did.

It would be nice to know the distribution of the answers by several categories like programming languages, destination environments, open source and commercial projects, speciality of the projects (banking, science, administration, telecommunications, entertainment, web/publishing), however, this simple survey is not capable for that.

But I have some opinions. It's apparent that open source projects are cooler than commercial ones. Scientific and academic projects must be also nice as they can have much more time for research and development than, let's say, outsourced banking projects where contracting party is generally absolutely disinterested in the question of nice, reusable and well-unit-tested code in contrast with delaying the payment for the software. I don't know what is the situation between programming languages but I think C or C++ programmers on embedded devices make a much more precise work than Java programmers at enterprise projects. Lower-level programming languages need more enthusiasm, higher-level ones are more popular which implies broader distribution in the level of knowledge of the programmers. But these are just thoughts...

Let's see the results at 1st of July.

Comments

Popular posts from this blog

Client's transaction aborted

I've met the above error message using a Wicket 1.2 / EJB3 intranet application under Glassfish v2 . Here is the more particular head of the stack trace: javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:3394) at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:3274) at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1244) at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:195) at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127) This exception raised on the integration server sometimes, randomly, for simple page fetch operations. After pressing reload on the browser, the operation was usually successful. I couldn't reproduce the failure on the local machine where I regularly restart the app server and...

jxl.log

In an intranet production environment we have running a Glassfish v2 appserver with several J2EE applications which all use JexcelApi , a.k.a JXL, which is an open source library for accessing, generating or manipulating Microsoft Excel documents. We use version 2.6.3 of JXL because it's the recent one in the Maven repository which we use, however, at the official JXL site there are newer versions. Additionally we have log4j and Java Commons Logging (JCL), ignoring Glassfish's JSR-47 Java Util Logging (JUL) facility. Application #1 uses purely log4j and gets its log4j.xml config from a custom location. Application #2 runs Java Commons Logging with no explicite configuration file given, so JCL uses the default JUL facility of the appserver. Application #1 had been running for a long time without problems but when we installed #2 we realized that a jxl.log file had been created in the glassfish/domain/domain1/config directory and it's rapidly growing. As it happens, we ...

Standup

Recently I was asked if it makes sense to do standups. Is it just a formal waste of time? Wouldn't it be more useful to spend the same amount of time by actual work? This is how our standup looks like, this is how the work would look like without it according to me and this is why I think it's worth doing standups: Standup optionally starts with a half-minute long announcement by the Scrum Master if somebody is missing and when will be this person available again. Without standup:  We could check out this information from a well-prepared shared calendar but unexpected lates or illnesses which are missing from the calendar would require a little bit more communication and irrelevant discussion during the day. It would cause some delay for sure. Then we look at the burn-down chart of the sprint and to the status of the latest nightly build. Is it stable, what about automated tests which were run last night? We make a common standpoint in one minute which is clear a...