Musings on IT and programming

  Learn your everyday tools, they will free you up a lot of time and will give you an edge to become faster and better with time. For example Integrated Development Environments (IDE) have lots of quick keys for everyday use and most blogs reccomend memorizing the most used ones. I'll go on a different route for my suggestion with a little of backstory. At my first job near 2002 most developers were using very crude tools as the workstations available to us were not powerhouses and most of us were pretty new to the industry so we didn't know better.  The workflow mostly involved using a plain text editor on local Windows NT, upload source code to a Unix server, compile and possibly restart a server in order to load new code. As you can imagine this was brittle and there were multiple places for collissions either by overwriting somebody else's code, restarting in the middle of another developer test or plain corruption of compiled binaries. The first thing that we started t...

I've found some things that I simply refuse to work without. Public, Centralized requirements visible to all parties involved. I is ridiculous that we still don't have such repository of information available,  there is not a sane way to assign an identifier to the requirements. Then we go with the 'it is all on Microsoft Office documents' hell which are not kept up to date and which prompts my next entry. Version control. When we arrived here quite a lot of groups were working on windows shared folders... now it is a combination of tools but heck at least there is now version control. Controlled environments and infrastructure. Boy... did I tell you that we are using APIs and tools that are out of support? Continuous deployment. First time here, to assemble a deliverable artifact took 1-2 human days... when it should have been 20 minutes of machine time. And it took 1 week to install said artifact on a previously working environment. And some other things that ...

I'm not against of leaving a trace log of everything that happens on a project what I'm completely against is filling documents for the sake of filling documents. Some software houses that are on the CMMI trail insist that in order to keep or to re validate their current level they need all their artifacts in order but what is missing from that picture is that sometimes it becomes quite a time waster just filling a 5 page word document or an spreadsheet which is just not adequate for the task needed. Perhaps those artifacts cover required aspects at a high degree but they stop being usable after a while either by being hard to fill on a quick and easy manner by someone with required skills and knowledge or they completely miss the target audience of the artifact. Other possibility is that each artifact needs to be reworked every few days apart to get some kind of report or to get current project status and those tasks are currently done by a human instead of being automated. ...