This week at Encora was full of challenges, research, and resources. Today I’ll be sharing about the topics I got to learn and the problems I faced when working with tech skills.
There is this conception about the mythical genius programmer, the one that goes to their caves and comes back with a lot of code that is perfect and compiles on the first try. Truth to be told, there are no genius programmers out there, and even if there are, what the needs of a successful project are good programmers, people that don’t hide their code to their peers and acknowledges their mistakes and fixes them.
When we are developing we need to have that communication with our teammates and be able to share and ask for help when needed.
We need to remember that companies are made of people and working as software engineers means not only working with the software but also knowing how to work with people (as we talked about before). When starting to work at an organization it’s important to:
Being able to communicate effectively is a fundamental skill when working as a software engineer, and Programming Well with Others talks about 4 main areas where social skills impact when working in a project:
There is a model that describes the stages between being a novice to being an expert, that was described in this talk and is as follows:
Perfection Is An Unrealistic Goal is about agile development and how trying to make it perfect is not really possible. Agile development is not about being perfect, but rather be consistent. Projects are unpredictable and we can only do so much when giving estimations for them. That’s why we need to be flexible with the development.
It also mentions that we humans work in cycles, when learning something, when sleeping, etc, in the same fashion that agile iterations work. That’s why we should not do agile, but rather be agile.
In The Agile Mindset, it is mentioned that any ability, talent, or knowledge can be acquired as long as we practiced it, we get better at it. It is important to see failures as opportunities to improve, this is called the “Agile mindset”. It is important to set our goal to learn rather than look good, and be resilient to challenges.
I also got to learn about the conscious and unconscious mind Linda Rising interview, where they describe the unconscious mind as a powerful tool and how we can take advantage of it.
Rising also talks about stereotypes and as much as they come from evolution they can (and most of the time) be harmful.
Nowadays everything is a remix, a mix of existing ideas in combination with other smaller ideas. There are a lot of examples in the music industry. This series also describes the process of taking an existing idea and creating or building something out of it. The basic elements of creativity are copying, transform and combine are also introduced, and of course, we have to take into consideration fair use.
I also got to learn about compression algorithms, starting with the basis of variable length codes and how to make them work you have to know the distribution of the symbols used for the data stream in order to assign the most frequent one the shortest code (otherwise this won’t work out pretty well). With this comes the construction of the symbol table, which maps each symbol to the corresponding code. This table also comes in handy when decoding the stream.
There are several compression algorithms used today, but the most popular ones are the LZ family, which are a series of algorithms that use tokenization of the data stream, a search buffer, and a look ahead buffer.
But as popular as this family of algorithms are, the trend is moving toward using Markov Chains (MC) algorithms for compression. The MC algorithms serve as the foundation for many big data, analytics algorithms used by big companies. With MC, we don’t encode symbols (states) but rather the transitions between them.
When working with development (especially for mobile devices) we should take performance into consideration. One way to do this is with the performance tuning loop:
When starting to code it is very tempting to get married to the programming language that we are using since it is familiar, we know how to use it. In reality, we shouldn’t use just one language for all of our projects and should take into consideration some factors like portability, reliability, performance, productivity, etc when choosing a programming language to work with.
I also got to learn new cool commands/tools when working with bash, such as:
ls *.sh
convert image.png image.jpg
convert image.{png,jpg}
source script.sh
tree, broot, find, fd, etc.
One of the assignments of this week was to apply what we learned with the Best Programming Language and solve a problem using a language we had never used before, so I chose C#, and in this case, I solve the Reversort problem.
I learned a lot about C# syntax, the way the arrays are passed as parameters, and how to start a new C# project. I also find it helpful, in order to solve a problem in a new language, to:
This week was full of time management, resources, and some coding challenges, but at the end of the day, it comes down to being ready to keep learning and not be discouraged by failure.
I believe all these new skills and knowledge will be very important for not only the following months but for a lot of professional experiences. I especially like all the lessons that can be applied both in professional environments and personal life.