Skip to main content

Software Craftsmanship

 For this week, we listened to the 150th episode of Software Engineering Radio, featuring Robert Martin, aka Uncle Bob, aka (by me) the author of Clean Code. In this episode, Bob talks about architects and the role they should play in software development, and he shares some tips on how you can become a true craftsman yourself. 

First thing first, Bob believes that an architect (and in my opinion, any other non-coding role in the field) should be somehow involved in the coding process, because it makes no sense to put someone in charge who will not be responsible and won't have to live with their choices. I fully agree with this, and it's why I believe that the practices he talks about afterwards and in his other work is essential if you want to pursue any career in the field. 

Craftsmanship is often used to describe a piece of work where it's clear that a lot of time, effort, and knowledge went into its creation, and it's no different for code: the final product should reflect the experience of the people who worked on it, and in software's case, should correctly and elegantly solve the right problem. 

Bob also provides some tips on how to become a craftsman, mentioning the help of source control, IDEs and the tools that come along with them (or sometimes by themselves), such as debuggers, unit testers, shortcuts, etc. 

In my opinion, Bob gives a lot of good advice, and I'm constantly implementing his teachings in my day-to-day work, but I don't fully agree with his idea of spending so much time to perfect our software skills. I'm not saying it's a bad idea for everyone, but I think this field is too focused on being the best or being in a "top" company, for which you need to have a million side projects, and spend all your free time learning new skills (or get a little bit lucky like me), but it's not necessary in order to be successful in the field. 

We have the advantage of having a huge pool of options for where to work, and there's nothing wrong with working a regular 40-hour week, in order to avoid burnout and live your life outside work. If someone wants to spend all their free time working or learning, that's fine, but it's also important to remember that it's not the only road to success. 

Comments

Post a Comment

Popular posts from this blog

Microservices

 This week, we read an article called Microservices  by James Lewis and Martin Fowler, which did a great job explaining the differences between monolithic applications and those that run on microservices (and the ones that use a little bit of both). They explained the advantages and pitfalls of implementing any of these methods, and they conclude that while microservice-based applications seem promising, it's still too early to tell whether they'll be better than monolithic ones. Luckily for us, this article was published in 2014, and we're far enough in the future to know that they are, in fact, more widely used today. Before reading this article, I was already aware of these different types of applications, and I knew that the market had a preference towards microservice applications, but I hadn't realized how much this change had affected how businesses are run today. From personal experience, I belong to a cross-functional (XFN) team that dabbles in many different p...
Post a Comment
Read more

4+1 View Model

 This week, we looked at many different resources: two very short videos ("The 4+1 Model" by the Virtual Training Company and "Six Blind Men" by Phat Phish) and an article by Grady Booch titled The Elephant and the Blind Programmers . What they all had in common is that they all touched on either the 4+1 view model, or a concept known as wisdom gap, which is very closely related to the model.  In order to explain the need for the 4+1 model, Booch relates it to the old Indian story, which talks about how different blind men examine an elephant and come to different conclusions as to what it is, since they are all looking at different parts of it. The moral of the story is that they are all right in their own way, yet none of them have the full picture. The same applies to the model. Depending on who you are and what part of a system you're working on, you'll be interested in looking at it from a certain way, which will definitely differ from the other team me...
Post a Comment
Read more

Software Architecture

 This week, we read a chapter of Pete Goodliffe's Code Craft: The Practice of Writing Excellent Code. The chapter, just like this course, focused only on the importance and different types of architecture. After this reading and after having completed the first Ruby activity, I think I finally have a good idea of what to expect throughout the semester.  Throughout our degree, we have always been told how important it is to design before we start coding, so that we have a "guide" and to get an idea of the workload or work distribution from the beginning. However, so far, it hasn't been taught to us in this way; we would think about the code, abstract it into a higher level, and define our design based on what we thought would be easier to do.  However, I now see that the correct way to do it is the other way around. Think of what you want your software to accomplish, figure out its scale and any other relevant details, pick a style that fits your project's needs, a...
Post a Comment
Read more