Go back to index

Week 2 - 27/09/2020 to 02/10/2020

Overview

This week was very productive and filled in with a lot of learning I had the chance to learn about:

Communication Skills.
What things make a good software engineer.
Ideas and their value.
The Linux Shell.
The Work Flow to work in software issues.
Self-Trascendence.
Creative Thinking.
Achieving Progress.
Master a Skill.
Be a Badass Dev.
Other Cool Stuff.

We have a lot of ground to cover so get ready to get a peek about everything I learned this week. I hope you enjoy it as much as I did.

While doing this reading I have to admit that I wasn’t 100% in agreement with what I read, mostly because it came out to me as to manipulative or machiavelic, I understand that maybe a politician or a ‘big cat’ as the autor calls them has to use them to get what they want, but honestly I just didn’t feel comfortable with some of them. Nonetheless there are cool things I learned:

Body Language Stuff:

Pivot towards the person you’re talking.
Avoid touching your face a lot.
When someone arrives wait one second and then smile, this will make them feel welcome.

After saying hi:

People want to be convinced that everything is OK and the two of you are similar.
When you say your profession, add some interesting facts.
If you don’t know what to say repeat the last words.
Go back to an interrupted stories, the other person will thank you.

VIP Talk: Maybe this was the hardest part to read, I just don’t like the idea of deliberately changing the way you talk and behave to be liked by other people, but here are some interesting points that I agree with.

If someone gives you an unwanted question twice, reply with the same answer twice.
Never make a joke at someone else expense, it’s just bad taste.
You can amplify your vocabulary to avoid cliches.

Phone Calls: I think this one is particularly relevant now that a lot of interaction (or most) is done by calls or video-calls.

Replace your gestures with sounds.
Say the other person name a lot.
Answer calmly and when you realize who’s calling give them a happy greeting!

Of course there were a lot more of tips, but these were the ones that I think I will really try to aply because they resonate with me. Learning to communicate properly can be hard, so that is why this topic has a lot to offer.

Profound lessons from Stanford Professor

To be honest I’ve never heard of Professor John Ousterhout before this read, but I’m glad that I was exposed to his ideas, I’ll list each one of them and add some insigths.

First take your system from non-working to working. A lot of times programmers can spend a lot of time thinking of optimization or the perfect code, but first you should focus on making the thing work and then from that starting point, do iterations to refactor or improve the code
Use your intuition to ask questions, not to answer them. You see this all the time on the internet, people have the intuition about some idea and they’re willing to defend that idea to death, instead of actually questioning if they’re right.
Facts precede concepts. And idea so simple and elegant that had never crossed my mind, but of course I think I applied this without thinking about it. This just means that to understand a concept you have to observe several examples and identify the pattern of that particular concept.
If you don’t know what fixed the problem you haven’t fixed it. This has happened to me a lot of time during school projects, modify x, y and z. Then suddenly the problem is solved. Do I know what solved it? Nope. Now I know that that behavior was not a good programming practice.
The three most powerful words for building credibility are “I don’t know”. Of course! Makes a lot of sense to me now, being able to admit you don’t know stuff will make you more credible for when you actually know.
Coherent systems are inherenyly unstable. I find some beauty in this, the world is chaotic and we as humans are always trying to make things our way, to have our stuff stacked and organized. But entropy always strike, no matter what you do. You have to be in peace with this, and understand that things are going to fail at some point.

Ideas are just a multiplier of execution

This one was a really short one, but powerful. I’ll try to resume it in one phrase:

Ideas are worth nothing by themselves, they become worthy when executed.

This reminds me of a meme: I think almost everyone is familiar with this experience at some stage of their lives, having a lot of ideas but not actually executing any of them. And we all know how that ends… Let’s try to avoid it.

Missing Semester: The Linux Shell

I find very interesting how most of CS or SWE students can agree how there are some essential or very important topics that were never really thaught formally to us. For me, this is one of them. During the course of this short chapter of the Linux Shell I learned about several commands:

THIS IS WHAT I UNDERSTOOD FROM EXECUTING THIS COMMANDS AND NOT THE FORMAL DEFINITION. IT CAN BE WRONG.

Create a directory mkdir
Create a file touch
See what it’s inside a file and print it in the console. cat
Inspect a command and see what it actually does. Trust those guys, not me. man
Change the permissions of a file (rwx). chmod
Find a specific pattern in a string. I guess this is like some kind of rejex but for the terminal. sed

X Work Flow

In this article the author proposes a methodology for solving tickets and working on software development. These are my main takeaways:

The whole process is not expected to be done by one person, but everyone on the theam should be aware of the process.

Discovery

Discover what’s wrong or what you want to change, this can be a bug.
Understand your system.
Identify when the problem was introduced, what variables have changed in the mean time.
Use the data you have to test ideas of the possible solution/problem.

Hypothesis Generation

Explain in one sentence what is going on.
Make a set of protocols to replicate your observations.

Problem Definition

Define your problem in one sentence.

Search for solutions

Many problems are already resolved. Use the internet.
Brainstorm to come up with ideas.

Modeling

Make a simplified version of the soultion (Prototype).
Make a document with the solution step by step.
Write the limitations, hypothesis and black box modeling of the solution.

Religion, evolution, and the ecstasy of self-transcendence

At the beginning I was a little skeptical about this video, because I thought it was about religion. The real idea of this video is explainning how self-trascendence is the ability to look for the well-being of other people and not just yourself. According to the video you can achieve this not just by religion, but by other ways like meditation or nature.

One of the things I found the most interesting was how this was based in the science of evolution. It shows some simulations about how simple life forms, when working together had a lot more chances of surviving and reproducing, so in some way mother nature planted the seed of cooperation in all of us.

At the end I agree with the author, I think I’m still in an early part of my journey but that eventually I want to have that feeling of being part of something bigger than myself (as long as it’s not a cult).

Creative Thinking Hacks

The author was an ex software engineer in Microsoft, and had really interesting insights about creativity. Here are some of them:

The first thing that sticked to me about this video is that creativity is a kind of work, like any other. It’s good to demistify it and not think that only certain people can access creativity.
Ideas are just made from other ideas, if you don’t know how to start, take other ideas and modify them.
Sometimes we see constraints that are not really there, if you’re able to identify them you have room for improvement or innovation.
If you want to be creative, pay attention in which environment you work better.
Physical work like walking helps you trigger creativity.
Having an idea is easy, following trough is the hard part.

He also had some hacks to boost creativity:

Keep an idea journal. I find this idea very interesting and I’m putting it in practice myself to see how it works.
Give your mind moments of solitude. Of course, all the great ideas come in the shower or when you’re walking by yourself it’s because you have time to think.
When you’re stuck working in a team, invert the problem. This is about coming in a brainstorm with the worst possible ideas, this will break the ice and provide you a fresh moment to re-invert the problem.
Partner Up. A lot of legends have partners, why wouldn’t you?
Fail. If you’re willing to fail, you won’t be afraid of tackling bigger problems. And bigger problems are what you need for growth.

“The first draft of anything is sh!t.” -Ernest Hemmingway

How Progress Really Happens

Sometimes we want to do major changes but we don’t know how can we actually have an impact in whatever we’re doing. This video is perfect for anyone who wants to learn about having real impact in your environment. Here are some bullet points:

Change Of course to provide progress you need to change something, but how do humans feel about change?

It creates work, so we don’t like it.
People tend to resist it.
It puts you at risk
We only do it when things are unpleasant enough.
For change you need power.
For power you can use persuasion.
You’ll need to anticipate what you’ll need to make change happen.

The playbook for change Here are some general steps to follow for someone who seeks change:

Make a Pilot and show it to gain support.
Find allies based on that pilot.
Find resources.
Scale it up until it becomes the real thing.

Another extra points for managers:

Managers should facilitate the execution of the playbook for their employees.
Be careful what kind of behavior you reward as a manager. If you seek people making improvements, you can’t reward people who only agree with you.

I find this particularly interesting, because I think that Encora as a company offers you this non conventional way of making change inside without actually having to struggle as much as you would in another company, this is thanks to the power dynamic that’s implemented with the LTs.

How To Master Anything

This short video resumes a book that talks about how you need to practice more effectively in order to master an hability. Here I’ll present some interesting points:

If you settle you’ll stop improving. This just means that if you think you’re already good enough, you’ll stop seeking for change.
Mental representations are models we build in our minds in order to recreate things before doing them.
Deliberate practice is needed to build mental representations.
Effective Practice, this is about recognizing what you can and can’t do yet.

The cycle of practice: Rapid progress » Hitting a perceived limit » Prolonged frustration » Sudden breaktrough

To give a concrete example of this: Imagine you start learning how to code, you start learning a lot about declaring variables, printing strings in the console and maybe even some if statements, but suddenly you reach a chapter of Object Oriented Programming and you can’t really wrap your head around it. It starts to get really frustrating, you read it and re-read it and it just don’t makes any sense. Until suddenly you’re able to find a different perspective and understand it. This goes on until you hit you’re new limit.

In the video we can learn about something called Purposeful Practice to improve the way we Practice. It goes like this.

Have an specific goal.
Put intense focus on that goal.
Get immediate feedback about your performance.
Be in frequent discomfort with your level of expertise.

And if you want to take this to the next level and reach Deliberate Practice there’s a simple formula: Purposeful Practice + Expert Coaching = Deliberate Practice.

Making Badass Developers

This one was one of my favorite contents for this week, because it talked about how we came become more powerful learners. My main takeaways were:

Every dev has a different answer to what you must know to be a good software engineer.
You need to learn fast rather than know a lot.
We are often mistaken by humanoids. Our habilites and energy are finite.
We have to be careful with how we manage cognitive resources. Just thinking about something can drain you.

And now the good stuff, how to actually get better:

First understand that tasks you perform go into one of 3 categories: A) Can’t do but need to, B) Can do with effort, C) You master the task.
If things pile up in B: Try to keep more stuff in A. Split into subskills so you can move more things to C.
Your habilitis that you take for granted in C can not be optimal. Move back things to B if necessary and refactor them.
You need to move things from A to B and from B to C.
To achieve the previous point: Get a lot of high-quality examples of the skill you want to master, for a rule of thumb, about 200 of good exposures in a short ammount of time.

The last point is my main takeaway, next time I try to learn something I will expose myself to a lot of code or examples from experts. According to the theory this will help my brain to eventually identify the pattern that I want to accomplish and be able to master the skill by myself.

Others

Besides all the readings and videos I learned about other stuff thanks to my menthors, talks from Encora people, and the lightning talks from my fellow interns. Here are some of the things I learned in no particular order.

Scrum has a lot of meetings, called ceremonies. Each one of them serve different purposes.
Data Science is statistics in steroids.
GraphQL is a very powerful form of API. Before I had only the chance to work with REST APIs.
There are several good practices when coding, among them are: write good comments, give good name to your variables, and try to follow the same conventions in your code.
Machine Learning and Neural Networks are a hard think to grasp.
Encorians do a lot of parties when there is no pandemic.
Markdown is a very powerful but simple tool for writting articles. I like it.

Conclusions and Main Takeaways

There was a lot of content to absorb this week, and I really enjoyed learning from it, I think that I now perceive myself as a softskill enthusiast. This is because I’m becoming to realize how powerful this can be for personal growth. Also I like how a lot of things for self-improvement are kind of interconnected. Like there’s some common agreement on good practices regarding to softskills. For example a lot of resources rely on the idea that you have to admit ignorance and make yourself vulnerable, it comes interconnected with ideas like get out of the comfort zone or to push your limits. I’ll call it the softskill multi-verse.

I’m starting my own idea journal, and so far I like it. Gives me an easy way out to write all my random ideas that can be either garbage or in someway useful. Eitherway I don’t have to decide in the moment I can revisit them later and classify.

Note to self from next week I will try to write in this blog as I absorb every individual content. This week I writted all of it at the end based on my notes. But I think I can make deeper insights if I write the blog post when I have it fresh in my memory.

That’s all from this week I hope you enjoyed it and that you didn’t get bored, thanks for reading :).