Week 2 - What I learned

2021/04/13 to 2021/04/19

Overview

This week we are going to learn and try to understand that a programming language is just a tool and that having the right way of approaching it we can learn it quickly. Also, we are going to see how software engineering is about people and not computers and we have to worry about people and communication more than improving tools.

---

Videos

Google I/O 2009 - The Myth of the Genius Programmer

Things to note:

• There is no genius.
• Feeling that nobody should look at your code or project and this inhibits progress.
• If you are in a cave trying to build something perfect is harder to improve your skills.
• If you don't show your research you could come with something already done.
• Working in teams and communication is important.
• Lose ego.
• Criticism is not Evil.
• Embrace failure. In new things not in something that you have already failed.
• The faster you fail, the faster you iterate, the faster you learn.
• Practice is the key.
• Be a small fish.
• Be influenced. Be open to new ideas.
• Technology can solve social issues... in some cases.
• Social behaviors of tools.
• Involve collaborators... but... at a good time, not too early, not too late.
• Sweet Spot.
• There are no geniuses.
• Collaborate early and often.
• Pay attention to your tools.
• Pay attention to timing.

Discussion:

It's very interesting how these two guys are talking about software and they are focusing more on people than technical issues. I just noticed that they're talking about how to get better and what is true and false about genius, but from their corporate environment. I just want to point out that, well the advices are interesting, but let's just be careful because sometimes we are not in the same environment, but yeah... I liked most of them.

What I take from this video is that is rare to find a genius. Genius exists, but don't always succeed. You need to learn how to collaborate and work in a team, they can help you a lot. We also need to learn how to receive criticism without taking it personally, it's really important to separate your friendship from work. We are small fishes and we need that to keep learning. Practice and fail, fail fast, learn fast, do a postmortem, write down everything you learned and keep going, don't fail again, you are in a team... so you didn't fail alone, look for help and keep going.

#perfmatters (Performance Matters)

Things to note:

• There was a problem with performance in web applications running on mobile web browsers. (I didn't know)
• What you can measure, you can optimize.
• Performance Tunning Loop.
• Gather: Gather all the data, statics and reasons. You need to first, explain to yourself why is it slow.
• Insight: Get a reason and insight from data.
• Action: Fix it!
• Repeat it!
• 3 pillars of web performance: Network, Render, and Compute
• The network problem was to render the HTML on the screen, getting all the HTML parsed in the screen. The Number of dependencies. Critical Path.
• To solve it you could stop loading crit-path or resources(HTML,js,css)
• Scrolling costs resources.
• Make changes used to cost a lot of resources, needed to rebuild the whole site.
• Tools, not rules.

Discussion:

I do not know that there had been so many performance problems with cell phones. He's mainly talking about phones, but I think the main topic or thing that he's to transmit is that there is no excuse to not be responsible for the performance of our application. He's telling us that we have the tools and methodology to fix performance issues and a very good example of how to use them. That's what I learned from here, there are a bunch of tools to measure and not only performance but other quality attributes. Let's get that and understand that is part of our job.

Google I/O 2012 - The Art of Organizational Manipulation

Things to note:

• Companies are made of people!!!
• Learn how to navigate them (companies).
• The ideal company.
• Servant leadership. Leaders are not here to tell you how to do your job instead there are here to remove the blockers. Make sure that everyone is happy and efficient.
• Pursue responsibility. Find things to do, don't only do what have told you to do instead try to do something with your skills.
• Communicate proactively. Communication is important!.
• Act like an adult. Get your things done, your times, your work and no one is going to tell you what to do. They trust that you are an adult.
• Be responsible.
• Take risks, do something, fail, fail fast, learn, write down what you learned and try again.
• We have bad managers...
• Bad managers are too conservative, thinks you serve him, thinks you serve him,
• The real things in companies are unrealistic expectations, doesn't trust you, directional chaos
• Ask for forgiveness, not permission. Do what you feel is the correct thing. Don't be scared.
• Don't step in front of every train. Choose your fights!
• Sneak ideas in.
• Don't destroy, replace. Search for things that you don't like and replace them!
• Work the ladder
• Search for a safe place, change team, people, place, etc.
• You're not going to win all the time, sometimes you have to lose.
• You have to make things happen.
• Networking is important!!
• Ge along with everyone.
• Don't mess with Administrative Assistants.
• Plan B, always have one.
• Don't be a victim. Look to other options.
• Being successful in software engineering is not about just code, it's about people and corporate politics. It's about effort.

Discussion:

This presentation is separated into 3 parts so the first one is the ideal company and they talk about managers and I liked what they say. First of all, I like the way they question managers' roles, is like how a manager should be and what they're doing. I also think that if someone is a manager, he should have a different way of thinking and acting, to a certain extent have mental health that allows him to behave well first with himself and then with others. He also mentions those people who do many things to become managers, but that does not mean they can. Some people go up a step and they fall.

Yeah, we know that corporations are evil and all that stuff right, but I noticed that these guys are telling you that change can be made and starts with you. I liked the way they said it, I mean is not only to change but how... and these guys talk about things we can do. I liked that and yeah is true, sometimes we want to change things around us and we don't do a thing, we can start changing and inviting other guys to change too. We can do a lot of things, but it's about really doing it and if something goes wrong, then learn and keep going. Finally, if it's not working, then you are in the wrong place, don't be a victim, keep going.

Just make sure where you do this and how you do it. Maybe you are not in the right place or time.

Google I/O 2011: Programming Well with Others: Social Skills for Geeks

Things to note:

• It's not all about the technical stuff, is about social.
• Feedback of your code is important but if you aren't doing the right thing, then it's useless.
• Get everyone on the same page.
• Culture perpetuates and is contagious.
• If you're a manager, don't yell to software engineers instead clear the road.
• If you don't have a leader, someone is going to take that role and it's not necessarily bad, but it's different from being a manager.
• Don't ask what to do next.
• Autonomy, let them do their job the way they want to do it!. Let them free.
• Mastery, let them improve themselves.
• Purpose, make them feel like they are doing something important!
• We motivate ourselves.
• Don't waste energy on mad users.
• It's about users' trust.
• Have a good relationship with your users.
• Listen to your users.
• Learning to talk to non-technies is a skill.
• Learning to talk to non-technies is hard.

Discussion:

This talk is similar to others, but this one is talking about users. Users are also stakeholders of the software industry and they are also part of our environment. That's why we build software. First thing, users could also be distractors, but we shouldn't waste our energy fighting them, because we aren't going to win, and sometimes they're just some trolls. Let's be nice with them and have them close because they are also guides for us.

Another thing that was mentioned in the presentation and I agree with this! It's to talk to non-technies is really important. It's important because you will able to get some clues and ease your work if you make your client, or whatever person that you're helping, tell you more about their problem or need this will ease a lot of the job of understanding. In my opinion, we are the technical people if we can't conceptualize something hard into something easy that means that we aren't understanding at all.

The Best Programming Language

Things to note:

• There is no best programming language.
• Choose the language based on your situation.
• Criteria to choose a programming language.
• Productivity: How fast you do things.
• Performance. It depends on what you're doing, but don't worry too much about it languages are fast but it depends on your needs. Do I need to be that fast?
• Reliability. It depends, but you are not going to use a language that is likely to fail in web applications
• Portability. Consider in which devices the application is going to run.
• Community. People, libraries, forums, and tutorials that could help you. Depending on your needs and your knowledge you should consider this. Makes your job easier.
• Sometimes you have to realize that some languages are built for one purpose and maybe changing to that language could ease your work.
• The best language is not the one that you know.
• Trying a new language sometimes takes time and effort, but you will have a new tool and maybe your problem solved.
• No bests. Trade-offs.

Discussion:

Like this guy said, and I agree, language and frameworks are just tools. Depending on our needs, we need to choose a tool, we can't use the language we know for everything, because maybe that tool wasn't built for that purpose. We need to understand what we need and based on the criteria that we saw in the talk. The two main things here are that there isn't the best language and using a language just because you know it, could not the best choice. Sometimes we just need to dare to try new things and get out of the things we know. Maybe trying to learn a new language and using it, could ease our work or task.

Developing Expertise: Herding Racehorses, Racing Sheep

Things to note:

• Software is not written by tools, languages, frameworks, software is written by people.
• Software tools and development environments have changed (improved) and bug rating is still constant.
• If we want to make better software we have to do better people.
• What can you for your team to be better?
• Team members:
• The wizard: Knows everything.
• Novice: Needs a recipe. We need to know how things work.
• We give persons in teams the same recipe and instructions when they work differently and have different needs.
• We label people.
• As you become an expert we use more intuition.
• Novices can get confused.
• As you do something constantly you assimilate it. That's how you begin to do things.
• Advance beginner: They start doing things by themselves, but they can't do everything.
• Competent: Can do more things by themselves, have difficulty troubleshoot. Feel smarter.
• Proficient: They feel like they are going backward. They ask 'why'. Want to understand larger concepts. Learn from others' experiences.
• Expert: They can explain things in metaphors. Facts are not enough. Work primarily from intuition. Always seeking information.
• Dreyfus Model.
• Treat people differently, they are in a different stage and have different needs.
• Can't race sheep.
• Can't herd racehorses.
• Competent people: Take risks.
• Understand what happens in our companies and our careers.
• Communicate, get a number (level) and try to be treated like that.
• Let the experts be the experts.
• Experience makes us valuable.
• Have a plan. Diversify. Look for value. Invest regularly.
• Experience comes from practice, not knowledge.

Discussion:

First of all, I noticed that this is a problem that has existed for a long time and there is still no solution, but the good thing is that experts have started talking about it. The first thing that they say is that building software is about people and that if we keep putting bugs in our code it's because of people and not tools. They are going to the source of the problem, in my opinion, this a good approach to solve the problem and I'm also happy that they recognize that we are different from computers and we need to be treated differently.

That's the main thing that I take with me, we can't be treated the same way. We have different knowledge, experience, and needs. I like the way he is trying to say that you don't have to lock someone up in their role, let them be free they are going to do things a different way and it's not bad it's just different. Finally, I loved the invitation he makes to determine how we see things, maybe you aren't doing the right questions and to approach the problem differently. Understand your team, what they're doing and what they need.

Perfection Is An Unrealistic Goal

Things to note:

• Nobody likes to read code, all prefer writing.
• We don't know the specification.
• We think that agile is going to take us to a 'Nirvana'.
• We can't get everything right.
• We are hard-wired to lie to us.
• We lie to ourselves and others.
• Agile is about going in circles (cycles).
• Everything changes, even goals.
• Trial and error.
• Sleep: 90 minute cycles.
• We are not linear, we are cycling.
• The survivor was agile.
• Being productive is not multitasking or do more things.
• Take a break, don't work a lot of hours. Play.
• Try little things.
• Try a different way.
• Consciousness is not that smart.

Discussion:

Yes!, what Linda said, in my opinion, is completely true, we are trying to do things, and sometimes we don't even know what we have to do. We lose things, we forget things and that's why the things we do can't be perfect. To state this, first, we need to understand some basic functions that our brain does, and we need to adapt to how it works, the brain is not going to change, it's hard-wired. Continuous work is not doing something productive. Take breaks, and to take breaks is letting the unconscious work. Work different.

The Power of an Agile Mindset

Things to note:

• You can't change intelligence.
• You can learn new things, but you can't change intelligence.
• The agile mindset is to understand that you can learn.
• You face limitations, but you can grow.
• Agile mindset is about going back and improve.
• Agile mindset -> Give me the chance to learn.
• 
• Do things that you can do.
• Failure also teaches you.
• Agile mindset is less positive/negative about others.
• Boys and girls are treated differently so they develop a different mindset.
• Managers have a mindset.
• Managers label people. Treat people depending on the mindset.
• Teams have a mindset.
• Fixed educational system.
• We're born agile.
• The effort is good. Strategy is all!. Praise the effort.
• Agile is about effort.
• Agile is also about cultural differences.
• You can make a small change in any environment.

Discussion:

It's true... we encounter people that don't want to do a thing!. I mean they just do the basic and they think they deserve everything, and the truth is that nothing is free, everything costs. If you want to learn, achieve something or do something, it's going to take time and effort! You can find people quitting things because "they aren't good enough" and they have only been doing that a couple of months. That's what I liked about the talk, the message that is giving. Again, we have to change our minds and how we see things. I believe that everything requires effort and with only intelligence, you're not going to what you want.

Who do you Trust?

Things to note:

• Everyone is prejudiced.
• We judge without any information.
• We tend to think our group is better.
• We do this when we meet new people.
• We put people in little boxes.
• Vast labelers of everything.
• We have the power to make people think that they aren't enough.
• Managers are labeling before seeing the performance.
• We label ourselves.
• Stereotypes are prophetic.
• We set expectations.
• Working together is a more powerful driver for our decisions.
• We love collaboration.
• Cooperation on shared goals.
• You don't have to like everyone. Just respect and trust.
• Collaboration increases performance in achievement of something.

Discussion:

A very hard topic to talk about, but yes we all do that, when we meet someone we always judge them, and is something natural, is not going to stop. We can do some things like being aware, which is the main topic. Yes, you are going to pre-judge, but try not to label, try to take those things apart. Also, we need to understand that we can't do things by ourselves, so we need to cooperate and maybe is not for a common goal. The last thing, as we need to trust others, we need to be trusted and trust is not a gift, we need to win it in some way, so just to be aware of that.

Everything is a remix.

Things to note:

• The first video is making a comparison between some "knockoffs" done by Led Zeppelin.
• Genre exists.
• Everything takes parts from done things.
• We can call these done stuff templates.
• Creation requires influence.
• Copying is how we learn.
• Nobody starts original. After that everything gets interesting.
• Mixing ideas is the point.
• Basic elements of creativity: copy, transform, and combine.
• Mac is a combination.
• Combination of work of others.
• Innovations are the result of a combination.
• Evolution: copy, transform and combine.
• The original product can't be cheaper than the copy.
• Copying is restricted.
• We are territorial with our ideas.
• We restricted a source of ideas.
• Common good. Social evolution.

Discussion:

I think that the main message that we need to understand is that we don't have a real reason to not share our ideas and our knowledge. Like the video showed the best ideas in the world came from other ideas and influences. Another thing that I take with me is that copying is not that bad, we can start doing things copying others and trying to be others, but later on we need our style and that is when the fun begins.

Compressor series (3 videos. )

Things to note:

• Compression is to reduce the size of files.
• The probability of character appearing is important.
• Shortest code in more probable characters in a string.
• To encrypt we use the encoding table.
• To create a good decryption algorithm we need to assign the correct amount of bits.
• Prefix properties no one can share the prefix of other letters.
• Unary code. Equals probability.
• A Huffman tree uses a binary tree and branches are given a 0 or a 1. The representation of that character is given by the path from the node to the root.
• We have to consider variables length and entropy for our compression algorithm.
• Entropy minimum number of bits needed per symbol on average to represent your data stream.
• You need to understand your data to understand the entropy and length.
• To reduce entropy we can group characters in words.
• We need a dynamic grouping.
• LZ78 and LZ77
• Statical encoding.
• LZ78 and LZ77 powers the most famous and used compression algorithms.
• Markov models (See it later)
• Markov model assigns bits to transitions of the states.
• Markov invented an algorithm for predicting.
• Markov compressor encodes a string by looking at a letter and noting the transitions to the following letter.
• The number of bits to assign to a transition depends on the max number of transitions that we have.
• VLC for transitions.
• We need a frequency table for decompression.
• The encoder is going to change in every letter.
• IA is going to run a compressor in the future.

Discussion:

Sorry, I think it's a lot of information for those "short" videos, I didn't understand them very well the part 3. Also, he's going too fast. Anyway, in software engineering, there's also this kind of area that worries about data compression or structures and datastreams performance, and is very interesting how algorithms evolve and how they change. Another thing is that things are done differently now we don't have to wait for big scientists to create new algorithms, we can do it or in the future, the IA is going to be in charge. Another thing is that we as software builders, we need to know how to use these tools to create better software.

---

Readings

Collaboration, Bonobos and The Brain

I didn't know that we were like bonobos and that bonobos were so different from chimpanzees.

It was a really fun interview, but interesting. Linda says that it is important to understand the brain and how it works. Because this will enable better performance in software building. Now, Linda is saying that we make decisions unconsciously and that we need the two parts to make decisions the conscious takes the data and constraints that we have and the unconscious takes that data and comes up with solutions. And yes, I think this a great part and we need to take advantage of this and maybe we are already doing it!. Let's sleep well.

Now... in a part of the interview, they started to talk about chimpanzees and bonobos. This has to do with the brain and the evolution and biological roots, we are wired to work with a small group of people because we used to that in caves. This is related to pair and agile programming. In this programming methodology, we can create ways or "rituals" to communicate, work or solve a problem. What I can see here is that we are prepared or "wired" to work as agile methodologies and not to work in large teams without any communication.

Now, I also liked the comparison of how we work and that we are so far to live together like chimpanzees. By evolution and biological roots, we are not like that, and the way we work to build software has to change.

---

Technical, practice, or coding activities.

Missing semester: Shell tools and scripting

In this section, we review some things regarding bash and scripting. In going to paste my notes here. If I need it I can come back here.

Shell Tools and Scripting

Queues and Stacks

In this section, we reviewed some things regarding Queues and Stacks. I'm going to paste my notes here. If I need it I can come back here. I solved the problem (Code in onedrive).

Google code jam

This week we had to solve a competitive programming problem in different languages. I had to code it using Haskell. I've to say that is not an easy task. In my opinion, is easy to solve a problem have pseudocode and write the coding language that you need. This time was different, Haskell is a functional programming paradigm language so everything works differently. You have to think differently, I mean if you want to modify data you can't do it that well, there are some restrictions, you can only do this through functions and more restrictions. No traditional loops. No assignments or sums, etc. I know that languages are just a tool, but a paradigm is a whole new thinking process and a whole new programming process. That was the harder part using Haskell and I didn't have a lot of time. I got to a solution... it's not passing all the test cases but the firsts ones are passing.

Anyway, I had a bad time trying to solve it, but I used some of my new knowledge. I didn't search for everything or see a course, because I don't have time enough, but instead, I tried to master everything fast. I searched for everything I may need and learned all those things and put it into my code. So, I jumped a lot of things that right now are not essential, and manage to finish it that way. What it's more interesting about doing this is that you get something new, like functional programming and you realize that you have to do things differently, and you start from 0, you just keep going forward trying to learn new things and you get to the point where you have enough information to give a possible solution with the resources you have. This had to be and it was so agile, using the previous knowledge about learning fast is how I tried to get out of this. Sometimes the only resource you have is the ability to learn new things.

To finish this section, I got to a point where I got stuck because I couldn't get the idea of doing a function to do things that it could be done with a simple loop. My mentors gave me a new perspective by asking me a question: What is the main purpose of coding in a functional paradigm? When I searched for information about that, my way of structuring the code changed and that's how I changed my perspective and opened my mind to something new and finally, I could get to something. Sometimes is just a perspective issue, you have to see things differently and try to understand the source of that issue. These were my main lessons from this exercise.

---

Conclusions

A lot of things to note and learned this week. Things that I take with me!. We all need from others, that's why work in teams, we are not geniuses and we can't solve and know everything by ourselves. Working in a team also means that we are open to receive feedback and change the way we think and also learn from everyone. To make this work we need a lot of communication. Also, we need to understand that these teams of people are what builds software, not companies or computers. People are humans and have their problems, knowledge, and needs so this is what managers and companies need to understand and are starting to change. If we aren't feeling good, our needs aren't satisfied or we have bad communication then we can't work properly. Finally, there a lot of things that we can do to change things and to improve the environment, don't be a victim, try to change. Software is about people.

Finally, let's talk about languages and programming. Languages are tools and it has to be treated like that, you just use the tool depending on the problem. We can learn new things and fast but we just need to know what we need to learn. We are the builders and what builds software is ous not the language or the framework, so let's improve the way we learn and other soft skills and trying to understand the usage of new things and your perspective of things can help you a lot to learn or master new things.