coder . cl

Currently programming have three main perspectives, it is seen as art, as craftsmanship and engineering. No matter how structured and hard is your development process, you need to be creative as an artist, and detail oriented as a craftsman. Software engineering just defines the development process, and there are many components related to Computer Science that are being used by the engineering process and programming tasks. No matter what is your perspective regarding programming, the fact is that you are stuck in the marketplace, and you will not work on the projects that you like if you have a low work performance.

As you know I am the main developer — and unique developer, I hope more people will be interested in the future — of the pyxser project. It has a very specific purpose, but it is the only stand alone Python Object to XML serializer that exists. There is also the serialization routine built-in in the lxml extension. The project is hosted on Source Forge, not popular as Git Hub does, but it is a well known project hosting site. The fact is that it is linked from sites and recommended along the Internet by some people. It provides a nice serialization model that allows you to standardise the XML serialization.

Communications are a key element on any software development project. It implies the right understanding of requirements and related artefacts that are used along the process of software development. Is important to have a common language, because it can lead to well developed software, for example reading an architecture specification, where is required for example to have a good knowledge on design patterns if that architecture based on object oriented programming. A good knowledge of the platform is required too, so everyone in the project can easily identify each project component once someone refers to any of them.

The most dangerous project proposal is that project where the schedule was not made using well known techniques. For example I use PERT, on the company where I was working — before I become a freelancer — was using PROBE. There various well known techniques that you can use, but if you start hearing phrases like “the feature is required to be implemented at October 28th”, your own time is at risk. That schedule that was not set using PERT, PROBE or any other technique, and it is just a whim to get the things done for certain date, probably will lead you to work overtime. If you hear phrases like that, and the schedule is not justified by a well documented schedule, probably it was a whining requirement by any manager on the hierarchy.

Why should we tolerate bad programmers?. Probably that is the worst decision to make while you are working for something called “good company”. How many times you find yourself doing monkey patching because there is a sold product that must be delivered at time, but the scheduled time was wasted by a bad programmer that was introducing bugs, or simply writing code that should be honoured with a submission to “The Daily WTF”. Seems that bad programmers are everywhere, and they have two options I think, they learn and continue their career as programmers, or they simply fully leave all programming tasks to real programmers and people who really enjoy programming.