Hidden Figures

In the movie called "Hidden Figures" directed by Theodore Melfi I could see how things were in the 60's. At that time there were a lot of racism, so much that even the laws promoted it. I think it's unfair that, for the simple fact of being African-American, people have had to go through so much cruelty and injustice. As shown in the film with the main characters (Katherine, Dorothy and Mary), people of color could not formally have jobs, at least not in the same way as whites. The film talks about African Americans being paid less, they did not have official titles and their jobs were despised. The three African-American women were excellent at their job and yet they were reminded that their jobs were temporary (unless otherwise stated) and no matter how hard and skillful they were, they were considered replaceable.

It is for the above that I was impressed to see how Katherine and her friends managed to stand out despite all the obstacles that an African-American had at that time. They were able to show that they were better than other white people (those who were supposedly qualified). However, the racism against them did not stop, but increased the further they climb the stairs of success.

The film also shows a story of how an African American passenger vehicle was attacked with bombs and even then, it did not seem like justice was being done for that fact. It is noted that African Americans were not respected for their rights (maybe because they were not considered American citizens), and that is what makes it amazing how Katherine managed to stand out with her abilities to perform calculations and solve complex problems. In addition, it is also impressive how Mary managed to be an engineer and how Dorothy managed to direct a whole team of African Americans to work with IBM computers (Technology that was quite novel and difficult to manage at that time).

Understanding the SOLID Principles

In the section of the book called "Ace the Programming Interview: 160 Questions and Answers for Success" by Edward Guinness entitled "Understanding the SOLID Principles", the author tells us about the meaning of SOLID. Even though I didn't know this term, I had already heard about the contributions of Robert Martin to the world of good software practices. I could say that a very important assertion was made at the beginning: "the more things you depend on, the greater the chance something will go wrong". In my experience, that is quite true and for that reason, I think that dependencies between classes should be avoided as far as possible.

I think that the first principle called "Single Responsibility Principle" is one of the easiest to understand but at the same time one of the hardest to apply. To get a class to have only one responsibility, there has to be a very good software design, but developers must also devote time to code analysis (especially those that are dedicated to maintenance). Otherwise, programmers will simply do what is faster and simpler: Add code wherever it is going to work (Apparently) what was requested by clients.

The principles with which I do not agree at all are "Open / Closed Principle" and "Liskov Substitution Principle" since I believe that the base classes should have the flexibility to be modified as long as the repercussions of the modification are understood. On the other hand, I think that classes must certainly be made to be extended or replaced by functions, since in this way it is easier to add future changes without having to analyze too much (which is quite useful when delivery times are very limited).

The principle called "Interface Segregation Principle" seems very true to me. I think it is very important to keep the code in small fragments so that they are understandable and reusable at the same time without wasting resources (unnecessary code fragments).

Finally, I believe that "Dependency Inversion Principle" is extremely important for static typing languages since by using this tool, the dependency between the concrete classes is minimized.

Software Craftsmanship

In the podcast called "Software Craftsmanship" with Robert Martin and produced by Software Engineering Radio, many ideas that I found interesting were discussed. It struck me that someone as experienced as "Uncle Bob" (40 years developing) has decided to devote himself to coding rather than being a software designer or architect. Moreover, knowing that he is the founder of a company called "Object Mentor", because the most common is that the owner of a company is responsible for performing administrative tasks. However, it is true that an architect and a programmer should not be separate things, but an architect must also be a good programmer.

The main topic they talk about is "Software Craftmanship" that includes very interesting ideas such as, for example, the improvement of the traditional agile model. I liked the idea of ​​the agile team is the one that decides the artifacts that are necessary and can also be those who produce the architecture document, a task that the architect should traditionally carry out. However, it is true that it can be much more efficient to take the code as the driven document and the documentation to explain the aspects of the code that are not clear.

I think that the relationship that is made between the software industry and the craftmanship is very idealistic but at the same time achievable. Experienced programmers could be considered as master craftsmen who teach to apprentices all their tricks in order to get them to become teachers. If software companies adapt to this principle, they would see a clear increase in productivity and quality.

When talking about the evolution (The step forward) in the agile methodology, they take as a basis the 4 manifestos of the methodology, but with modifications that allow an improvement in this. I believe that the modifications in the manifestos can be summarized in that the software scalable in the future by making it understandable for other work teams.

Finally, I can say that something that made my view wider was the tools that a good craftsman should use. After hearing about that, I will definitely take the time to learn more about my favorite IDEs, about Git, Jira or Bugzilla, about Unit Testing and acceptance testing tools and of course I'm going to learn how to make good tests. I think that anyone who aspires to become a better programmer or software architect should have a good foundation of the tools and concepts mentioned.