Week 2: Polyglot Programming
The Lightning Talk
This second week of lightning talks was, I think, more easy due to the fact that we had the experience of the previous one. In my case I the did focus in constructing a narrative for the presentation, trying to engage more with the audience. I found it curious that something that helped me improve my speech during the presentation was adding a subtle intonation.
The subject of my lightning talk (LT) was about software requirements, I intended for the LT to be a basic introduction to the topic, but when I was developing the presentation, I realized that “the basics” of software requirements were very wide, and a 10 minutes exposition wouldn’t do it, so I did focus on a more general idea of what a requirement is and a concrete use case in which I could point the failure to apply a good software requirements engineering. I didn’t like the conclusion of my LT, maybe looking for people to blame for is not the right way to close a presentation, so I’ll have it in mind for upcoming ones.
The video material
Ben and Bryan, from Google
The Myth of the Genius Programmer
This was a very fun video to watch. The video is about a talk presented by two google employees, they seem to have a very good chemistry and usually complement what the other is saying, hearing them is like hearing two friends talking in a bar. The purpose of their talk was about this myth that exists in our industry, in which we almost idolize to prominent people in our field, for example Bill Gates, Steve Jobs and lately the well known tech personality, Elon Musk. But this idolization comes with a price for everyone in the industry, let me explain you the myth.
The myth of the genius programmer is an illusion that almost every programmer has had at least once in their careers, the myth as described by Brian and Ben is somewhat like this:
A genius goes to a cave, once in the cave, he builds something amazing, all by himself. Lastly, he reveals the results of his works to the world, and the world is impressed.
But wait a moment? how did he do it? well he’s a genius obviously, he can do great thing by himself. But this is simply not true, there is not a single example of something in our industry made by a single man that is widely adopted in the industry. Every great project is the result of the work of a team, unfortunately, this is something not widely accepted, and people prefer to attribute a successful project to a single entity. This provokes that people aspire to be like them, to build something by themselves from scratch, without errors and widely accepted by the industry once it’s done, THIS IS SIMPLI WRONG. Not Elon Musk nor Bill Gates nor anyone else has made anything by themselves alone.
The problems associated with this kind of behavior are that it hinders the personal progress as well as the project as a whole. If you are solely responsible for a given feature in a given project and you leave, everyone else will suffer as they are not familiar with what you’ve made. This is called, The Bus Factor.
The Bus Factor is a complex formula to determine the number of people involved on a given feature :P. It asks “How many people does it take for a project to collapse/turn to hell if they are hit by a bus”. So scientific.
The Art of Organizational Manipulation
Continuing with Bryan and Ben, they now introduce us to the world of the organizations. Something that they used in their presentation and that I found funny was this:
Companies aren’t made from code or compilers … they are made from Soylent Green.
Soylent green was a product featured in a film with the same name that dealt with an overpopulated world, this product was made from humans. So, companies are made from humans and in order to be successful, or to be in a healthy environment, you must know how to navigate this entities.
They made this point because, generally, programmers and people in similar fields have been portrayed by media as extremely introvert individuals that go to extraordinary lengths to not talk to people, I don’t know how much truth does this hold currently, but in my limited field of influence I have known fierce software engineers who are not afraid to make themselves heard. Back to the point, the environments described in the talk are:
- The Ideal Environment
In this environment, managers don’t manage you, they are there to serve you and to make your job easier.
Software engineers take more responsibility as result of the previous statement.
They expect you to act as an adult, that’s why they do not manage you
- The Realistic Environment
The manage don’r trust you, that’s why they manage you.
Managers tend to ignore the low performers, driving away the real performers.
—
In conclusion, it was a really nice talk, they mentioned things that I have either experienced or heard about and how to deal with them. It’s awesome to have insight from experienced people in our field.
Compressor Head series — By Colt McAnlis
This was the harder series of videos to swallow, the more you progressed the more you were confused, when I heard that my partners in the academy were struggling to understand the series, I remember that I thought to myself “well I can make my lightning talk about these videos and hit two targets with one shot” but then I gave up on the idea because they’d be difficult to understand to me too, and man was I right, even now I am still confused about the Marklov’s chains.
Compression is a necessity, not a commodity, people don’t compress thing just because, without compression the Internet as we know it can’t exist. Compression allows us to send enormous amounts of data in a fast way. This concept comes way before the Internet, it was born with the invention of the telegraph. Morse code is a form of compression. In order to send characters through a wire, the data was codified as a series of electrical signals that were encoded and decoded based on codes, as the one below.
These codes were designed based on the occurrence of every character on the dictionary. Similar to this, we know encode every character in a series of bits represented by 1s and 0s. The problem with this is that we may no need to send te full 8 bits used to encode every character over the network, we may compress these characters given several factors, as the frequency of use in a given string, and end up with a smaller transmission load.
In order to this we must acknowledge first that there is a correlation between the information content and the probability of symbol occurring in a stream. This correlation is measured by the formula Log₂ P. This correlation outputs something called “entropy” which is the minimum number of bits that each bit in a stream should have in order to represent the whole stream. What the compression techniques always look for is to reduce entropy in order to end up with an efficient compression algorithms.
As we can realize, binary code can’t be VLC (Variable Length Code) due to the fact that binary must always have 8 bits in order to represent a character, and not only that, they also violate the prefix property.
The prefix property dictates that once a code has been assigned to a symbol, no other code can start with that pattern.
The LZ77 and LZ78 are the algorithms responsible for the majority of the compression used in the world. They were developed by Abraham Lempel and Jacob Ziv in 1977 and still in use today.
Developing expertise: Herding racehorses, Racing sheep
I can say that this was my favorite talk, it was imparted by one of the founders of the agile manifesto and the way he delivered the speech was awesome. I completely understood all the concepts he wanted to transmit and that’s a great deal!
So he basically says at the beginning that methodologies and software languages aren’t going to fix the world, because they are basically tools. Even though this tools have gotten better since 1970, the bug rate found in systems has been maintained, and this is not because the tools have failed to be better, but because software is still made by Soylent Green 🍀 (hehe).
So, in order to improve the creation of software, we must understand why we are the problem. It’s here when we are introduced to why I think will be the next topic of my lightning talk, the Dreyfus Model of skill acquisition. This is a model that shows how people learn new skills, is divided in levels, from novice to expert, in a pyramid scheme.
The model says that, when we first enter to a certain field, we are, obviously, novices, we need someone to tell us what to do, we need guidance, in short, we need rules to follow. As we advance in proficiency, we start to decrease our dependance on rules and start developing more our intuition, that is, our intrinsic understanding of why the things are the way they are, in a below consciousness level.
The problem with this way of skills acquisition is that the industry hasn’t adopted it yet. Industries are filled with people who stays in the second level of the model because they require initiative in order to go up de ladder of expertise. And this is not something found only in engineering fields, we can find these situations everywhere! And this is a problem because an industry full of level 2s is wasting potential.
So we should all strive to reach upper levels in the Dreyfus model, because up until level 2, you can be easily replaced, these are the most vulnerable positions. So you should make a knowledge portfolio. How to do that? well, you can start by the next steps:
- Diversify your knowledge
- Plan what knowledge you want to get
- Look for value in that knowledge
- Be active, a portfolio is something that needs to be updated regularly
- Review it constantly
- Do it
Perfection Is An Unrealistic Goal & The Power of an Agile Mindset
This one hit close home. As i said when I did introduced myself in the first week and someone asked us what was a film/series character we thought better represented us, and I answered with Chidi, from The Good Place. Chidi is a character that has problems with deciding, he can’t decide until he’s absolutely sure the decision is the correct one. The problem with approaches like that one is that there are decisions that can’t be measured by rational means, you have to make them based in other factors. But worse than than that is that this inability to make decisions until certainty has blessed you does not enables you to progress in life. You can’t wait to have the perfect weather to perform an activity.
3 months ago I did realize that I had stopped exercising IN ANY WAY, I was seated at work 8 hours a day and then seated during my rest hours, I was seated all day! and that started to take repercussions in my health, obviously, so I decided to start go to run in the park near my house (is down the street). The first day I was going to run it started to rain, so I said, well next day I’ll start; next day came and there wasn’t rain, but it had rained hours before and the ground was wet, I didn’t want to slip or something, so I said that the next day will be a better day to start, the next day I had so much work that at the end of the day I was to tired to even remember my plan to go to run. This cycle has continued until the time I’m writing this, fellow reader, please don’t judge. So, my problem is that I’m looking for the perfect conditions in order to start something that does not require said conditions in order to be done, what I must do is simply go and run, if it’s raining, well, I should run earlier or when the rain stops, if I have to much work, maybe I should get better balance between work and free time, etcetera. And the same applies to this industry (I bet you didn’t see that coming :P ). What Linda tries to tell us is that this is the core of Agile; Agile doesn’t mean “No documentation” or “shorter development cycles” it means to get things done, without trying to create the perfect circumstances to start developing. BTW kudos to Linda Rising, she is amazing!
