The second week building a project from scratch.

Last week we have continued working on our respective projects. The topic of continuous integration has ceased to be theory and has become a constant practice that we implement in our teamwork.

Don’t spend too much time. (The Time Box)

During the first week we inspected a new idea, I mean “breaking down the tasks”. At first glance it would seem that it is only a matter of dividing the tasks as much as possible, but this week I began to apply a new criterion. This new idea is about the “time box”.

At first I took it as a common term in some general work methodology, but this concept seems to belong to common terms in SCRUM, for example. By concept, the idea of the time box is to establish a certain time for a task, this should not be very long, and as soon as this deadline is fulfilled, the task is finished.

It would seem a bit extreme to set limits for tasks, especially if these are the shortest times possible. We could think that it implies more pressure for the work team and its members, to everyone’s surprise, and me in particular, it meant the opposite. It has the goal of not spending more time than necessary on tasks, thus avoiding situations such as overthinking, and even procrastination. By dedicating small periods to each thing, the workload that falls on you is less.

Another benefit that I was able to identify is that since the task is so short it allows establishing “control points”. In case the task has not been completed, what has been done is reviewed, it is decided if the strategy serves to dedicate more time to it or if it is time to rethink a new way of working to complete it taking what was useful and what no.

This way of working had a certain impact on the way I organize myself. I have to admit that I have a terrible planning for my day to day, so my mentors suggested that I prepare a list of tasks that I will do during the day and in that list also include the tasks that I did the day before. Something similar to the stand up that I take with my team every day to mention the things we will work on. In order to fulfill these tasks, academic and personal, I tried to make them as small as possible.

The important details that I need to refine to improve in the use of this technique is to make sure that the time invested is of quality, learning to take the main ideas in a short time can be difficult and this is where I link to another point: search inside yourself .

“Search Inside Yourself” is the title of a book that I started reading recently, recommended by one of the leaders of the Academy program. This one talks about the importance of emotional intelligence. And that this does not have to be excluded in jobs where professionals such as engineers, technicians, physicists, mathematicians, etc. apply. Since work does not matter, the common factor that exists is teamwork. For this, interpersonal and intrapersonal skills are equally important.

I am starting the book, so I cannot give a final impression, but the idea I want to talk about in order to establish a very necessary point in the application of the “time box”, and the process of gathering ideas, is to train concentration managing our emotions better. Think of it this way: if you approach where there is water to see your reflection, while it is cloudy you will only see the waves and a distorted image, but as soon as it calms down your reflection appears immediately.

Working with Git

Moving on, I’d like to talk about my first experience using a VCS. Last week I learned that a VCS, in this case GitHub, not only helps us to work safely with versions of projects that we can alter at will, but it even has tools to carry out planning and control in advance of every part of it.

The way of working with branches at first is a bit confusing. Details like paying attention when working locally or remotely are the first hurdles, but practice makes perfect. Of course, it takes a lot of practice, because for now there are many commands to learn. And if commands aren’t your thing, there are ways to configure either an IDE or code editor to sync with a GitHub project.

I found great command support like: commit, checkout, reset and stash. I learned how to save my projects once they work. It saves changes without the need to commit and allows me to freely move between branches and get back to work. Also in the worst case scenario I learned to reset my branch when I did something wrong to a safe point and share them with my teammates to compare results or test it in different work environments or, in this case, as if we were all different users testing a product.

Although it sounds redundant, I like to emphasize that the work log, updates, deleted files or any type of modification in general can be consulted throughout the entire project. There is no better comparison than that of a time machine

Communication.

One of the first workshops we had at the beginning of the program was the communication one. How communication affects personal relationships and teamwork.

We had a similar situation, in which a colleague and I worked on a task, but we had the assumption that we were not achieving what was asked of us. It took us one day longer than planned and the next a colleague joined us to complete the task.

While our colleague carried out the task, we realized that it was already a point we had reached, but we were unable to communicate the idea to the rest of the team. We learned two important things:

+Communication: Learn to report a problem, letting others know what has already been tried and the results obtained.

+Tests: Screenshots, copy and paste of the errors in console or better yet the running versions of the tests carried out to see the results. Everything is important so that others know what has already been tried.

What about the errors?

Returning a bit to the GitHub topic. Another good practice that we are learning as we go is to document each issue with this type of information. In case of having presented a blockage, problem, error or even a bug that has been solved, it is important to document what was done and how. As mentioned in one of the Talks we saw about Google. You never know when a member may be missing (bus-factor). Or simply because too much information runs during the process of any project. So leaving a record is good practice.

Conclusion.

This week I can conclude that the process of recording both errors and successes is important at any point. As the phrase says “people who does not know its history is condemned to repeat it”. We are not a large number of people involved, but it is still just as important.

So far I only have basic knowledge about the use of GitHub, even so it has been enough to be able to give us structure, control over our project, evaluation points and assignment of tasks.

And last but not least. Communication is and will always be one of the pillars in any teamwork. And from what I’ve learned so far in my reading, if we don’t have a skill, it’s always a good time to learn it or even if we already have it, to improve it.