Encora Inc. Week 2

Introduction

This was definitely a tough week. Here I express a brief summary of everything I learned throughout the second week of the Reset Phase here at Nearsoft/Encora, from readings to videos. I hope you enjoy it.

About failures and perfectionism

“A lot of insecurity going on” these are the literal words of Ben Collins-Sussman in his talk The Myth of the Genius Programmer, along with Brian Fitzpatrick. Collins-Sussman uses the latter words so that they can start demonstrating the idea of some sort of inner instinct to find celebrities to idolize. And the insecurity Collins-Sussman was referring to, is that when we compare ourselves to these celebrities, to these idols, we become insecure because of how different we are. And I can totally agree on this. This insecurity is directly linked to failure.

We don’t want others to know that we fail because that makes us vulnerable. We don’t want others to know that we fail because our celebrities we idolize “don’t fail”.

The latter is thoroughly wrong. Successful people have failed. And they have failed a lot. And they accept it. They embrace failure. But we can’t, because we are egocentric. So, the very first step is dropping ego.

We need to stop thinking that criticism is evil, and we need to start seeing failure as part of our nature as drinking water. We will fail, but it’s on us how we deal with failure: if we see it as a disgusting experience we must avoid at all cost, or if we see it as a learning opportunity.

We don’t need to hide.

A great example of failure right there was the fact that they didn’t have their laptop plugged in to, what I suppose, was the power supply. And they even highlighted that, emphasizing that everyone fails.

So, in order to stop failing, we usually think that being perfect is the only way. Not because our ultimate goal is to be perfect, but because we see our idols and they seem perfect. And since we want to become like them, we try to be perfect. Bad idea. As, sometimes, in order to achieve that perfection, we may lie. And “we are all hardwired to lie”.

The latter is a really interesting statement. Are we? Linda Rising talks about it in her talk Perfection Is An Unrealistic Goal. When we, as software developers, get requested something with impossible requirements by our Clients, and they want it by June (or any other really close date)… What do we say? “Of course! We can do it!”. Because if everybody is working 8 hours a day, without any breaks, without any distractions, we will somehow manage to get it done. Right?

It’s a simple equation: the more hours we work, the more efficient we are.

Wrong. Utterly wrong.

We are under the illusion that being more productive means either multitasking or working longer hours and not taking breaks. And it means that we will often make statements based on that illusion. Statements that will eventually be a lie.

How do we know that by not taking a break we are more productive? That’s the goal. It’s not just sitting there and forcing it for 6 hours a day, it’s about taking a break, and start talking with the truth: “No, we can’t finish it by June”.

But, how exactly are we supposed to achieve this? I mean, it sounds easy, right? But we all know when something seems easy to do, it usually means it isn’t.

With this, we arrive at the end of this first part of the essay: the agile mindset. When we compare ourselves to our idols and we see how stunning and successful they are, what’s our excuse? He was a visionary, I’m not. She was creative, I’m not. We label other people, including ourselves, according to whether someone has it or not, and this is an example of a fixed mindset. On the other hand, the agile mindset says “I can get better, I can grow”.

Some noticeable differences between fixed mindset and agile mindset are the following:

people with a fixed mindset think that ability is static, like height; whereas people with an agile mindset see ability as something they can grow, like a muscle. Likewise, their thoughts on failure are intrinsically distinct: people with a fixed mindset see failure as something bad that defines your identity, while people with an agile mindset see it as a way of receiving information.

Rising also talks about the results of a research, which was focused on giving different types of feedback to two groups of children: in group A, whenever the children completed a task, they told them “Wow, you are pretty smart! You are really intelligent!” while in group B they said “Wow, you must have worked hard!”

The results were the following: the group A’s children were later identified as fixed mindset whereas group B’s children were identified as agile mindset.

When giving feedback to someone, we must focus the effort and the progress.

About software and people

Oh, software… Oh, people…

We know pretty well there exists an ideal (perfection) and (reality). The latter applies to pretty much everything… So, companies are not the exception.

In an ideal company, the leaders should also act as servants; as an employee, you should pursue responsibilities; you might question things; and you might take risks.

But the reality always crushes that dream of ours: in reality, leaders think you serve them; companies are often too conservative; there’s always unrealistic expectations; and many, many more…

This raises the question: how do you get things done in a dysfunctional environment? Well, you should ask for forgiveness, not permission; you should sneak ideas in; don’t destroy, replace; work the ladder; use the favored economy; make influential friends; and do not mess with administrative assistants.

A really interesting way of sneaking ideas that caught my attention was the following: “let’s try this, we can always undo!” Saying something like “let’s try this” is the perfect way to sneak an idea, because, if nobody likes it, we can always go back.

The end of this first talk astounded me: Brian Fitzpatrick & Ben Collins-Sussman even gave us this plan B, in case any of the latter tips on working in a dysfunctional environment worked well, and it is…

Plan B: get the hell out of there! Don’t be a victim.

I loved Programming Well with Others: Social Skills for Geeks, because Brian Fitzpatrick & Ben Collins-Sussman used this creative way in which they use “real” calls as an explanatory method, and I’m going to share with you what I think are the best tips & tricks they gave:

You should be thinking about “how do you work in a team” not “how do I present myself as a genius”; mistakes are ok; some teams are dysfunctional, and you can only accept it; if you start a project with respect, this respect tends to perpetuate; get off on the right foot with a new manager; don’t wait for orders, proactively, express what you really think; communicate!

It’s healthy and important to have a good team ego, because the software is not written by tools nor methodologies… Is written by people.

So, if we want to get software better, we need to look at making people better if we want to get software better.

Dave Thomas talked about the latter in his talk Developing Expertise: Herding Racehorses, Racing Sheep. There are five types of expertise levels: novice, advanced, competent, proficient and expert. The journey from being a novice to being an expert starts with the way we interact with other people.

What do the people we work with need to get better? How do people learn?

Level 1: novice. If you are a novice, you need to know how to solve the problem. The novice is gaining experience until at some point he becomes an advanced beginner, and begins to see the bigger picture. They are not stupid, they are mot malicious, they are just advanced beginners, and when novices, advanced beginners and competents asks questions like “why”, is because they want to understand the larger conceptual framework, and proficients and experts usually answer “I don’t know” because they don’t care about their bigger picture.

Thomas explains that there exists a golden rule of investing: “do it”, it applies to knowledge as well. The experience you get will make you a better person doing what you are doing. With this, Thomas closed his talk stating that it’s not your company’s job to train you. It’s yours. Because, in the end, experience doesn’t come from knowledge, it comes from practice.

About being original

Kirby Ferguson, in his video Everything is a remix, starts by comparing songs with their remixes. Covers and knockoffs are legal remixes.

Then he moves to movies. He states that, from the past movies, 74 out of 100 are either secuels or adaptations from comics, books, video games, etc. Transforming the old into the new is Hollywood’s greatest talent.

Because creation requires influence.

I was surprised when he showed the similarities between Star Wars movies and other previous movies, and I quickly recalled one time when I took a Writing Workshop: when I expressed to my instructor how worried and scared I was that, if I continued reading, my writings would inevitably be a copy of what I read. And he said to me “they won’t be a copy, they will be influenced. And I assure you, all the books, since the very first one, have been influenced by something”.

Ferguson states that we are convinced that creativity comes via inspiration, that original creations break the mold, that they’re the products of geniuses…

But creativity isn’t magic, it happens by applying ordinary tools of thought to existing materials, and the soil of which we grow our creations is something miscorn and misunderstand even though that gives us so much and that’s copying. And copying is how we learn.

Nobody starts up original, we need copying to build the foundation of knowledge and understanding and, after that, things can get interesting.

But now, in the late modern period, ideas are regarded as property. And, when it comes to Software, this property is often declared vaguely, trying to cover as much as they can.

62% of patent lawsuits are over software, the estimated loss is $500,000,000,000.

Do we really think that this is, or should be, right?

About performance, encoding, decoding and Linux

“Painting on a webpage is not free”, Colt McAnlis talks about performance in his talk #perfmatters: Tooling techniques for the performance ninja. He starts stating that there’s no longer a single pillar of web performance: there exists network, render and compute. So, how can we improve the performance on a website? These pillars have this hit list: in a network, we need to optimize the critical path; when rendering, we need to reduce the number of paintings; and when computing, we need to reduce JS execution time.

If your assets are too large and the number of dependencies you have are too large, of course it’s going to keep your critical path from being resolved. Reduce the number of requests, and reduce the size of the total number of requests

When it comes to mobile, we want to get the number of requests low. We have maybe one, two, three assets that had to be downloaded and resolved before the critical path can start painting, that’s the website you want your users to load, because that’s where money is.

Validate everything you’re seeing. Measure it. Go forward with that methodology. Don’t just rely on a bunch of people standing on stage telling you what to optimize. Go find it in your tool chain in your application and fix it there.

Then, it came encoding and decoding, a topic that McAnlis covers in three-episode videos. The main outcomes I got from them are the following:

Variable Length Codes are very similar to morse code, because morse code has the objective of encoding certain letters according to their appearance in the English alphabet: the more a letter appeared, the less length it had when encoded; and Variable Length Codes’ principle is assigning shortest codes to most frequent symbols. When I realized what this means in the computer world, I eventually supposed that it would be really, really, really hard to design and create the proper variable length code, and here’s why:

As I watched these videos, I quickly recalled those times when, whether at school or at online competitions, I needed to code a program to encode and decode something. And I recalled those moments because I remember pretty well how stunningly easy it was to encode information, but how amazingly hard it was to decode it. And McAnlis even emphasized it.

In Missing semester: Shell tools and scripting, the instructor gave a lecture about a lot of Linux shell’s commands, and how shell scripts work. Something curious here is that I didn’t know if I typed ./example.sh in the shell, and the file example.sh does not have the right access permissions, bash will tell me exactly that instead of running the file. So, as a good Software Engineer, I tried bruteforce: sudo ./example.sh, but it turned out those access permissions weren’t related to my current user, but to the file’s access permissions. So I had to type chmod +x ejemplo.sh.

Also, tldr, super cool.

The takeaway

Fail early, fail often. fail fast and learn constantly. Failure is an option. Without failure, how can learning happen?

It depends solely on you if you stay as a novice; it’s not your company’s job to train you. It’s yours. Because, in the end, experience doesn’t come from knowledge, it comes from practice.

If you are not into computers, or have not coded anything before, the following may sound weird, but software engineering is more about dealing with people than dealing with computers. Because we, software engineers, know pretty well how to deal with computers. What we often lack is the communication skills to deal with people, and you can only acquire it through experience.

Originally posted on: 2020/10/12, 9:08 AM