Musings on IT and programming

 Sometimes you create a system that faces directly the end user and produces value on each interaction, sometimes it is something that is deeply buried in the back end but still has direct business value by performing actions directly involved with the value chain, other times it is a support mechanism that helps monitor either the business or the infrastructure and other times it is something that is so low level that it does not have a direct business impact but if it were to fail it would bring the business to it's knees. All of these systems have their own characteristics and way of life, what works on one of them might completely break another one. Also talking about some of those can be made almost naturally with somebody outside of the organization as is evident what they do; on the other hand others can only be understood by individuals that have in depth knowledge of the field where those systems are meant to live. It is very hard to draw the line where one type of system

This is a rant coming from my latest interviews. In the past I wrote about my approach to interview candidates for developer positions, I must apologize as I used to be really hard and harsh while doing so while also focusing on not the best qualities; this was almost 10 years ago. A few years ago I saw my practices change completely and start asking different types of questions and looking for different kind of things with better results and was able to build a very strong team. Currently I've been on the other side of the equation and even though multiple houses have also changed the way they do interviews I still see some of the practices that I'll try to avoid.  I understand the need of the hiring manager to assess the qualities of the candidate and also I understand the pressure and frustration from the interviewee as it is required to iterate, sell ourselves and also prove that required qualifications are met. Interviewing is hard on both ends and can be exhausting, both

 There are books that set themselves apart and this is one that definitely marked my path as a developer. This is one of the first things I bought from Amazon, it popped on my recommendations just a few months after it was published and it is one of the best things that landed before my eyes. It covers many topics and was a very good insight on how software houses (and not only game development one) operate. It teaches about software development process, software design both in micro and macro, some common personalities that arise on projects. For the most part it was a really fun intro to what being a software engineer and later a software architect means. This book alone made spend a lot more on "gaming books" which were actually very good general programming reference material. Product details Title :  Game Architecture and Design: Learn the Best Practices for Game Design and Programming Publisher ‏ : ‎  Coriolis Group (November 18, 1999) Language ‏ : ‎  English Paperback

This is an interesting trip to memory lane on 2002 era of software development in Mexico. In retrospective this particular environment molded my mind towards always finding ways to improve developer productivity. Memories from 2002

 On 2023 It would be really rare to have to create a new program that does not have distributed characteristics. But I guess this has been like that for a couple of decades and we have been using the same concepts by different name and using different techniques to solve the same problems. Even on the now called monolith systems there we were using the same concepts either consciously or forced upon by the restrictions of the technology. Take for instance the basic design patterns used in software like the Gang of Four (GoF), they used to be the bread and butter of everyday developer talk while discussing at the lowest coding level. But the same concepts have been applied at system, enterprise and beyond with some caveats. The important part is that patterns emerge and become common language for multiple organizations. Independent of the technology used these patterns arise and get implemented over and over but the concept remains stable. There are patterns that are easier to implement

  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